There was quite a discussion on HN about the podcast joined by Brendan Eich himself:
647 karma · joined November 24, 2020
3 techies made disgruntled noises in their apartments behind drawn blinds and the rest of the world moved on.
> The overwhelming majority of users are not shedding tears that their favorite product hasn't updated its icon in more than 3 months.
And the overwhelming majority of users will not shed a tear if their favorite product changes their icon once a week.
At first I thought it was an allusion to the mythical rational markets, but the content is so staccato, cryptic and Buddhist Koan-like that I was not able to make the connection...
I think my attempt at understanding it is tainted by what I expected it to be. I would be greatful for clarification.
Supposing most people think like that, it would indeed explain why there are so little of these types of visualizations out there. The effort, as you say, is probably not worth the objective value it would create (which is why I hoped someone else had already done the work).
For me, a visualization of the breakdown of languages by application domain would have immense value, especially for broadening my perspective. As someone who never gets to toy with FPGAs in my day job for example, I would be oblivious to most of the ideas that flow into PLs for FPGAs. Why a visualization? I guess that is just taste. I find visualization a lot easier and faster to digest.
And I bet there are quite a few PLs that I have no idea about that have answers to problems I have encountered before.
And for the second type of visualization, I find those to be quite helpful in understanding and tracing back the roots of PLs. This often makes me comprehend quite quickly why things are done certain ways in different PLs. Especially looking at the main, root influence of a bunch of PLs and understanding the zeitgeist it was created in, what problem it was solving, who created it etc. give me a much deeper understanding.
So I don't think such visualization are useless, but I could probably not justify spending the amount of time it would take to create them either.
From personal experience most teachers simply ended up in the job as a fallback plan or a day job to get by. There was the occasional passionate teacher that put in a lot of effort and I really appreciated that, but having talked to many other people about the matter it does seem that those are few and far between.
I also got the impression that teachers tend to live in their own little world and tend to have very little experience outside of the educational system. Hence they often lack the need to explain to students why they are learning these things or how they may apply them in the "real world" (as we called it back then).
On the other hand I have met quite some folk in the pre-retirement age ~50-65 that are in technical jobs and had 30 years of experience in explaining and understanding things and are passionate about teaching what they've learnt. Most of these folk are also privileged enough to be able to start lessening their workload. I always wonder why they do not take up to passing on their wisdom to the next generation, by maybe just teaching a single course at a school?
Why is it not the norm to go into a job for, say 20 years, and after years of experience start teaching? Why would it be a good idea to have a teacher straight of college teaching kids just a couple of years younger?
I know only of one person that taught at a small school in their pre-retirement years (mostly helping out with maths) and as far as I know all of his kids performed excellently.
In a talk he gave in Gibraltar [1] he explains the many difficulties with making claims about Neanderthals. I suppose the tl;dr is that we are really just very barely scratching the surface of understanding where Neanderthals fit into the hominid ancestry tree, but I don't feel entirely justified to sum up the talk like that, because it contains a lot of nuance. Watch it, if you have the time :).
[0] https://www.anthropology.wisc.edu/staff/hawks-john/
[1] (2018) https://www.youtube.com/watch?v=aa3258dAOxo
In most cases I have encountered people uttering this quote they were using it as a mere observation of the statistical fact that a large group of users will inevitably lead to a larger amount of complaints. And the conclusion was usually something like: "Don't blindly disregard a language, because many people hate it. Always take a closer look if the tool is up to the job."
"There are only two kinds of languages: the ones people complain about and the ones nobody uses."
I think it's an interesting point you make, because Python is actually one of the few languages that tried to break away from its past (the whole 2.7 to 3.7 fiasco), but it seems the need for a language to be stable is just much, much greater – so features are just piled onto the existing standard instead.
If COBOL taught me one thing, it's that I'm pretty sure in 60 years time there will still be critical infrastructure running on Python 2.7.
Giving it the benefit of the doubt, I could not help but wonder if this was the Usenet post you saw back in the day that made you apply for a job at Amazon :)
Regardless of the fact that most of the banking sector is still stuck on IBM mainframes from the 60s-80s running COBOL:
I have seen accountants who's only job it was to come in every day and do the same sums on Excel.
I've seen people insisting on a calculator and a printout so that they could sum up columns of an Excel table and send the results back via email.
There are valid reasons to move slowly. Transition costs to new systems are usually immense and the process is a nightmare for banks, but none of what I described fell into that category. It was just people refusing to change their ways. A report for treasury could've been instantaneous with a super simple live updating dashboard. But no. Instead, the CEO got an Excel file emailed to them every week that was put together by 40 people – many of whom entered the numbers manually.
In the industry we have come to call people involved in these tedious processes "hamsters", because they might as well be going up and down the escalator all day.
I don't think many people understand how excruciatingly slow banks move and how inefficient they are.
/cathartic rant over
Edit: (I should add for context that this was a fairly large bank in continental Europe)
I tested it in Vim and VS Code. In Vim it was like the regular REPL experience of a shell, but with more editing and completion power. The only thing I found lacking was that there is no file name completion, but I understand that this is hard to implement.
I almost think this removes the need for any new kind of shell, since the most annoying part (to me at least) – the input method – has been solved.
Thoughts and Opinions?
For anyone else interested, the parent paraphrased a scene [0] from the legendary British sitcom "Yes, Minister" (~early 80s) where the civil servant Humphrey explains, in the most cynical manner possible, how the EU (at the time EEC) came to be.
Nowadays, if I don't understand something, I head to the keyboard and start explaing it in text and it pretty much always works. I rarely revisit notes, mostly to link them together and very seldomly to revise them. If I have the time to organize the notes, that's great, if not, that's fine too.
I don't know know if this will work for you though. Learning is highly personal and imo just trying to find new ways to learn things can help a lot too.