mr_vile

Maybe the title is a bit misleading because "instead of applying for jobs" implies to me at least that it's a job-finding site.

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.

This repository here has a pretty exhaustive list of these softwares: https://github.com/indigane/git-graph-drawing

Anyway, congratulations to the author for actually releasing their work.

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!

It would have been more honest to add (in Rust) to the title.

say the line, genejak

Ok, but can we keep the ads off HN? :)

For anyone that doesn't know, the ! is for UUCP routing.

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:

[email protected]

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.

link: https://github.com/Tanami/maja

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.

> what is more boring than Rails?

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.

the symbols compose in both directions and are aware of tacit parameters, so I don't really think your summary is even remotely correct

>militant commitment to stupidity

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!

Wow, that's a very insensitive title.

My thoughts:

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.

I wonder how much he got paid to write this.

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?

What a confusing title.

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.

I'm surprised the article didn't mention bunnyhopping or other kinds of physics exploitation-based gameplay. It could also have talked about games like Rocket League which rely on completely impossible physics to make a fun game.

I think there are three problems here: first is that the new generation of developers that Mozilla is trying to attract are not used to systems which do not persistently store data in an API-accessible database backend.

Second that there is a perception of plain text as an antiquated medium of communication (and yet we persistently reinvent markdown as a way of simplifying rich text).

Third and most importantly, the issue is not that IRC is old or is missing features, it is that IRC encodes a specific model for running a communication network (hubs, leafs, operators, etc). When we try and replace IRC with a system like Matrix we are giving up the old model of "owned" nodes and the decentralised nature of it to instead bow to a centralised model where certain people wield absolute power. Is this really the right way? what if I want to write a bot to perform some unusual administrative function? do I have keep updating it every time the API changes? that's why IRC is good, I don't need to do that.

it's dead? maybe I live in a bubble but it seems to be more alive than ever for me and my peers...

Well if you're really going to go down that route, you should remember that the "unix philosophy" favours plain text as the data-passing mechanism. JSON itself does not have rules for how things like malformed UTF8 decoding should work, which means that every implementation of this JMAP protocol is going to need to refer to a specific JSON spec for starters, which is already destroying the credibility of the "simple" argument. Also, I don't see how your claims about hackers "in those days" has any basis other than speculation here.

the cut, sed, xargs, utilities are available on all major unix derivatives and have a pretty consistent set of command line flags... I don't see why we need to suddenly slap camelCasedParameters on everything because the author needed to read some man pages...

well, it's definitely not identical

This whole exercise seems more damaging than constructive, and I don't really like the author's smug tone, as if he deserves praise.

This style is very similar to one which is used by expert C programmers, it seems that most people that write like this have had experience writing parsers and compilers too. It's not their fault that most people don't just think purely in terms of function composition :P