Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

[flagged]


Please don't engage in programming language flamewars here. They're shallow, tedious, and silly, and never teach anybody anything (except maybe flamewar tactics).


Can we please try to stop talking about this specific language ecosystem as an awful deplorable hell hole or whatever?


> Can we please try to stop talking about this specific language ecosystem as an awful deplorable hell hole or whatever?

Back in the second century BC, Cato the Elder ended his speeches with the phrase 'Carthago delenda est,' which is to say, 'Carthage must be destroyed.' It didn't matter what the ostensible topic of the speech was: above all, Carthage must be destroyed.

My opinion towards JavaScript is much like Cato's towards Carthage: it must be rooted out, eliminated and destroyed entirely. I don't know if I'd go quite so far as to say that the fundamental challenge of mass computing is the final destruction of JavaScript — but I want to say it, even though it's false.

JavaScript is a pox, a disaster, a shame. It is the most embarrassingly bad thing to become popular in computing since Windows 3.1. Its one virtue (that it's on every client device) is outshone by its plethora of flaws in much the same way that a matchstick is outshone by the sun, the stars and the primordial energy of the Big Bang added together.

JavaScript is the XML, the Yugo, the Therac-25 of programming languages. The sheer amount of human effort which has been expended working around its fundamental flaws instead of advancing the development of mankind is astounding. The fact that people would take this paragon of wasted opportunity and use it on the server side, where there are so many better alternatives (to a first approximation, every other programming language ever used), is utterly appalling.

JavaScript delenda est.


That's great, but someone else thinks PHP is worse than javascript. (All those copy-pasted security holes.) Another person thinks iOS is the real problem. (If we don't own our devices, we're not free.) For me it's malaria. (Think how many more capable programmers we'd have if fewer people were dying every day. Plasmodea delenda est!)

We can all go around commenting on every single thread about how our chosen terrible thing is terrible, and then every thread looks exactly the same and it gets really boring. Or we can all restrain ourselves to only talking about how terrible our chosen terrible thing is, in threads that are about that thing.


I would disagree with you on a variety of levels, but the phrasing and effort you put into that are impressive. Please have an upvote, and this has gone into my quotes file.


+1 for effort, but I fucking love Javascript.


> I don't know if I'd go quite so far as to say that the fundamental challenge of mass computing is the final destruction of JavaScript — but I want to say it, even though it's false.

Well, as long as you're having fun!


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).


> 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.


Can this specific ecosystem please stop being a massive pile of crap? Then maybe we can have something nice to say about it :)

Perhaps the new ECMAScript standard will help. I have my doubts (but as with any statement about the future it is hard to say with any certainty what will happen). The Node rot runs deeper than the usual Javascript nonsense.

If it feels like Javascript is being unjustly maligned: (a), it isn't; (b), wait for the next gnarly buffer overflow exploit to come along and you'll see that people despise C just as much.


I don't think people despise C, they just think it's misused and difficult to master.

With JavaScript, many people are just vitriolic about it. I try to offer counterpoints because I'm a small part of this ecosystem, and I'm thankful for the work people put into open source tools, libraries, etc.

I also happen to think JavaScript is a pretty neat language... like, one of my favorites, despite its shortcomings.

By the way, I don't know of any languages without serious shortcomings... funny, that...


Oh, you don't care for JS/node? That's really interesting. Do you have a non-flammable, on-topic comment about the project?


A drive-by provocation can be hard to resist, but please don't take HN threads further into flamewar.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: