Not trying to be pessimistic here, but I feel like the author is being a bit loaded with the marketing text. There's many pieces of TUI software that do this exact same thing with "color and clarity" and the same fuzzy search, etc.
I am a die-hard advocate of the Phalcon approach to this problem, which is to deliver the framework as a PHP extension. It requires slightly more admin experience to get it setup, but boy is it fast!
I know a couple of people that went out of their way to have the yen backslash on their PC. It certainly is charming in a way. Kind of like how email addresses used to be written like:
I share some similar sentiments with the author and I developed a personal note-taking system which has automatic linking based on the collocational word. You can think of it as sort of like an inverted mind mapping software.
I think a shortcoming of my software and other people’s note-taking software is poor integration of time.. if I could modify my system so I could in effect make some commentary of the changes in the word files I think that would be a much more productive process than simply being able to visualise the changes as a static thing.
modern PHP? I would contend the OP is still a hipster, but at least he's pointing out that fashionable programming is really toxic for the industry as a whole. Boring technology is good because the ordinary, standard thing is meant to be exactly that, ordinary and standard. Leave the breaking changes, feature churn, evangelising, endlessly-revised howto articles, missing/outdated documentation, etc. where it belongs -- in the "innovative" software.
Indeed, I would say that even now the extant textboard and irc users are still attempting to push the boundaries of sophisticated stupidity and they have become experts at it.
In the world of real advancements in terminal development, Plan 9 had come up with Blit and drawterm in the 90's -- so why haven't we made it back to there yet? the answer mostly lies in the lack of simple drawing primitives in X, the TTY interfaces, etc. People like this warp.dev guy come along every few months and poo-poo everything because secretly they do not want to learn it (and neither do we, really!). But nobody really comes along and tries to fix the termcap-brained mindset we still have when considering terminal design. It seems like after everyone got 256-colour and 24-bit colour support we have just accepted the state of things.
You're right, they both worked on ZMQ together, however Sustrik disagreed with some of the design decisions and decided to make nanomsg. Hintjens and co have worked on code generation tools since the mid-90's. Read the zproto github page for more information!
First of all, the third column here is highly editorialised. If you have a look at anything related to languages, he always lists Erlang, Oz, Prolog -- I wonder why? I won't go into a diatribe on this-or-that nonsense but it would be fairer to talk about languages by their capabilities i.e. either include more languages like Ocaml (which is my hill to die on for "high-society" languages) or just say "has pattern-matching and concurrency primitives".
As for the Systems Programming section, does he really think that knowing how a compiler works is a system-related topic?? and why is that level 1? shouldn't the first level be understanding things like system calls, filesystems, drivers, kernel operation? processes? etc. Once again I think this matrix has been constructed with little consultation from domain experts for that area.
I agree for the most part with the criteria for programming itself, but I need to nitpick at the claims about using IDEs. Why is "written a custom macro" a tier-3 requirement for IDE proficiency? wouldn't it be more reasonable to say "has written a plugin"? and moreover what does this really have to do with programmer competency? a beginner could write a macro or plugin for VS Code for example. Therefore I don't think it's a good marker.
I guess like most discussions on programming, it is about 60:40 in terms of objectiveness. The remaining 40% is largely grounded in the author's personal experiences and you can tell that he had trouble deciding what the top-tier programmers would be capable of, preferring largely complexity-increasing exercises instead of complexity-reducing tasks. And for me the latter is the sign of an expert.
Surprised to see no mention of Acme here. As much as I love keyboard-based tools, I must begrudgingly admit that from a scientific standpoint it is much quicker to use a pointing device because there is no recall associated with the action, you intuitively drive the device. However that said, there is appallingly little effort to actually utilise this power. Anyway, this is a roundabout way of saying that I don't think mouseless development should be celebrated. Good on him for figuring it out, but did we really need to figure that one out?
Okay, it's provable... what value do really get out of it? isn't the whole reason why we still use C because it gets so close to resolving (or at least acknowledging) hardware or platform-level implementation problems? we can continue to re-invent the language in isolation but you can't replace a hardware-level programming language in this manner.