Sixel support unfortunately came to terminals in 01988, as that page explains. I saw it myself in 01992. Sending uncompressed color raster data over a 9600-baud serial link again every time you wanted to look at it was a terrible idea, made worse by the stupid Sixel encoding inflating it by an additional 33%.
Today, when we're sending it to terminal emulators running on teraflops supercomputers over gigabit-per-second links, it's only a waste of CPU and software complexity instead of user time and precious bandwidth. But it's still a waste.
Why couldn't we have FTP and Gopher support in web browsers instead?
> I don't think they needed improving in order to continue accessing the existing sites that still used them
The browser support would have need continous security fixes and rewrites unfortunately, the protocol specs and the code was written in the day and age of a much less adversarial internet. It's much safer to handle those sort of protocols with a HTTPS proxy on the front these days. There's dedicated gopher and ftp clients still out there, IMHO browsers are too big and bloated as they are they need more stuff taken out of them, not more added without taking anything away, particularly stuff thats old and insecure and not used much anymore.
And yes, I'm also here for the retro factor :-) my pet project is Z80/6502 emulation in UnrealEngine with VT100 and VGA support and running BBS's in space.
So I'm all over stuff about old ANSI, PETSCII and anything even tangentially 8x8 character set related:
I think it had been many years since the FTP code had needed a security fix, and at least a year or two for the Gopher code.
The entire original point of the WWW project was, approximately, providing a better user interface for accessing files on FTP servers. So to me it seems perverse that the current stewards of the Web have broken that.
I think JSON Schema made the same fallacy as eg. OWL did: The assumption of an open world. 99% percent of the time you want to express "This message should look like this and everything else is wrong". Instead JSON-S went the way to make everything possible at the price of rendering the default unwieldy.
Is Julia a general purpose programming language? I mean I did check the web site which contains a "General Purpose" section, yet the articles seem to center around "scientific applications".
it is a general purpose language, but it's happy place is math. Most languages (except Fortan Matlab and R) are very much oriented towards writing web servers/compilers etc, so Julia gets lots of wins in science just by virtue of caring more about math.
Julia is a completely reasonable general purpose language, but getting people to switch generally requires a ~10x better experience, and Julia can't deliver that for general purpose applications.
I might be biased but I found it that the people who came to interview for the Rust roles of my company were noticeably better (or at least better at interviewing) than the applicants for the Java roles. More knowledgeable on the theory, struggled less on the hard things, more up to date on their tech watch
Isn't that pretty common in all languages that are not big?
They attract people truly interested in programming, not those going through the motions at a job.
I have heard this same thing with Haskell, Lisp, and many other languages out of the mainstream Java/C#/Javascript/Ruby.
Well, now you name something. Java is the most bureaucratic language only a matching personality or a programmer who is not very good would tolerate it.
This kind of generalization is so old. Imagine someone told you that "I've noticed that people of race A are noticeably better than people of race B". If you think it's different, just consider that people don't really have much of a choice in either case: there's a lot of Java developers because there's a lot of Java jobs, universities teach it, and it's been around a fairly long time when compared to Rust, at least... i.e. there's a lot of forces pushing people to using Java, and once you learn a language and get a job in such language, there's a lot of inertia that will keep most people on that same language for a long time. Yes, they can eventually choose something else, but only if that's a thing in your region, which may not be the case at all... and in any case, why would you go out of your way to change? Java used to be pretty terrible, but these days, it's a decent language. I can do Rust, but I still would pick Java for most projects given the choice, unless it was something where performance mattered more than the easiness of hiring Java developers and finding Java libs (though I admit Rust is catching up, there's a lot of libs now! However, one missing lib and you may be stuck for months having to port or implement something yourself - while in Java, or C++ for that matter, chances are slim you'll be in that situation).
I feel you're objecting to the wrong comment. sebstefan appropriately specified "the people who came to interview for the Rust roles of my company [...]", and was giving it as a counterpoint to the previous comment's broad generalization.
> there's a lot of Java developers because there's a lot of Java jobs, universities teach it, and it's been around a fairly long time when compared to Rust, at least... i.e. there's a lot of forces pushing people to using Java, and once you learn a language and get a job in such language, there's a lot of inertia that will keep most people on that same language for a long time.
The fact that one language is the mainstream default taught in many schools, whereas the other requires going out of your way to pick up, could well be a factor in the latter having more knowledgeable average applicants - in the same way I'd expect Gentoo users to be more technologically competent than Windows users on average.
> Yes, they can eventually choose something else, but only if that's a thing in your region, which may not be the case at all...
I presume the majority of Rust programmers learn it online.
Not at all. His comment was worse in that it generalized a whole lot of people based on the minor evidence he's been able to collect. Unless he's had several dozen, at least, Java applicants, as well as dozens of Rust applicants, I assume he's just using the exact same plain old discriminatory thinking people used to employ when comparing, among many things, race and nationalities. It's incredibly hard to generalize anything about people honestly.
> whereas the other requires going out of your way to pick up, could well be a factor in the latter having more knowledgeable average applicants
I disagree. It's much more likely, in my view, that newer languages will appeal to people who value the wrong things in a business, like which language they want to use for the excitment of being in the cutting edge (not to mention technically as well - we've tried for so long to create languages that make software engineering better, but anyone with a long experience in trying things will know that language is very low in the list of things that help: many studies have shown that over the years)... which also tends to correlate with people who will leave the job as soon as something new catch their eye.
Except in extremely niche cases, the language is not that important. The only things that really help writing software are static types and tests... and that doesn't mean the more the better either: there's a diminishing return with both. That's why Haskell is NOT the pinnacle of software engineering, despite what some fanatics will try to tell you (proof of which is that almost no important software is written in Haskell or languages like it - I think the most successful type-rich language so far is actually Rust!).
> I presume the majority of Rust programmers learn it online.
What I meant is that in their region, there's a good chance that learning another language is useless to find a job because all jobs are in Java or C#/C++.
But I do advise younger people to learn many languages anyway because of the fact that it really helps them think better and not get stuck with a particular approach to software engineering when there's many.
> His comment was worse in that it generalized a whole lot of people
The only statement sebstefan made specified "the people who came to interview for the Rust roles of my company" and likewise for Java applicants - groups they presumably have first-hand experience with. It was jhoechtl's previous comment that generalized to "the Rust workforce".
> I disagree. It's much more likely, in my view, that newer languages will appeal to people who value the wrong things in a business, like which language they want to use for the excitement [...]
Whether your views on people who learn Rust are positive or negative, you do still seem to agree that there are factors that can cause people with different levels of experience or attitudes to programming to choose different languages.
> anyone with a long experience in trying things will know that language is very low in the list of things that help [...] The only things that really help writing software are static types and tests...
Not necessarily the syntax of the language - but languages will have design decisions and ecosystems build up around them and that can make them better suited for particular purposes. Rust's borrow checker is very effective at reducing memory safety bugs without losing performance to GC or reference counting, for instance.
>he's just using the exact same plain old discriminatory thinking people used to employ when comparing, among many things, race and nationalities. It's incredibly hard to generalize anything about people honestly.
The reason we shun it for race and nationalities is because you can't pick those, you're born with it.
All generalizations are not the same ; your job, your hobbies, your programming language of choice: these assumptions might yield to incorrect results in the exact same way for the exact same reasons, but they are not on the same moral ballpark
Enjoy the warmth!
reply