JavaScript is the C++ of the Web - <AUTHOR> http://pointersgonewild.com/2015/08/02/javascript-is-the-c-of-the-web/ <comment><USER2> > Too high-level, too JavaScript-centric. It's going to take programs encoded > as Abstract Syntax Trees (ASTs) as input, which seems quite wrong. GCC, > clang, and other real-world compilers usually generate Control Flow Graphs > (CFGs) at the output stage, not ASTs. Forcing compilers to convert CFGs back > into ASTs seems silly.

An AST is used because it allows significantly smaller download sizes, which is quite important on the web, more details here:

[https://github.com/WebAssembly/design/blob/master/AstSemanti...](https://github.com/WebAssembly/design/blob/master/AstSemantics.md)

WebAssembly is in a different situation than gcc, clang, etc. It makes sense for LLVM IR, for example, to have a CFG, as it is a compiler IR meant for optimization. But WebAssembly binaries are meant to be distributed over the web and instantiated as quickly as possible.

> This decision was clearly made to try and simplify the job of WebAssembly VM > implementers, at the expense of everyone else.

I don't think that is the reason at all. In fact it adds work for those people to handle an AST. But the work is justified by the startup speed benefits that it brings to the web platform.

<comment><USER3> I think Luke Wagner put it best. Paraphrased, "an encoded AST is just a bytecode for a register VM with a compressed encoding form for 'the last register I mentioned'".

Besides, converting a CFG to a high-level AST is a complete non-problem these days.

<comment><USER4> What resources are there on the state of the art algorithm-wise for doing that conversion?

<comment><USER2> One option is the relooper [1][2] which is used in emscripten. It recreates high-level control structures as best it can, then falls back to a helper variable when it can't. Another option is node-splitting, where irreducible control flow is solved by duplicating code (but that has a bad worst-case code size increase).

[1] [http://dl.acm.org/citation.cfm?doid=2048147.2048224](http://dl.acm.org/citation.cfm?doid=2048147.2048224) [2] [https://github.com/kripken/emscripten- fastcomp/blob/master/l...](https://github.com/kripken/emscripten- fastcomp/blob/master/lib/Target/JSBackend/Relooper.h)

</comment></comment></comment></comment><comment><USER5> The problem with ES6 is that everyone has 2 features they like in it.

The only thing that matters in my opinion is generators and (in ES7), async/await. This is a shift we've been seeing in _many_ languages and I think actually tangibly solves a real problem in a transformative way. By that I mean, people will actually think about problems differently. Especially in JavaScript where everything is asynchronous, you need first class support of asynchronocity.

There are a bunch of feature I "like" in ES6 but are ultimately useless in my opinion. Arrow functions are great, but could 1) be implemented in a transpolar, and 2) unfortunately behave different with regard to this and thus make the language even harder to understand (why did all my code break when I switched out the arrow function for a normal inline function?).

Classes are horrible in my opinion, especially if they start inspiring people to use instanceof, which is a broken feature in Javascript (and hence why we need things like Array.isArray). Due to the fact that in JavaScript you will often have code from different contexts, you can't rely on these checks, and the old-style JS programming encourages you to use feature detection, whereas now you will think you can do something like this. The species properties (so map returns the right thing when you subclass Array for example), is even more complex. The fact that I can subclass Function is a bit absurd. The fact that subclassing Object, vs subclassing null, vs no subclass will be a lot of fun to understand.

Let scope is fine I guess, I honestly never thought this was a big deal (coming from C and having to make the switch). It was of course implemented with TDZ which makes it incredibly hard to write in a transpiler, so now you have situations where the transpired code will work but once real let is added your code will break.

<comment><USER6> async/await is one of those very C++-ish features, though, due to how it's implemented.

Understanding ES5 async callbacks requires very little conceptual understanding -- you need to understand run-to-completion and the event loop (and I guess the idea of higher-order functions), but otherwise it's straightforward.

Understanding ES2016 async/await keywords require you to understand all of that, plus ES2015 promises, ES2015 generators, and how they're all orchestrated together to implement async/await. The code looks simpler, but understanding what's really happening is a lot harder.

<comment><USER7> True enough... I've been using async/await for about 6-8 months now via babeljs, and tbh trying to explain it to people so they understand how it really works is a bit painful... a lot of people don't understand that an async function is simply a promise wrapper around a generator yeilding promise-friendly values.

It's kind of important to understand promises to use await/async affectively. I love the easier to read/follow code though.

</comment></comment></comment><comment><USER8> After working for ~2.5 years on the web stack, I've spent the better part of the last year working purely in C++, and I can agree with the author's sentiment here.

Both languages have warts, but JS is a small enough language (at least in the ES5/ES5+Typescript world I was working in) that the warts felt finite. The first couple months were full of surprises, but after that I felt like I had a good grasp on the language, and knew when it was going to bite me.

No such luck with C++, however. It still seems like there are several times per week where I'm surprised by some new way the language can screw me over, like non-virtual inheritance, or a newly discovered subtlety in the way includes are processed.

Another benefit of JS - since the language is interpreted, build times tend to be much lower, and debugging tends to be much easier than C++.

EDIT: Another benefit of JS - people like to give JS devs grief for all of the OSS frameworks they create, but in the C++ world every major company has built their own, in-house, closed-source implementations of the same shit. I'd _love_ to know how many different implementations of a linked list in C++ exist in the wild today.

<comment><USER9> >I'd love to know how many different implementations of a linked list in C++ exist in the wild today.

Why isn't the STL linked list enough?

<comment><USER10> Sometimes intrusive linked lists are more efficient and require less cleanup

<comment><USER11> With an intrusive linked list you pay the memory cost of having node pointers all the time. If you're you're going to do that, then you may as well keep all your nodes in a list all the time, and use splice() to move them around. There are practically no performance advantages to using intrusive linked-lists in this case.

<comment><USER12> There is a usability advantage, though: with a STL list, you need an iterator corresponding to an element to move it between lists, not just a pointer to the value. So all functions taking a reference to an object, if they might want to move it around at some point, need to take an iterator, and in particular, object methods cannot do so, unless the class contains a wasteful iterator-to-self field.

Intrusive lists also allow an object to be in multiple lists at the same time (usually ones with different purposes) by having multiple sets of prev/next pointers.

<comment><USER11> Boost multi_index solves both of these problems. To simulate multiple lists you can simply add more than one sequenced index to the container type. The sequenced index interface provides an iterator_to() method which takes a reference and returns an iterator, and the container interface allows you to project one index to another. It's incredibly powerful.

[http://www.boost.org/doc/libs/1_58_0/libs/multi_index/doc/re...](http://www.boost.org/doc/libs/1_58_0/libs/multi_index/doc/reference/seq_indices.html)

As a bonus the ownership semantics are clear and memory management remains trivial. Intrusive lists are useful, i'll grant you, but they'll always be a last resort for me. Especially if you're implementing them yourself.

</comment></comment></comment></comment></comment></comment><comment><USER13> I don't quite get why the author thinks that wasm will make asm.js irrelevant. As I understand it, what wasm brings to the table is mostly a binary representation of asm.js, with the concomitant size advantages. If they're two different ways of encoding the same thing then I'd expect most toolchain and optimization work for one to benefit the other, and asm.js will continue to benefit older browsers for a while.

What made asm.js a breakthrough was that vendors couldn't kill it by ignoring it - it's just Javascript, so it doesn't need explicit support to run, so ignoring it just hurts you in competitive perf benchmarks. Wasm IMHO is a smaller step forward, but I think the mapping is direct enough that a polyfill lib can handle deserializing wasm to asm.js - not ideal, but at that point it's unkillable again. Very different from {P}NaCl, which was very successfully killed by everyone except Chrome ignoring it.

DISCLAIMER: I've read about these techs but haven't had a chance to use them in anger yet; apply pinches of salt to taste.

<comment><USER14> If you look at the WebAssembly github they have a pretty detailed roadmap/plan of what they would like to accomplish. In the beginning it is essentially what you just stated, but after that initial goal is completed they are looking to start diverging from asm.js and begin adding in more features.

</comment></comment><comment> aaron-lebo A few thoughts:

I was all aboard the ES6 hype train before I realized that ES6 was one of many stops. Yes, the ES6 standard may be double the size of ES5 but most of the features were also necessary.

ES7 seems like it will be a sizable change as well, and as the author points out, JS seems to be destined to design by committee. The other aspect of this, which the author points at but never says (JS is C++ and they prefer minimalist languages), is JS is stuck with backwards compatibility issues. ES6 adds proper scoping with let but can't completely remove var due to lots of old code. How do you handle that?

You can't be too upset about asm.js becoming irrelevant because it was a rough draft of an idea and WebAssembly is an improvement on that. Better we fix those mistakes now instead of waiting 20 years to build on an already adopted but unsteady foundation (ala JS?). Despite some issues that might bother them (like feeding an AST instead of a CFG), hopefully WebA does its job well and lets us use those minimalist languages already mentioned.

</comment><comment><USER15> > There are a number of semantic inconsistencies in JavaScript that need > fixing, but the ES6 and ES7 additions do nothing to fix those, they merely > add new features (read: complexity) to the language.

This, one hundred times. The current excuse for JS's surprising behavior is legacy and the fact that it was built in ten days or something.

Now that we are not in such a hurry, could we please fix the thing? It's not like new ES6 code is backwards compatible anyway.

I'd argue that we don't need many of those features. Lua is tiny, has a tiny interpreter, has a fast compiler (LuaJIT) and has been resisting new language additions and doing fine anywhere it's deployed. It helps that it has a nice design from the start.

But it doesn't have brackets and semicolons. People just love those, it seems.

<comment><USER16> JavaScript can't fix the legacy issues because of backwards compatibility. Not in terms of making ES2015 code work on old browsers, but making old code work on new browsers.

<comment><USER17> I agree with the first sentence but the last part seems incomplete. Were you thinking of the difficulties bridging old and new code running in the same app? I like the idea of an opt-in "use modern" to avoid breaking old code but that would get tedious if you needed to call between old and new code in the same app.

</comment></comment></comment><comment><USER11> C++ isn't terribly large. The current language, i.e. the standard excluding the standard library, is about ~700 pages. Smaller than Java. The standard library, as of C++14, is also tiny (but growing rapidly)

Imho, the perception of C++ as a large language comes principally from the high combinatorial complexity of its feature-set. It is very much a toolbox language. C++ advocates have only just recently started preaching a collective 'Pythonic' or 'Rubyist' way ("modern C++"). It is, however, still very much a broad church, with less philosophical baggage than many other languages. Strong and differing opinions on the committee seem to keep a single dictatorial programming style from emerging.

Tbh, I don't know what the author is worried about. Does Javascript have an overriding mindset/philosophy that is being eroded? Is that the concern? Other concerns about implementations not keeping up don't seem well-founded.

<comment><USER18> Are you serious? Even if we stipulate that Java is as big or bigger (I don't think anyone would say Java is more complex), what other mainstream language is as large or as complex as C++?

<comment><USER11> I said it wasn't large, not that it wasn't complex ;)

</comment></comment></comment><comment><USER19> "Still, it seems to me that in the web world, nobody takes the time to pause, breathe and think things out for even a moment."

Hey, how about that, another person who thinks this. And this from someone who read the entire ES5 specification and built a JIT compiler for JS. She gives a good example of the web moving too fast. Already asm.js is obsolete and it didn't even mature enough to be used. It's starting to feel like complexity for complexity's sake.

Java and JavaScript both had a chance to win in the early days of the browser wars. JS came out on top, and it was vastly simpler than Java. Now they want to turn JS into Java. Maybe this will be the opening Google's Dart needed to take off.

<comment><USER2> It does feel fast for asm.js, but WebAssembly is simply much better than it. We did asm.js because there wasn't an option to do something better earlier; now that there is, with all browser vendors eager to collaborate, it seems pointless to delay.

Also, this evolution should not be too disruptive. First, asm.js content will continue to work, since it is just JS; it will also continue to be fast (in fact, WebAssembly will polyfill into asm.js in the short term). Second, tools like Emscripten will be able to emit both asm.js and WebAssembly, so that those users don't need to even care about what their compiler is producing (and those users are the great majority of people using asm.js on the web).

<comment><USER20> >Second, tools like Emscripten will be able to emit both asm.js and WebAssembly, so that those users don't need to even care about what their compiler is producing (and those users are the great majority of people using asm.js on the web).

The problem is around the API. I know you do your best to provide a platform similar to native (with fopen(), sockets, SDL...) but I wonder if it is not simpler to do that with a VM (a kind of kernel for emscripten) ?

From time to time, I look at qemu source code to find a solution. Originally, Fabrice Bellard did a standalone libqemu but it was removed. There is the SPLICE protocol too for the graphics or even VNC.

I'm thinking of a layer that do not rely on the DOM or emscripten JS pragmas. Thus we could have a world of lightweight linux/bsd distros for the web.

PS: I've seen your work on musl and signals.

<comment><USER2> Not sure I understand the problem - what is the issue with APIs?

WebAssembly will have the same API access as asm.js, both can call into JS (and JS can then access any web API).

<comment><USER20> API are OK but they are tedious to implement. You have to discover the good way to manage each subsystem.

I think of something more low level for a VM that could run inside a web worker (or in the main thread).

It's visible interface could be (with ArrayBuffer):

\- an address space for a virtual framebuffer

\- an address space for a virtual disk

\- i/o with ports for sockets, mouse, keyboard ...

With that, we could use existing OS. There is too much case to implement all the existing API and each case can be complicated and have implicit assumptions.

For example, instead of mapping fopen() paths to localStorage or URLs in XHR, we could implement an existing hadware API for disk storage.

Instead of implementing SDL, implement a VGA memory.

I think it is more reliable to use on the lowest interface and you can reuse all the stack (from the kernel, to GNOME and Firefox, all inside the browser).

The rules of mapping what to what will be defined outside the VM. The browser could be in charge of these rules.

The rules are:

\- save this address space to localStorage (or IndexDB)

\- send this address space in XHR (or websocket)

\- put this address space to this canvas (with putImageData())

I had this idea after reading a spec of a VM for a Forth:

[http://retroforth.org/docs/The_Ngaro_Virtual_Machine.html#i-...](http://retroforth.org/docs/The_Ngaro_Virtual_Machine.html#i-o- ports)

I'm not criticizing your work nor emscripten at all. I'm a big fan :-)

It's more about making the things simpler, get rid of the complexity, increase the features and liberate everybody of the burden of mapping native API to Web API. It's like Cygwin vs qemu/kvm.

I'd like to help emscripten and I see that.

<comment><USER2> Making a new set of APIs like that would need to be done very carefully, to keep the web consistent and also to make sure it is sandboxed properly and so forth.

In general the web is actually going in that direction, for example WebGL is similar to low-level OpenGL. But obviously in many other APIs, that is not the case.

There are proposals for various new APIs, like for file storage, but they are each being debated separately. I don't think WebAssembly is going to change anything in that regard - we can propose new APIs for it, but the proposals will go through the usual processes.

<comment><USER20> The solution is somewhere in the qemu or kvm world but qemu deals with real hardware. I'm looking for something simpler than a real machine.

Ideally, qemu could run a virtual cpu just made for asm.js or wasm. The virtual hardware is accessed thru the Module functions. We could have a peek() and a poke() like in the old days to read the ports :-)

I remember your first posts about emscripten and the first script in Python. The gap to fill is similar to "write a backend for LLVM" as you did (not enough, of course).

There is also the x86 emulator from copy.sh ([http://copy.sh/v86/](http://copy.sh/v86/)).

The general direction is "support blobs in the browser".

About implementing new Web API, I think the process is not so slow but it relies on non-technical things (like strategy for the companies) so low level would speed up that.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> Javascript is the only language "of the web" if you want to be blunt about it. Nothing else has ever come close, and itll be challenging to get a concensus on a replacement that wont just compile down to JS anyway.

</comment><comment><USER22> Yeah it is becoming a bit bloated. Honestly I think all they had to do was add import/require and support 64 bit integers and numerics and the language would have been good enough.

</comment><comment><USER23> _> Personally, I'm a big fan of simplicity and minimalism in programming language design. I think that smaller languages have the potential to be easier to implement, optimize, teach, debug and understand. _

After reading hundreds of blogs and articles about this or that programming language being supposedly " _simple_ ", sentences like the above have come to mean _nothing_.

I wish a had a succinct meme to describe what actually happens in the real world around "simple" languages but the concepts are:

If there's a "small" or "simple" FORMAL language specification, it means there's a "large" INFORMAL language out in the wild. The "informal" will include things like idioms, patterns, macros, code generators, industry practices, "utility" javascript libraries, etc.

For example, take the concept of "classes" that supposedly nobody needs in Javscript (because protoype chains are superior). What is the longest most complicated chapter of Nicholas Zaka's Javscript books[1]?! It's the long chapter on manually simulating classes using prototypes! Same situation with other books that describe home-grown "modules". Even if one chooses to avoid simulated classes in his own js code, one still has to understand the different variations that others write. If classes are not _formally_ specified in the language spec, it's _informally_ specified in everyone else's books, stackoverflow answers, blog articles, and youtube videos explaining js simulated classes. If Javascript had "classes" earlier than ES6, perhaps the over abundance of informal adhoc "class objects" would have been completely avoided.

Another example would be "optional default" function parameters. Since javascript's _formal_ language spec doesn't have a feature for default params, it is "simpler" and "easier to learn". (Hey, if one doesn't have to memorize the keyword "optional", that's one less thing to worry about, right?) Hmmm... really?! Look again more closely.[2] The "optional" feature is simply moved into an idiom (multiple idioms!) that all competent javascript programmers must learn. The "smaller" language hasn't saved any complexity -- it does the opposite -- it made JS usage _more_ complex overall.

 _Any_ language that's used for non-trivial purposes will not be "simple" if looked at holistically by combining both the formal _and_ informal real-world uses of it.

However, within that unavoidable complexity, there can be limited subset cases of "simple" for certain scenarios. What does one want a "simple" Javascript language spec for and what can it do? Make the monkey dance?[3] Ok, that's one mapping of "simple" to an end goal and 1995 Javascript specification is probably enough. However, people want to do much more complex apps with Javascript without having to mess around with Typescript, Babel transpiler, etc.

To blog writers: please stop characterizing languages as "simple" without any qualifications of use cases. That adjective is no longer convincing on its own.

[1][http://www.amazon.com/Professional-JavaScript-Developers- Nic...](http://www.amazon.com/Professional-JavaScript-Developers-Nicholas- Zakas/dp/1118026691)

[2][http://stackoverflow.com/questions/148901/is-there-a- better-...](http://stackoverflow.com/questions/148901/is-there-a-better-way- to-do-optional-function-parameters-in-javascript)

[3][http://programmers.stackexchange.com/a/221658](http://programmers.stackexchange.com/a/221658)

<comment><USER24> > What does one want a "simple" Javascript language spec for and what can it > do?

To write proofs? You don't need to worry about the larger idiom of how the language is used for that.

And to write a _correct_ implementation of a language you don't need anything except a correct simple spec. To perform well for idiomatic code you may need to know about idiom.

<comment><USER25> > To perform well for idiomatic code you may need to know about idiom.

To enforce idioms you include them in the language. This makes the language easier but less simple. It also means people will use exactly one idiom instead of lots of variants. This improves performance and makes it more predictable.

To perform well for idiomatic code you must know about idiom and have consensus about it and teach it to everybody.

</comment></comment></comment><comment><USER26> Since C++ was malinged by the author, I thought this quote relevant.

 __ _" There are only two kinds of languages: the ones people complain about and the ones nobody uses"_ __\- Bjarne Stroustrup

Source - [http://www.stroustrup.com/bs_faq.html#really-say- that](http://www.stroustrup.com/bs_faq.html#really-say-that)

</comment><comment><USER27> > _Personally, I'm a big fan of simplicity and minimalism in programming > language design. I think that smaller languages have the potential to be > easier to implement, optimize, teach, debug and understand._

Citation needed.

Python is a popular first / teaching language and it has as many (and probably much more in 3.5) features as JS.

And Scheme is supposedly simple, but not that popular with any large amounts of people, beginners included.

There are features that interact in mysterious ways and can be difficult to master (C++ has a lot), and features that are mostly orthogonal (e.g. template strings don't complicate anything related to arrow functions and vice versa).

What I'd like to see, with regards to Javascript, is for "strict mode" to extend to the correction of old, long standing warts (e.g. crazy coercion rules etc). But I guess with this new shared "bytecode" for the web announced, we probably wont have this problem for long.

<comment><USER28> Why does someone need to provide citation for expressing their opinion on something that's even so obvious as "I think simple things are easy to teach and understand, etc.". Do you think complex languages are simpler to teach, debug, optimize, and understand?

<comment><USER27> > _Do you think complex languages are simpler to teach, debug, optimize, and > understand?_

Obviously yes, I do think it, and I gave an example.

Or rather, I think that number of language features is not related to how easy it is to teach, debug, optimize and understand.

Python has tons of features (maybe even more than ES7 for which he laments) and yet it's an easy to teach and understand language.

And inversely, C is succint and has few features, but it's complex to teach and debug.

One key insight it: a language might be big, but you don't need to use all of its features (or even teach them all).

You can start someone with basic Python, for example, without delving into async or metaclasses and he can still do tons of stuff. Contrast with the "simpler" and much smaller C, in which he needs to understand pointers (a tricky subject) in order to even use the standard library.

A second insight is: a language might be big, but its features could be orthogonal and easy to understand in isolation, not the "features subtly affecting each other" mess C++ is.

</comment></comment></comment><comment><USER29> I'm afraid I have to concur with the article's title and most of its contents.

Instead of letting developers code in a sensible language and simply making JS a better compiler target, the language was bloated with cruft to support manually writing it. For a notoriously overburdened language like JS this is definitely the wrong direction. Like with C++, you now have to judiciously choose which features of the behemoth to abuse and woe betide you if you choose unwisely.

Don't touch JS with a ten-foot pole, let a compiler do this dirty work for you.

</comment><comment><USER30> Interesting perspective. I've been sort of on the other side of the fence and excited about new features. With that said, I do love the simplicity of C and how the features of the language itself are very minimal and learning all of the language is fairly simple task.

Do you think maybe the push for the extra functionality is an effort to standardize the millions of JS libraries out there that do this "high-level" functionality already, rather than leaving it up to the user for interpretation?

<comment><USER7> It's sometimes painful trying to even approach standardizing on a given framework of tools... I've been using babel + browserify and leaning on whatever shims it provides... I mean, even if I limit myself to lodash/underscore, bluebird, and jQuery, I've got a lot of overlapping bits in there... swap jQuery for react and my composition becomes a lot better, but even then I'm using either the ugly method invocation, or creating derived classes (which makes me feel dirty for some reason).

Look at even a modest node.js project, and dig into your node_modules tree, it's amazing how many different modules wind up in your codebase to do the exact same thing(s). Ramda, lodash, underscore all in there, and hopefully not all leaking into your client-side.

Hell, I'm working on a project now that has both jQueryUI and Bootstrap components in play... and a dozen or so extensions/modules for each of them.... It's pretty ugly pretty quickly. And I don't think the likes of Component or Polymer are all that better in practice. The more that starts to be in the box, and the better people understand it the better in a lot of ways.

</comment></comment><comment><USER31> On the one hand:

Who cares!? You don't have to use every feature of a language.

On the other hand:

What do you expect when something is designed by committee? Everyone wants to add their own special sauce to the mix.

<comment><USER32> Unfortunately you have to know every feature to read or troubleshoot.

Someone claiming to never be mystified by an obscure incantation of c++ either is lying or hasn't looked very much. I suppose something had to be invented to make bad perl look crystal clear. Insert bad joke here about not needing a contest to have a obfuscated c++ competition.

</comment></comment><comment><USER33> ASM or WASM, I expect a future where both of them are included in the head of the document by two different developer and I have no choice but to maintain them.

</comment><comment><USER34> _" Mozilla and Google are already working on WebAssembly"_

She picked her favourite companies, I guess :). The reality:

 _" The team working on WebAssembly includes people from Mozilla, Google, Microsoft, and Apple"_ [https://en.wikipedia.org/wiki/WebAssembly](https://en.wikipedia.org/wiki/WebAssembly)

</comment><comment><USER35> I'm happy about the changes that are being made to JavaScript. For new code, stick to a modern subset of the language and enforce it with a linter. It's not ideal, but I'd rather live in a world where ES6 and ES7 features exist than one in which they don't.

</comment><comment><USER36> I once listed to a talk about a "new" JS (don't know witch one. I guess it never was adopted)

It started with explaing all the ugly part of the DOM: Variables that are constant, variable that are more like setters, variables that don't show up in a for(x in y) loop.

I was very exited. Are they goning to fix all this ugliness? Tidy up that crap?

NO! They said: "We want to be able to implement the DOM in JS. That's why we are going to add all this crap into JS". I have no idea from what perspective this makes sense. It's not just that I think it's a bad idea, I have no clue how anybody else could come to the conclusion it was a good idea. This was a way worse than C++. But I think in the end it didn't happen.

</comment><comment><USER37> At first glance I thought he meant it was the C++ of the web by popularity. This will probably be the typical pattern of widely used programming languages. Adding features until it is time to start from a clean slate a few decades later.

<comment><USER38> 'he' is a she.

<comment><USER39> At a quick glance, I can see no byline that might give me a clue as to the correct pronoun of the author. What would you recommend as a neutral pronoun in these cases?

<comment><USER32> English will be a pro drop language sooner or later, may as well get used to it. Will not be much of a loss (not lack of it). When spoken, inhale during "pronoun break time" and nobody skips a beat.

"At first glance I thought meant it was the C++ of the web by popularity"

<comment><USER40> I wonder if this is a reanalysis of initial clipping. English lets you do some pretty aggressive deletion of initial segments of an utterance, and in many many cases that ends up being just a pronoun.. hmm

</comment></comment></comment></comment></comment><comment><USER41> * If JavaScript is really "the assembly language of the web", then why does it need all these high-level features?*

Someone should introduce this dude to the novel concepts of "figures of speech" and "metaphors" as he's completely clueless losing the plot.</comment>


I hate almost all software (2011) - <AUTHOR> http://tinyclouds.org/rant.html <comment><USER2> The older I get, the more I agree with this rant. I used to be that guy putting cute unicode checkboxes in his test runner, telling myself I was making the world a better place because my software was nifty and clever. Now, I realize that, while that's nice to see, my time was better spent just solving the problem and then moving on to the next problem. Nobody was dying for animated tick marks and I probably ruined someone's experience because their terminal emulator or multiplexer had shitty unicode and escape code support.

It's a delicate balancing act, of course. The tinkerers are often the ones pushing tech forward with their incessant fiddling. But it comes at such an incredibly high cost. I mean, how many _human lifetimes_ have been consumed by the shitty intricacies of dynamic linking alone. And for what? To solve a class of problems we haven't really had since 1992?

What a waste.

There's ample space in the software world for all kinds -- and arguably the industry is fueled by the blood of well-intentioned innocents -- but my increasingly jaded self just wants the shit to work so that I can close my laptop and get outside with my kids. The guy who spent 15 hours a day obsessing over The Right Way and code purity and ecosystems has aged into a man who firmly believes that less is much more, cuteness is a code smell, and solutions should be as self-contained as humanly possible.

<comment><USER3> The trouble is that the tinkerers learn to cope with the idiosyncrasies of the legacy systems and build their shiny new stuff on top of them. In the end, we get software that solves a relatively simple problem but depends on layers upon layers of other systems and abstractions.

IMO, we need to fundamentally rethink the design of our computing infrastructure so that it suits our current way of using computers. This would start from the CPU microarchitecture and instruction set, through the programming interface of the operating system, up to the middleware used by most programs.

<comment><USER2> I'm sympathetic to your point of view, but Big Design Up Front never works, in my experience. It's impossible to anticipate future uses for tech that we currently consider vestigial, unnecessary, or inefficient.

Mainframes and terminals were the future until PC displaced them, until the web came along, until mobile and cloud computing smashed it all and brought us full circle (sorta). Designing to optimize the full stack for one of these iterations would have made the transition to the next phase much harder. Fewer people than you'd think foresaw the IoT, FPGA, Arduino, processors-in- everything revolution currently underway back in the early 2000s, when Moore's Law was still gospel.

In the end, I take a sort of Buddhist view toward the fuckedupedness of software: It sucks, but it's all we've got and must be accepted on its own terms. Find a strategy that works for you and that minimizes global pain. Do no harm. Attempting to force your way into Nirvana and out of Samsara only wedges you deeper inside it.

<comment><USER4> "Big Design Up Front never works"

Seems to work for NASA and others doing way more complex projects than I am .

<comment><USER5> And yet people praise SpaceX for doing much better and cheaper with their iterative refinement.

BDUF can work if you have a single organisation with a single stable set of requirements that's reasonably compact. The Kennedy "man on the moon" speech was such an example.

Where it falls down is trying to meet the needs to the 7 billion distinct human individuals, which are inevitably vague and shifting and change in response to publication of software.

<comment><USER6> SpaceX also doesn't have the track record NASA does, and cannot be compared.

In 50 years when they've been working alongside each other, maybe, but not right now.

<comment><USER7> NASA has also used iterative refinement in the past.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I share this sentiment. As a user, I have found some relief by switching to a very simple setup with just a WM (XMonad), a browser (Firefox+vimperator), Emacs and a terminal (urxvt, which I only use occasionally).

Previously, even though I used Emacs as an editor, the idea of moving functions that correspond to applications (like mail reading) into an editor looked clunky and even dirty to me.

But I grew disillusioned of the Unix ethos. While it works well for composing very simple programs, it fails to deliver on most other things. For example, Mutt is a great mail user agent. But it is very difficult to customize beyond its author's original intentions using its own little configuration DSL. And scripting it from your shell does not lead anywhere. This happens with many other nice Unix utilities.

In contrast Emacs, understood as a text-mode Lisp machine, is at odds with this approach. The code you write is as first class as the code you run from whatever module you import. Everything is alive, integrated, and can be changed.

As a programmer, I am moving towards more and more abstract application domains for the same reason. Mathematica, PyMC or Scheme allow me to ignore all the horrid details the OP describes and work at a higher level.

<comment><USER9> I love the ethos of Scheme.

The language has ways that the program is expected to do things, such as named let and syntax-rules, but is flexible enough to get out of your way if you have a different idea, such as defmacro.

I wish that the rest of my userland would be as flexible.

<comment><USER8> You can always use Emacs and treat all low level things as plumbing. Eventually Emacs will hopefully switch to Guile Scheme. In any case Emacs Lisp is a pretty good language and would not feel clumsy to an Scheme hacker, I think.

You can have a pretty modern userland with Org, Gnus or mu4e, pdf-tools, etc.

I have recently switched to GuixSD after 2 years toying with NixOS. All dirty Systemd plumbing fades away and gets replaced with a minimal service manager written in Scheme, GNU Shepherd. Plus all packages are defined in Scheme. It's very refreshing.

I hope one day we get to see a cleaner kernel, ABIs and compilers. Things have gone a bit out of hand.

<comment><USER9> I'd rather not have Emacs as my environment. I really wish that something like Gnome worked as well as Emacs to be customiseable and extendible, and in fact that everything in /bin would share a cohesive, modular and programmable interface, preferably Scheme, but I'll settle for something sensible.

Emacs, and to a lesser extent, sch, are a nice first step to making a nice environment. But they still feel ten years old, or more. I use TUIs, and appreciate them. But VLC and my window manager should be beholden to the same level of control and interactivity.

And yes, I am never satisfied tweaking my system to my preferences, because I always hit roadblocks before I get there.

(I am totally fine with the kernel, and compilers and the like using "dirty" code -> that's one of the easiest ways to reach a damn fast system.)

</comment></comment></comment></comment><comment><USER10> I don't think this is a software problem. It's a general legacy systems problem. Think of self-driving cars. It seems plausible that one day all cars on the street will be self-driving, at which point the existing system -- which was designed for humans -- is a legacy system that is not efficient for the current users. If you were to design an autonomous transportation system from the ground-up I doubt, for example, you'll put in stop signs that cars have to read via machine vision. You'd probably have that information somewhere on the internet (or better yet, design something from the ground up that doesn't require stopping).

You can see how this translates to computing. The reason why I still have to deal with a `document` object while building apps in JavaScript is because we built an application distribution platform on top of a document viewer. There is no centralized planning here -- we're just riding a wave of distributed innovation and making the best out of it. (Nor should you expect centralized planning in technology to emerge unless a superintelligent AI system takes over).

<comment><USER5> Javascript is the app distribution platform that _won_ , because the others were worse.

ActiveX? Too much lockin, no sandbox. Java applets? Too heavyweight. Flash? Nice tooling for the producer, _terrible_ security record. ClickOnce/Silverlight? Never really got out of the gate and would have been MS/Win only.

The next generation of app distribution is "app stores" with arbitrary refusal policies which take a 30% cut of sales. A success for Apple.

Javascript _mostly_ delivers "write once, run anywhere", albeit through a vast shifting layer of shims. Its sandbox is pretty reliable. It's not owned by anyone and they can't stop you shipping JS apps. Thus it survives.

<comment><USER10> I agree with most of what you said but you're conflating languages and platforms. JavaScript as a language says and does nothing about sandboxing. It's the browser that does that. It doesn't even specify anything about concurrency (up until promises maybe) or the event loop. The event loop is a feature of the host environment. When Netscape put JS on the server they used in CGI mode.

So I wouldn't completely remove the browser from the picture. Had it been Lua or some other simple general purpose programming language that was the language that ran in the browser I'd say it would've been the JavaScript of today.

(I think one other component of this is "worse is better". JavaScript was easy to copy and implement, although not elegant or the best designed language)

</comment></comment></comment><comment><USER11> Much of what he's complaining about is a failure to obey a rule that appeared in the original Macintosh User Interface Guidelines.

 _" You should never have to tell the computer something it already knows."_

For example, users should never have to type in a pathname. The user should, at worst, be offered a list of workable alternatives from which they can select. Expecting the user to manually typing in a value for "$LD_LIBRARY_PATH" fails this test.

The original Macintosh software had applications which were one file, with a resource fork containing various resources. This kept all the parts together. UNIX/Linux and Windows never got this organized. Hence "installers", and all the headaches and security problems associated with them. The Windows platform now has "UWP apps" with a standard structure, but they're mostly tied to Microsoft's "app store" to give Microsoft control over them.

<comment><USER12> Doesn't packaging each piece of software as a single file lead to a security disaster? When openssl has a vulnerability, suddenly the end user needs to upgrade multiple applications, and that is assuming that all of the developers have actually built the upgraded software.

<comment><USER13> That's also the one reason why I'm very reluctant to throw shared libraries out the window.

<comment><USER14> Ok, security-critical stuff as shared libraries (libjpeg, libz, libssl, etc).

Why do we package the other stuff as shared libraries too? GMP, GtK, Qt, OpenCV, SDL, BLAS, ...

<comment><USER15> The original motive for adding shared libraries to Unix was so that X11 would fit in memory on the machines in use at the time (according to a comment I read many years ago).

If the use of shared libraries saves on memory, it probably also saves on L3 and L2 cache, so on the aggressively cached CPU architectures of today, replacing a shared library with a statically-linked version might slow things down by decreasing cache hit rates.

In particular, if every KDE application is statically linked to Qt, then when KDE application A's time slice ends, whatever parts of A's copy of Qt are in cache will be invalidated with the result that if B wants one of those parts it will have to fetch it from it's own copy of Qt in memory whereas if A and B shared a copy of Qt, the fetch from memory could be avoided.

<comment><USER14> Has anybody actually measured it in the last decades?

<comment><USER15> I don't know.

But we know that Intel and AMD design their CPUs to go as fast as possible on the operating systems people actually use (Windows, Macos, Linux) all of which use dynamic linking. Plan 9 is the only OS I know of that does not support dynamic linking (and Plan 9 simply does not have large libraries -- they have what they call services instead, which are similar to souped-up Unix daemons).

Linux and Windows in turn are designed to run as fast as possible on Intel and AMD hardware.

After a few iterations of this sort of mutual evolution, it starts to become very unlikely that a change as big as switching a bunch of big libraries from being dynamically linked to being statically linked would actually improve performance because lots of optimizations have been made to squeeze a few percentage points of performance out of the existing system (which includes the practice of shipping most large libraries as shared libraries), and typically those optimizations stop working if there are large changes in the system.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> Sounds like someone had a bad day.

Software developers are in a strange position in that they create the world they live in, so any warts seem magnified and self inflicted. But any significantly advanced discipline is going to be complex. Physics, chemistry, and biology does not have the same luxury of being "rewritable." They operate in the natural world, so you curse God and not Man.

Rewriting a software system from the ground up is nearly impossible. Also any sort of system will need to maintain some level of backwards compatibility, which induces complexity. Thinking about an operating system as something that was built according to a grand design is wrong. They evolve over time, written by different people with different styles solving different problems.

A counterpoint to this argument, "It's harder to read code than to write it."

[1] [https://www.joelonsoftware.com/2000/04/06/things-you- should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never- do-part-i/)

<comment><USER17> He is the creator of Node.JS

<comment><USER18> True. But Maybe he did have a bad day? Like a promise that never resolved or something...

</comment></comment></comment><comment><USER19> In my workspace sometimes people think I'm off to kill their buzz whenever they bring up the topic of introducing another library into our stack because it solves a specific section of our problem-space.

The real value and fun imho is solving complexity _in your head_ , and then coding down a solution that is simple and uses the least number of moving parts as possible.

And _yes_ , we programmers are also humans and we sometimes like to cherish our creations in non-productive ways, so if you code something simple and well thought out, it will be almost always come out _elegant_ and _concise_ , and you'll be able to pat yourself on the back at the end of the day for building something solid.

I don't believe solving something is _all about the user experience_ because there are humans on the back pulling levers and making that solution happen, so there's that.

<comment><USER20> Wonder how much of that is because the MBA beancounters use LOC as they productivity measure, as if programming is the same as a widget factory.

</comment></comment><comment><USER21> I live in a VS .Net bubble and avoid this Linux, C, native etc. stuff like the plague. No environment variables, no scripts, no dependencies except things that have a real and obvious purpose, all native interop isolated to its own small ugly files that I don't touch.

Sometimes I want to use an open source library or something and it's honestly days of fighting with compiler flags and environment variables and versions of compilers. There's always undefined symbols or other mystery failures. Last time I did this, the makefile failed because I was getting a source file from a badly configured web server that caused the downloaded file to get corrupted with some downloaders but not others. So there's learning about idiosyncrasies of the HTTP protocol too. It's a complete clownpants nightmare of wasted time.

<comment><USER22> Funny, I feel the exact same way about the windows world. The few times I've ever had to touch a windows machine, someone tells me \- "Oh just reboot it to fix that microsoft problem." \- "Oh the system update must have been corrupted, reinstall the OS." \- "Oh just go download this rando .exe using your browser that isn't signed or open source, that tool will be able to fix your problem."

I just wonder how that could ever possibly be acceptable.

You don't even have to reboot a Linux machine to upgrade the kernel nowadays for crying out loud.

<comment><USER23> But then, I hear Linux people talk about systemd making their system unusable, and having to recompile the kernel to make network cards work, and laptops never waking up from sleep, and reading the arch wiki to find which bizarre kernel options to pass to make CPU low power modes work, and (yesterday) having to update the kernel to make chrome work.

I'm not saying these are all real problems, just that if you only hear the bad, it sounds terrible!

<comment><USER20> Outside of systemd, that is hardware related. And hardware is a pain because most of it is made with barely any testing towards Windows. And Microsoft and standards are on a "best effort" basis.

Thus you get odd behavior in hardware trying to match "extended" behavior in Windows, that is then papered over by the binary only driver shipped with the product initially. None of that being available to the Linux devs trying to get things to behave sanely.

The systemd issue is quite different, as for many it seems to be making Linux more Windows like. And they specifically turned to Linux in the first place because they could no longer stand the cryptic errors and "heisen-bugs" that was daily life while using Windows.

Linux before systemd was to them a land of predictable computing. If something broke the error would point you in the right direction for a fix. And once it was fixed it stayed fixed.

</comment></comment></comment></comment><comment><USER24> I both agree and disagree with this. We're not paid to create new things, we're paid for our suffering - to drag ourselves through the nails and glass shards of previously existing code to accomplish a thing. In that respect, I don't see learning the details of a programming language or a tool as a waste of time - it's an investment to make sure I get less glass stuck in my body next time.

<comment><USER25> > We're not paid to create new things, we're paid for our suffering

Even I wouldn't phrase it that negatively - instead, we are paid for getting features created, no matter what it takes. Sometimes it is bliss, sometimes it's the seventh circle of hell. But in either case, it's our job to just get it done.

</comment></comment><comment><USER26> It's crazy to think from this came NPM and from that came left-pad. I can't reason about this, I can't understand the evolution in any other way than Chaos.

Is this the best we can offer as engineers. We launch our beautifully crafted boat into the ocean only to watch with despair as is taken and swamped by the waves and the enormity of the sea?

<comment><USER27> > _I can 't reason about this, I can't understand the evolution in any other > way than Chaos._

I think the most fitting description of the process in our industry would be "throwing shit against the wall and seeing what sticks".

</comment></comment><comment><USER28> > In the past year I think I have finally come to understand the ideals of > Unix: file descriptors and processes orchestrated with C. It's a beautiful > idea. This is not however what we interact with. The complexity was not > contained. Instead I deal with DBus and /usr/lib and Boost and ioctls and > SMF and signals and volatile variables and prototypal inheritance and > _C99_FEATURES_ and dpkg and autoconf.

The next step is to understand that file descriptors and processes orchestrated with C are a substrate that would make everyone reimplement most of what they want from scratch each time. Part of the list describes system services that we have come to expect from an OS: DBus = interprocess communication; signals = process control; volatile variables and ioctl = hardware control; /usr/lib and dpkg = software packaging and distribution. There are more to be added. at+cron = scheduling. syslog/journald/systemd = monitoring; wall = alerting; cgroup = process and process group control; bash = orchestration from a repl; systemd = orchestration not from a repl; lots of stuff = security; every developer's own file format = configuration; every developer's own plain text protocol = data encoding for IPC. The list goes on from here. Even in the early days of Unix, mature systems like VMS had these capabilities.

The problem is not that these exist. It's that they were all built piecemeal instead of being standard system services accessible from a programming language like processes and file descriptors.

Except for bash. That's the result of an old mistake: the job control language on OS/360\. That's when we got the idea of a command language distinct from a programming language, and we've been building it back towards a programming language ever since.

Autoconf, though, is purely penance for the sins of the past.

</comment><comment><USER29> "The only thing that matters in software is the experience of the user." is going on the wall in the office. And I'm mailing one to Android development team.

<comment><USER30> That statement seems simple and correct at first, but the term "user" is not well defined. Even if there was only one user in the world, me, it still isn't well defined. The reason being that I can't tell you right now at this moment about all the possible use-cases I might have for some software in the future.

<comment><USER31> I think what this statement really means is that we all create software for the end user, but then get lost in all the theory and principles of software engineering that often drag out software projects and make them overly complex. The point at the end of the day is that "it's all about delivery" and we need to remember that without the customer/end user, we're just wasting everyones time moving bits and bytes around because we can.

</comment></comment></comment><comment><USER32> So we are against perceived complexity and learning new things now?

To elaborate a bit: At work I use OLAP functions to simplify the business layer and focus on the data, moving much of the complexity to sql statements. Others get the data in it's list form and complicate the data layer or the business layer by transforming the inconveniently-structured data there. Yet I am the one who is told to tone it down and think simple.

Much like the author of this article, no matter how senior he is, they seem to divine a vague notion of "simple" when they face perceived complexity. And they always seem to associate this complexity with a real life example of something which could have been simplified (like how angry Linus Trovalds got when he tried to set up a printer on linux) which is unfortunately a red herring.

So is NaN equivalent to null? Does that question even make sense? Perhaps the real question is, how do I represent an optional entity without incurring additional runtime costs? C++, one of the most lamented languages for it's terrible template complexity, has no null problems. Most values are copyable, moveable or re-constructable and most code throws when faced with fatal situations where e.g. the OS runs out of allocatable memory to the point where returning null simply vanquishes and you won't see it in production code anymore. Did that solve your complex null problem? Absolutely yes. Did that come with a bunch of baggage you have to learn and implement? Yes it kinda did.

So the complexity is there for a reason. Go is shameless when it comes to nil. Yet Go is mostly called out for it's lack of generics. Ah, how ironic.

Anyway, if it is there in programming, it is probably for a reason and alternatives introduce their own baggage. Usage of POKE or sprite DATA segments did not suddenly dawn on me when I first started to learn me some programming. I did not say it was unnecessarily complex, or question why it didn't work like legos. I just opened the book and reduced the complexity by _learning_.

<comment><USER27> > _So the complexity is there for a reason._

Reminds me of the occasional questions about equality, like "why Java doesn't let you override ==?", or "why Lisp has eq, eql, equal, equalp, and you still end up using your own equality predicates anyway?". The root of the problem being, the concept of equality itself is complex at the philosophical level. It's easy to lament something is complex, it's harder to ask yourself why it is so, and accept that there is complexity in reality itself.

</comment></comment><comment><USER33> I was with it until the last paragraph. One reason for the mess is nobody thinks of downstream developers as users.

</comment><comment><USER34> Twenty-six years of developing software for different organizations yet I still struggle with the desire for simplicity in the face of conflicting needs.

The tendency is to think of a "user" as a lone person in front of a screen using a UI of some kind. This idea of user is incomplete. In addition to people using a UI, for say a university financial aid system, a management chain exists with the need for applications to be modified as quickly as possible with new requirements and with no interruption of service. They need applications to communicate with one another. To meet those needs, developers utilize libraries, frameworks, etc. for modularity and reusability. To insure that nothing gets broken while modifications are made, regression testing must occur. Adding test suites increases the likelihood of uninterrupted service. To help with module interdependencies, developers use package managers. And so the stack of software grows.

I'd call it accidental complexity, but it's not an accident. We are dealing with complex software stacks, often with interdependent modules, because we are trying to meet many different needs simultaneously. I don't see an easy way out of the situation.

Over the years, I've become better at determining when to abstract problem solutions in order to provide for future needs and when to do the minimum possible to get the problem solved. I don't think there is a rule or formula for making that determination. You just have to make mistakes and learn from them.

<comment><USER20> There is also all too often a tendency as treating all "users" as drooling idiots.

</comment></comment><comment><USER35> You know what software I like? Video games. It's a model we should all be striving for. There isn't another category where the experience of the user matters more than anything else.

</comment><comment><USER36> I think dev-ops are often overly complex ... Although most people want too simple programs/computers, if they would just invest some time in them, they would become more productive.

</comment><comment><USER37> This is a bit of a rant so either ignore it or consume the frustration and empathise.

Good enough is a turd in disguise, your desire to deliver enough working software to justify your existence and salary is egotistic and myopic.

Build _sustainable_ software, that will work, for you, your predecessors and successors.

The constraints of the domain are fine and dandy, that's what matters, that's the problem deadlines, delivery and all of that is superficial. Keeping the business afloat for now is a band-aid on cancer if you can't write software in a a way that you in 10 months, 1 year, 3 years will be able to maintain.

Here's the reality, you screwed up, you buckled and allowed the pressures of institutionalised shittyness to constrain you capacity to deliver real value.

Please, everyone lets stop acting like software is some ephemeral joke that we can half-ass, and start being serous about the implications of our actions.

</comment><comment><USER38> > The only thing that matters in software is the experience of the user.

While ultimately true, it's a bit too simplistic, because it presents user- experience as a constant. Done deal. Delivered or not. In reality the user experience is something which will change over time, as the software is updated and evolves to accommodate the additional needs of the users.

If you can't keep your code clean over time, your code will start suck, needless complexity might sneak in, and so will the user-experience start to suffer as well.

A good user-experience, just like the code, needs to be maintained. And thus comes the need to organize the code. And for a developer to bother maintaining the code, and for him to be efficient at it, he should work with tools and within an environment which fits _his_ needs (and accommodates his requirements for a good user-experience). And thus comes fiddling with editor- settings. Etc etc.

Basically this rant highlights a real problem: Software complexity is out of control. But the conclusion does not support the arguments given. Rather his conclusion drives all the things he rants about being wrong in the first place.

I think, in the end, to get clean code, to get rid of needless complexity, there's one simple thing which trumps everything else: You need someone empowered to make the required changes. And you need that person to _care_.

Without that, it's all just us waiting it out, until it starts heading into the abyss. We can already see that with lots of the bigger open-source projects which once fuelled the (small) Linux desktop revolution a decade ago.

So how do we cope?

> There will come a point where the accumulated complexity of our existing > systems is greater than the complexity of creating a new one. When that > happens all of this shit will be trashed. We can flush boost and glib and > autoconf down the toilet and never think of them again.

Maybe we will. But I don't believe for one second that we're going to break the cycle this time around, because finding and keeping someone caring enough for decades to come is a pretty tall order.

<comment><USER20> And this is perhaps why the unix philosophy has such pull, as it suggests an environment where one can make changes and adaptions piecemeal and at ones own pace.

But that suggests abandoning the notion of the DE, and going back to WMs and agreeing on, never mind adhering to, the ways software exchange data.

Something that is the polar opposite of the direction that "desktop Linux" is moving these days.

</comment></comment><comment><USER39> Best blog article I've read on HN in a very long time.

</comment><comment><USER20> That dbus was turned from the Desktop BUS to the de-facto system bus is me an eternal puzzle.

</comment><comment><USER40> Developers are users too.

</comment><comment><USER41> In my opinion, he hates the fact that documentation of stacking things up is very poor. Which is true.

</comment><comment><USER42> Most technology is useless. Its not a product of necessity, but a product of our chosen economic system.

</comment><comment><USER43> Yes, you hate technology because is hard to build it.

</comment><comment><USER44> The author has not articulated beyond - you don't understand how fucked the whole thing is. Terrible writing.

<comment><USER45> That's the nature of a rant, no? It's not a persuasive argument, or an essay. It's the frustration felt in a moment lived.

<comment><USER44> Yes, the essay is a terrible format for capturing life moments. Poems are a forgotten tool from our past that I think work way better. The sentence- paragraph structure is a slave to the period. It leaves no space for attention. Very information heavy. Poems, on the other hand, are like long tracking shots. They are naturally infinite. You can create a moment and stay with it. Note taking, list making, messaging are effective for similar reasons.

<comment><USER46>
      Poems are a forgotten tool from our past that
      I think work way better.

Good point. So here's a haiku which might be applicable to the post in question.

      The Master laments,
      When those who produce oysters,
      Declare "find the pearls."

</comment></comment></comment></comment><comment><USER47> I see the reason for the complains, but I do not agree with the basic premise. It should not be "I hate almost all software", it should be "I hate my employer and the job I am stuck in".

I mean, this person is writing for Solaris/Illumos (judging by SMF references and autoconf complains). Yeah, running modern stuff on solaris sux, unless you have a sysadminny mindset. This is clearly not for him. Fine -- different people like to optimize different things: user experience, internal code beauty, maintainability, code robustness, number of platforms supported.

No one should be forced to work on stuff they don't like. There are lots of jobs, and most of them do not require SMF, DBus, /usr organization, or volatile variables.

<comment><USER48> > This is clearly not for him.

Haha I had a good laugh. He created node.js.

<comment><USER22> So what? It probably started off as a fun hobby project like "I bet I can write a fast server in javascript." That was probably all he was interested in at first. Now he deals with problems that are not fun and not anywhere near that original hobby. These problems are clearly not what he considers fun at all, therefore I don't see any reason why you had to be snarky with the OP.

<comment><USER48> Node was written in c++.

Not even sure if you read the original article, because that's far from what I took away from it. I guess we all choose to see what we want to see.

There's a difference between someone complaining when they are bad at something, and someone complaining when they're good at something.

</comment></comment></comment></comment><comment><USER49> Maybe you should stop thinking of code as solving problems and more like painting a picture. It doesn't matter if there are mistakes or if you've done everything perfectly, as long as you've created something cool.

It's like telling a room full of artists that you hate almost all art because the tools available etc etc over complicate painting a simple picture whose purpose is to fulfill a client contract, etc.

<comment><USER46> Here are a few software development maxims which I believe you, or others reading this comment, may benefit from:

      Software is the manifestation of a solution
      to a problem.  Define the problem which needs
      to be solved.

      Developers can test their solution or Customers
      will.  Either way, the system will be tested.

      Only progress a system from a known working
      state to the next known working state. If the
      current state of the system is unreliable
      (IOW: "buggy"), peel back the existing logic
      until it is in a provably working state.
      Only then reintroduce removed logic (in
      adherence with the above) to reach a working
      state where additional logic can be introduced.

And, yes, it _does_ matter "if there are mistakes" for the vast majority of software systems. Perhaps not those with which you've been exposed, but for many this is the case.

HTH

<comment><USER50> Known working state ... That's a key argument against systemd. It's not inherently deterministic.</comment></comment></comment>


J.C. Penney Faces NYSE Delisting - <AUTHOR> https://www.cnbc.com/2019/08/08/jc-penney-faces-nyse-delisting.html <comment><USER2> Its like the end of an era. Before then there was Woolworths.</comment>


Do nice guys come second? - <AUTHOR> https://www.1843magazine.com/features/do-nice-guys-come-second <comment><USER2> As mentioned in the article and countless times on HN:

 _Many people in Silicon Valley are biased against Lyft because they think that ride-sharing will be a winner-takes-all market. They are probably wrong. Once a ride-sharing company gets to a certain level of reliability and waiting times are short enough, there is little benefit to using one service over another. Uber and Lyft will both be able to claim a lead in lots of cities, and both will be around for a while._

Furthermore, if you live in a city with both, it's not uncommon to talk with drivers who work for both services.

I will also add that the need for expansion has toned down the quirkiness of Lyft from when they first out a few years back. The giant furry mustache was replaced. No more fist bumps. And the drivers I encounter are generally less talkative and charismatic. That's not meant to criticize the company, but AFAIC, there is just a lot less separating the two companies.

So playing it slow and sane might be second in the long run, but if they keep expanding I don't see them not eating into Uber's market and climbing their way up. Well, unless of course Uber's investment into driverless cars is able to come to fruition within our lifetime.

<comment><USER3> I have no idea what the situation is like in the rest of the country, but Lyft seems to do pretty well in Chicago. The drivers I speak to tend to use both Lyft and Uber, but prefer Lyft overall; Lyft allows tipping, and Uber customers are allegedly pickier.

I'd say most people I know use one or the other exclusively. I think Uber actually tends to be cheaper at busier times than Lyft if you tip when you use Lyft. The average Uber vehicle seems newer than Lyft vehicle as well.

Either way, I don't think Lyft is at much of a competitive disadvantage in Chicago, at least in the 20-something crowd. The older individuals I know are much more likely to use Uber exclusively, and use the features that are not present in Lyft, like calling a standard taxi, or Uber Black.

It's all anecdotal of course, but I personally wouldn't worry too much about Lyft. I think the fact that they appear to allow a broader range of vehicles and drivers is a competitive advantage.

<comment><USER4> Allowing tipping is why I don't use Lyft.

<comment><USER5> Exactly this, to be honest. I use Lyft whenever Uber is too far away, but always prefer Uber given the choice primarily for this reason. (That, and Uber has a superior airport pickup UI, last I checked.)

It's not about money; it's just a UX thing. I don't like having to remember to go back into the app after the fact to pay more to not look like a jerk. I'd rather Lyft just raise their rates by 15% and kill the option to tip, or at least give me an opt-in setting to auto-tip (and factor the auto-tip into fare estimates).

<comment><USER6> "I don't like having to remember to go back into the app after the fact to pay more to not look like a jerk"

But you don't. The driver doesn't see that you tipped or not.

</comment></comment></comment></comment></comment><comment><USER7>
      But Lyft is stuck in Uber's shadow. I asked one venture capitalist what he thought of Lyft. He put his thumb and index finger into an L shape, brought his hand to his forehead and mouthed "loser".

I don't get this obsession with market share. Is Apple a loser? Is Pepsi a loser?

<comment><USER8> > I asked one venture capitalist what he thought of Lyft. He put his thumb and > index finger into an L shape, brought his hand to his forehead and mouthed > "loser".

Is this some kind of satire? Do people who have left their fraternity some years ago actually talk that way?

<comment><USER9> Have VCs actually left their fraternity?

</comment></comment></comment><comment><USER10> No, nice guys come in 15th. Cause they are being tripped, sued, and cheated by the sociopaths. And there seems to be an endless number of those.

As a nice guy developer for many years, who has build some amazing products, I have learned that no good dead goes unpunished. Irregardless I will continue to be a nice guy because that is how I believe the world 'should' work. One last cheer for Bernie!

<comment><USER11> Surely it's possible to be a nice guy while screwing over the cheaters.

<comment><USER12> Cheaters are people.

<comment><USER12> Wow, that got a downvote?

I meant it as answer to the question: No, it's not possible to screw over people while being a nice guy. Ipso facto.

<comment><USER11> I did not downvote you, but I question why you suppose righting a wrong makes you no longer 'nice'.

<comment><USER12> Alternatively: you can screw over the cheaters all you want. But, don't call yourself a nice guy. :)

I believe this is one of the reasons it's common for people to self-describe themselves as assholes.

<comment><USER11> Being nice and punishing someone else are not mutually exclusive.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> "Sorry, you need to enable JavaScript to visit this website."

<comment><USER14> If you use some style injector plugin (like stylish), you can add this for that page:

        #seckit-noscript-tag { display: none; }

and it works fine... (or you can remove the matching div from the web inspector if you are using a browser which has one).

Aside: That one element is blocking an entire working page for no reason. Where oh where has web dev come to :'(

<comment><USER15> It probably is not "for no reason" – the reason is that the page contains advertising and tracking scripts. The page owner is even willing to lie (pretending that JS is necessary is a flat-out lie if the page works fine without any JS features) so that users enable JS and run those.

In 2013, I created a program to visualize what hosts a web site notifies when it is loaded [http://daten.dieweltistgarnichtso.net/src/list-web- bugs.py](http://daten.dieweltistgarnichtso.net/src/list-web-bugs.py) – you can see the output for the article here: [http://daten.dieweltistgarnichtso.net/pics/graphs/web- bugs/w...](http://daten.dieweltistgarnichtso.net/pics/graphs/web- bugs/www.1843magazine.com-web-bugs.png)

<comment><USER16> Hey, this is cool! Nice work. I am going to play around with this later.

<comment><USER15> I also have a page to visualize German newspapers' tracking: [http://news.dieweltistgarnichtso.net/posts/zeitungs- tracking...](http://news.dieweltistgarnichtso.net/posts/zeitungs- tracking.html)

</comment></comment></comment></comment></comment><comment><USER17> I really like this idea: "They have talked about building a city and designing it differently, so the car would not dominate the landscape."

Custom-designing a utopic city has been tried before (see California City), but I never tire of seeing people try. The end result could be fantastic, especially in this case.

</comment><comment><USER18> Lyft, has a name that is not distinctive from the English word "lift", which may make for a nice pun, but it's harder to express in conversation that you'll use a ride-sharing service rather than just calling a friend. "I'll get a lift."

Uber has a lot more brand recognition, but like Chik-fil-A they are also known by a minority for terrible business practices and are on unofficial boycott.

<comment><USER19> You're saying Chick-fil-A has terrible business practices? The only reason I know for people to hate them is that their owners have taken Christianity- based opposition to gay marriage (or something alone these lines), which doesn't really seem like a business practice of the restaurants.

<comment><USER18> Perhaps I should have said just "terrible practices". The brand is about perception, and lots of liberals perceive Chik-fil-A as materially supporting regressive social values. Too bad the chicken is fantastic.

With Uber you have the perception that the company is exploiting drivers, driving down wages, disregarding how it puts women at risk, and all kinds of sexist behavior. [http://time.com/3595318/uber-sexism-tech-delete- app/](http://time.com/3595318/uber-sexism-tech-delete-app/)</comment></comment></comment>


A Philosopher's Take on Global Basic Income: Fund It by Land Value Taxation - <AUTHOR> http://www.knowitwall.com/episodes/GBI_philosopher <comment><USER2> The despicable problem with land taxation is that it turns property from _owned_ to _rented_. It allows for abuses of raising tax rates to drive people off their property. It replaced true supply-and-demand with arbitrary choices by under-informed bureaucrats, which never goes well. It is the core of gentrification problems, driving people from long-occupied homes via taxation because others pay a premium for neighbouring properties.

Never mind the core problem with UBI itself: funding inactivity by taxing productivity.

People should be able to own land outright. Let the poor and elderly and independent keep theirs, without being driven out by overwhelming taxes raised to fund the poor and elderly.

<comment><USER3> What?! Poor people can _always_ be abused by driving up taxation. You don't need to tax their homes, you can just tax their food, water, electricity and fuel.

I see a much bigger problem in land ownership encouraging concentration of capital. We should be encouraging productivity, innovation, hard work, not rent-seeking.

<comment><USER2> If you own land, without property tax, you can become completely self sufficient: grow food, build shelter, produce power, collect water. I grew up close to that, and could have done it 100% if needed.

Outright land ownership is critical to survival, independence, and productivity. Property taxes are horribly destructive.

<comment><USER3> Even if you're self-sufficient you should still pay taxes, because the government still protects your property by enforcement of laws by police.

<comment><USER2> If I have no income, how can I pay taxes? Bushels of carrots?

</comment></comment></comment></comment></comment><comment><USER4> The concept is simple and elegant on paper, but it's vulnerable to the same problem that real-world policies that philosophers come up with often fall prey to. It's going to be incredibly difficult to assess the "unimproved value" of any parcel of land fairly.

Do you apply a flat rate per acre of land regardless of where it is, to the detriment of rural farmers who own many acres? Or do you take the location into account? Are we going to have an army of certified professionals whose job is to assess the unimproved value of each and every parcel of land in the country?

And if your formula makes any reference to the actual price at which land is traded, how do you tell how much of it is the unimproved value and how much of it is the value of all the improvements that went into it? There is hardly any land in populated parts of the world where no improvement has ever been made to it, so there's no reference point. If there are two parcels of land in the same neighborhood but one is more desirable because it has a view of the waterfront, does the waterfront view count as improvement or an intrinsic part of the value of the land? Everything is going to be based on a series of arbitrary decisions. Even the value of a dollar is based on a series of arbitrary decisions.

Even worse, since it's all going to be an arbitrary benchmark with a lot of variables that can be tweaked, everyone will try to influence it or abuse it in a way that minimizes their own tax burden. Over time, these forces will result in lower assessments for all land, reducing the overall tax revenue and making the whole scheme unsustainable. Right now in the developed world, a disproportionately large share of people's wealth is tied up in real estate, especially for middle-class folks who read political philosophy. But this won't last if the incentive structure changes.

I would much rather just bite the bullet and say yes, we're going to charge tax on the fruit of your labor whether Mr. Nozick likes it or not. Oh, and we're going to charge even higher rates on the fruit of non-human labor, i.e. machines, since they have no rights anyway. Maybe if these machines produce enough stuff, who knows, perhaps one day they'll contribute enough so that the tax on humans can be reduced to zero?

<comment><AUTHOR> _> Do you apply a flat rate per acre of land regardless of where it is, to the detriment of rural farmers who own many acres?_

No, it's the market value of the land. Probably the price would be determined in a manner similar to property tax.

It seems that in our current world, it's easier to fairly determine property tax then what counts as someone's income, at least for the self-employed and investment classes.

<comment><USER4> Market value is easy. The problem is that the author wants his tax to be based on the "unimproved value" of land, rather than the market value that includes buildings and other stuff that's on and around the land. He's aiming for a kind of philosophical purity in order to be able to say that he's not going to put a tax on human effort. That's where the complexity comes in.

<comment><AUTHOR> I don't think it's about purity at all, but practicality. Land is the scarce resource, not the buildings on it. Taxing scarce resources is what we must do and also creates the right incentives.

You claim it'll be hard to judge it's fair market value and this is what I disagree with. I mean, sure it'll be hard, but not harder than measuring income.

If the land tax equals the land value, undeveloped plots should sell for about $0. That's a natural benchmark to aim for.

</comment></comment></comment></comment><comment><USER5> No pitchforks, but this has sentences straight up from wikipediea article: [https://en.wikipedia.org/wiki/Land_value_tax](https://en.wikipedia.org/wiki/Land_value_tax)

<comment><USER4> Hillel Steiner is a pretty well-known political philosopher, and this topic is right up his alley. It's much more likely that whoever contributed those sentences to Wikipedia borrowed them from Steiner and/or whoever he's quoting from (whether knowingly or not) than the other way around.

</comment></comment><comment><USER6> Some populations practice having as many children as they can because their belief system calls for it. They believe they will get more brownie points from a supreme being for that.

So these groups will get more share of the basic income in the next generation and more in the next and so on and so on...

<comment><AUTHOR> The basic income should be on a sustenance level. So even without any controls, having more children is not a way to get wealthy. It's basically like now; if some of them succeed it may pay off, but it's anti-social and usually doesn't work.

</comment></comment><comment><USER7> This is interesting. Is there a dedicated forum where such new ideas in economics are being discussed?

</comment><comment><USER8> I'll concede that I'm not as economically literate as I'd wish, but this doesn't make sense to me. The "1%-ers" don't tend to store their wealth in land, do they? How would this proposal even out the wealth-gap when it is essentially blind to the mechanisms that the rich use to store their wealth?

If anything, this idea seems like it would only harm the (already struggling) middle-class, who may have little equity beyond their home/hand.

<comment><USER8> Too late to edit, but: s/hand/land/

</comment></comment><comment><USER9> I get it. I like it. But man, would that piss off all the farmers in this country.

<comment><AUTHOR> Farmers are already paying property taxes and their land is hopefully not the most valuable to begin with, so it doesn't seem like it will change their finances much.

</comment></comment><comment><USER10> we are trying to tackle this problem by rewarding people for finding good candidates for available jobs in the market (mostly tech jobs); [https://www.ref10.com/](https://www.ref10.com/)</comment>


Social Media and Sports? Part 2 - <AUTHOR> http://www.fanpictor.com/en/blog/2013/9/12/social-media-and-sports-part-2/

<comment> steph-fanpictor if you like the entry, check out part 1 of social media and sports: www.fanpictor.com/de/blog/2013/8/21/social-media-and-sports

</comment><comment><USER2> Great aticle!</comment>


What's the best launch strategy for a web startup? - <AUTHOR> http://www.quora.com/Whats-the-best-launch-strategy-for-a-web-startup <comment><USER2> All the answers seem to be from "early influencers" (Scoble most of all) advancing a view in which they're the gatekeepers. The problem with that is that you end up building products for the particularly narrow niche that is Northern California Tech PR professionals.

I can think of several huge successes that as far as I can tell, were huge long before the Tech PR community discovered them.

Facebook - built an audience at a single colleges first.

Groupon - never heard a thing about them from the PR community, until _boom_ they were everywhere.

Zynga - just pure evil marketing crap, but seemed to work spectacularly well.

So I think that completely ignoring the "early influencer" crowd and doing plain old marketing (find a market, advertises, promote, etc) is more likely to result in huge success than is playing the SF/NYC/SxSW "influencer" game.

<comment><USER3> Facebook sort of followed the model. It built for a niche first, then for other niches, then the niches collided with each other and they start building for mainstream and standardizing their product.

Chasm Companion book(and Crossing the Chasm, Inside the Tornado) explains this very well.

[http://www.princeton.edu/~guanchun/Books/The%20Chasm%20Compa...](http://www.princeton.edu/~guanchun/Books/The%20Chasm%20Companion.pdf)

<comment><USER2> I have read the book. I just think that the people who style themselves as "influencers" no longer fit the model's early adopters. Mostly because they've been professionalized. PR people aren't early adopters, they're PR people.

</comment></comment></comment><comment><USER4> It depends massively on the intended market. Is it a consumer service? SMB service? Mobile? Local? Social? Color?

For a consumer service, making a big launch splash on TechCrunch, SXSW, Disrupt, etc is awesome. Not a lot of start-ups are fortunate enough to be a part of any of those events. However, just because you launch at one of these does not mean that the service will prove to be persistently successful. Certainly, you will get a huge bump in traffic off the bat, but if you do not have a great product, then it will be extremely difficult to create sustained value for your users. In my opinion, it would be far better to create a killer product, get your first 1000 users, and pay attention to what they want. Ideally, you get the PR to come to you.

</comment><comment><USER5> release early. release often.

</comment><comment><USER6> If you have killer product PR will be hunting for you.</comment>


Calling Steve Jobs 'Lucky' Would Be A Sin - <AUTHOR> http://statspotting.com/2012/12/calling-steve-jobs-lucky-would-be-a-sin/ <comment><USER2> Steve Jobs was born in the USA. Massive edge right there.

Lived in California during the dawn of the personal computing age.

Met Woz.

These 3 coincidences put him ahead of billions of other people. And they _are_ coincidences. They're luck.

Luck matters; we just don't like to admit it -- <http://chester.id.au/2012/03/02/does-leadership-matter/>

<comment><USER3> Good lord. There's gotta be some logical fallacy named after this.

Yes, all these things happened by some fortunate cosmic happenstance. But that is true for _everything_. Take away a few key pieces from a flow in history, and the flow might not have taken place at all.

The point is that, statistically, such fortunate confluences happen all the time. Only a few produce a flow that blazes a trail. And it does have a lot to do with the characteristics of the people who find themselves at the cusp of it.

Could someone else have been as successful as Steve had these early things happened to them? Maybe, maybe not.

Could someone else have been as successful as Steve had some other set of fortunate events come together? Maybe, maybe not.

It is silly to take away from a person, and attribute it all to luck.

<comment><USER2> > _It is silly to take away from a person, and attribute it all to luck._

And where, exactly, did I do that?

</comment></comment></comment><comment><USER4> You can win three times Lottery Jackpot and you still wouldn't create a damn thing that is anywhere near Apple's Product. Not that they are insanely great, but no one would put label them as cheap, crap or mindlessly crafted.

And you can met Woz, but you would still have failed creating a company. And properly failed miserably.

Steve Lived at the dawn of the personal computing age, and got kicked butt by IBM, M$ and Intel. Wow. Lucky

He got kicked out of his own founding company. Extremely Lucky.

There are properly some luck involved in every successful billionaires, Bill Gate for exmaple. But Steve, I would put him as the last one on the list.

So Yes. It is a Sin.

<comment><USER2> I believe that being born in the USA, being in California and meeting Woz were all _necessary_ causes. Without them Steve Jobs might have run an insanely great yoga studio.

So yeah. Luck.

</comment></comment><comment><USER5> I've heard Jobs called a lot of things over the years (mostly the C word, if we're honest), but lucky? As in "merely" lucky? Nah.

The guy had a head on his shoulders, you've got to give him that.

</comment><comment><USER6> These kind of debates are so boring they actually make you appreciate reading VB code.

<comment><USER7> Surely, you meant J2EE?

<comment><USER6> Nope, nobody deserves that much.

</comment></comment></comment><comment><USER8> Don't mess with the narrative. If hard work isn't the only thing that contributes to success you're going to destroy a lot of people's entire world view. But yes he was lucky. Just like the fact I'm a programmer right now has a lot to do with being lucky that my accountant father brought home an IBM PC from work in 1980. The choice to actually spend time learning how the computer worked, while an important choice, was secondary to the luck in being one of a fairly small number of people with a personal computer in 1980.</comment>


US Congress: Republicans vote to limit ethics body - <AUTHOR> http://www.bbc.com/news/world-us-canada-38494455 <comment><USER2> _Under the proposals the new body would no longer be able to receive anonymous tip-offs, nor have a spokesperson, and would be under the supervision of the House Ethics Committee. Accusations against lawmakers would not be made public, as they are currently._

That's just the beginning, because those guys don't believe in regulations, and they've been very open about what they want to do - do away with regulations.

Like under the last Bush administration, it will be free-for-all. There will not be a single anti-hrust case brought against any company.</comment>


Startup School Radio: Campus Job Founders on Leaving Google and McKinsey - <AUTHOR> https://blog.ycombinator.com/startup-school-radio-campus-jobs-co-founders-on-leaving-google-and-mckinsey-for-startup-life

<comment><USER2> On CampusJob: I've always found the idea of product placement and marketing on college campuses to be antithetical to a "classic" college environment that promotes freedom of thought/speech and the exploration of ideas outside of the mundanities of corporate life. So I cringe when I read about companies that are putting Red Bull t-shirts on students and having them convince frats to buy red bull for mixers that they'll use for ragers. There was one company that was providing free branded bikes [1] to campuses which is useful for broke college students, but campus marketing is still just weird and distasteful in my mind. Maybe it's just me.

On leaving Google & McKinsey: "Google and McKinsey, we could always go back to them if we needed to. But Campus Job now is an even better place to work. So we're happy."

Better hope this quote doesn't show up in a re-hiring interview :)

[1] [http://www.freebikeproject.com/](http://www.freebikeproject.com/)</comment>


Ask HN: What is your most favorite programming language ever? - <AUTHOR> And what tools do you use it with? <comment><USER2> I don't really have a "most favorite programming language ever". I think of languages as tools and try to keep a focus on "use the right tool for the job". I don't reach for C++ for writing webapps as a rule, and I wouldn't reach for Prolog to write an OS kernel.

That said, my primary language for most "general purpose" tasks these days is Groovy. I also lean towards Java for many things, due to familiarity. I have a soft spot for C++ as well, which I probably would have called "my favorite language" years ago.

Lately I've been working on adding R and Octave to my arsenal, and I have to admit, I'm really liking Octave.

But I just bought a Swift book earlier tonight, so who knows what the future may hold...

</comment><comment><USER3> I don't think I'll ever love a programming language like I loved ANSI C in 1996. I slept with the K&R book under my pillow. When my friends were getting into tarot cards & crystals, I did divination by picking random passages from that book. It was my first "real" programming language, and the one that led me to understand computers on a completely different level.

Today, I guess I'd say JavaScript. I mostly write "vanilla" JavaScript with the help of grunt for minifying (switching to webpack soon). It has it's rough spots, but they're ones I've known for decades now. It's everywhere. It's multi-paradigm.

</comment><comment><USER4> Common Lisp.

The only tool I use with it, I guess would be emacs. Unless by "tool", you mean libraries.

However, it's Ruby (often generated by Common Lisp) that puts food on the table these days -- and Python that I'm using to plot my (positive) escape from the workforce.

Both Ruby and Python are weaker languages that share some of the Lisp spirit. Ruby in fact, is derived from Emacs Lisp.

One of my side projects is an attempt to jack libraries from Python -- which will, if successful, make Common Lisp more usable as a day-to-day programming language.

</comment><comment><USER5> After discovering Haskell (lazily-evaluated functional) and Lisp (actually, Clojure), I'd have to say them. For anything close to the metal where pauses for garbage collects don't matter, Go. And of course HTML. (Tho I realize some people out there won't count as a PL non-Turing Complete languages like HTML and Groovy as used in virtually every Gradle build script out there.)

</comment><comment><USER6> My favourite language is Lua. Not so much for the language per se although it's pleasant to use. But it's very simple so if it doesn't fit exactly what I need I just change it. I use luaj too if I'm going to need to use JVM libraries.

For that reason I tend not to use luajit so much. Although it's a technological marvel, it's nothing like as hackable for a mere mortal like me.

</comment><comment><USER7> Plan 9 C and the rc(1) shell by far. Plan 9 C is still C but has a lot of things fixed and the plan 9 libs are great. The rc(1) shell I like because its much more consistent than any other shell I've used.

</comment><comment><USER8> C#

</comment><comment><USER9> I want to be up-voted on hacker news so Python twothree is by far the GOAT programming language. Go-lang is fucking trash (until the next major point release in which case it becomes vice-GOAT). Django was what god made when he decided to refactor the bible, and is thus elevated to language status. Rust is gonna take over the world. And I currently have 103 side projects in React.</comment>