Hacker News Reader

Comment by benbenolson | Hacker News Reader

It's not node.js that's horrible: it's great for what it does (web development). When taken out of that use case, it's awful, because it's simply not meant to do systems programming or to make local applications.

It's kind of like people who knock Perl: it's made specifically for text parsing, nothing more, and too many people use it for much more. Since it's not meant for more complex things, it fails, understandably.

I think what the comment was trying to point out is that oftentimes there are things on Hacker News that are written in JS that shouldn't be: systems programs, emulators, shells, etc. This is not the fault of the ecosystem itself, but rather the misunderstanding of the authors about the viable use cases of the tool that they're using (node.js).

View on HN

> It's kind of like people who knock Perl: it's made specifically for text parsing, nothing more, and too many people use it for much more.

Perl 1 and 2 I think really were specifically for test processing, but it is neither widely regarded as a text processing language by its users, nor would someone learning the language notice that it's particularly geared toward text processing. Perl is hated on because it's a language that turned the dynamic up to eleven and embraces multiple ways of doi g something which causes ecosystem fragmentation, and because perl 5 predates a lot of now-widespread conveniences.

I think that's still a lot of blanket judgments that programmers who can and have built other things with Node than web things, and with Perl than text monging tools, have to disagree with.

Node, for example, is a high-performing and fast-starting interpreter for a dynamic language with a base runtime that includes good tools for building network servers, system utilities, etc. There are many, many uses for which it's just great.

So when you say that Node is "awful" for anything except "web development" it's just inviting disagreement. Why make this kind of strong value judgment about a general purpose tool?

That's because it's a waste of time to write a program in a primitive language like C when you don't end-of-the-world absolutely need performance/hard realtime guarantees; even then it's a better idea to only write the 5% performance-critical parts in C/asm and the rest in a saner high-level language.

C is definitely the wrong choice for a complex data-structure processing piece of software like a text editor.

Even though vanilla JS is madness, it gives you a very nice base to build on - namely closures and a GC, which make languages like Clojure or Purescript possible.

Still, for an editor I'd prefer pure Javascript over C every time.

There are more concerns than performance. The choice of C here is a philosophical one. Vis seems to come from the same school of thought as the Suckless projects, where the unix design principles are worshipped. People who are interested in that kind of stuff are also usually fans of writing in C, simply because C is the most Unix of languages: Makefiles control the build, which allows trivial integration of external tools into the build process, function names match 1:1 with the labels in the produced object files, no name mangling, documentation comes in man pages.

But really, a text editor is something C is quite well suited to. Javascript wouldn't bring much to the table, and you'd have to jump through hoops for something like mmap.

I agree that often the choice of C is philosophical rather than technical, or we wouldn't see so much misuse of that language (and yes, I wouldn't count the build or package management system (or rather the non-existence thereof) or the documentation format as serious technical arguments for or against a language).

Just to be clear, I'm not advocating the usage of Javascript here, rather I'm trying to make the point that C is a really really primitive language and programming in it, rather than in a higher-level language (any higher-level language) is almost always a waste of time.

(Drivers and memory / performance-constrained code being an exception.)

Btw, there's a mmap module or library for any major programming language out there (checked for Js, Python, Ruby, Haskell, even Clojure.)

Some things are just more convenient/efficient to do in C. As an example the mark handling[1] used to represent cursors/selection relies on pointer arithmetic.

Other things like the syntax highlighting are implemented in Lua which is high level but still has low resource usage.

And yes part of the choice is also philosophical. I consider an editor a core system tool which should have minimal dependencies.

[1] https://github.com/martanne/vis/blob/02c6df7cd4bca89506cf1d0...

A mark could just be an offset inside the Text buffer instead of a direct pointer. Yes, dereferencing a mark would be slower, but do you really think that matters? I mean even if you did that 1M times/sec there wouldn't be a noticeable difference to the user.

On the other hand, look at array.c. Or buffer.c. Or map.c. Or all the manual linked list management stuff. Or all the other logic that would be so much simpler with a more functional language. I mean, sure - there's an unique feeling to being so close to the metal, and that's fine, but if you want to build something new reinventing the wheel for the millionth time is a waste of time.

edit: there are compiled higher-level languages too (i.e. Haskell). If you want minimal dependencies, it doesn't really matter how the binary got built.

The nice thing about the pointer as mark thingy is that while the offset from the start of the file might change when something is inserted before it, the pointer will remain the same.

Anyway this was just an example. I agree that higher level languages (including functional ones) have their own merit. If I would start again today I might consider Rust. But again the LLVM dependency seems kind of scary.

Again for me an ideal base system is built upon a kernel, libc (musl), C compiler (cparser/libfirm), coreutils (sbase/ubase, toybox, busybox), editor (vis) etc. Writing a C compiler is non-trivial, but doable. Creating a C++ compiler on the other hand ...

A self contained (including terminfo entries etc), statically linked vis binary weights in at around ~800K. This allows usage in resource constrained sytems, I don't think the same would be possible using e.g. Haskell.

Fair enough - if portability to systems without much more than a C compiler is a project goal, than C is obviously a good (the only?) choice :)

>end-of-the-world absolutely need performance/hard realtime guarantees

As someone who spends much of their time inside a editor, I would say that this is pretty important to me.

I meant hard realtime [0]. Your operating system is probably not hard realtime, which means that any editor you run isn't either.

[0] http://stackoverflow.com/questions/17308956/differences-betw...

"I think what the comment was trying to point out"

It's easy to understand what the comment was trying to point out, because there are similar comments in ~80% of HN discussions. That's the issue.

I still like node for writing utility CLIs as well, which I find myself doing A LOT these days. To be totally fair, that's mainly because of the excellent feature rich CLI modules out there (yargs, commander, etc...); but, I've found I want my CLI utilities to be in an interpreted language, and node just fits the bill pretty well for that.

But why? It's a deployment nightmare to keep node updated on servers and laptops and desktops that will never, ever use node to server server-side JS, why do I need it and NPM and the whole upgrade nightmare it implies to run a random CLI utility?

"Hey guys, look what I did!"

crickets

"... with JAVASCRIPT!"

thunderous applause and/or retweets

I wrote a compiler for a toy functional (lazy) language.

In bash.

Reply on news.ycombinator.com