Comment by reginaldo | Hacker News Reader

Comment by reginaldo | Hacker News Reader

Parent Full thread

I feel likewise (except for the Perl part. I have the most fun working with PLT-Racket tools).

I believe this happens because language design involves a lot of trade-offs, so every language incorporates these trade-offs.

When one is comfortable in many kinds of languages, one is in a special position to see the trade-offs in the design of the language one is currently programming it.

The way I see it is slightly different then the way you describe. Say I'm programming in Prolog, for instance. In the beginning, I'll be like "Wow, such expressiveness". But inevitably I'll do something that is outside the scope of Prolog and it will be as slow as hell. That's when I think to myself: "if I could just fix this little part... I miss C". So when I'm back programming in C I'll think "now my code is fast", but then inevitably: "if I could just find a way to do this without so much repetition".

In the end, it comes down as a "right tool for the job" thing. One possible ideal would be do the things Prolog is good at in Prolog, the things C is good at in C (and also throw in some Python, Erlang, Lisp, etc). Except most of the time this is infeasible. Working with FFIs suck. Sometimes there are no FFIs, sometimes there are many incompatible ones, and the dream of calling any language from any language is just further and further apart. And don't get me started on the pain that it is to have multiple runtimes with slightly different semantics...

Even if it were possible, a developer would have to learn all these little languages enough to be working on them comfortably, and we all know this is not going to happen. So hardly anybody does this, as hiring someone for a polyglot project is a complete nightmare.

Tradeoffs are a sign of a false dilemma; rather than choosing one solution or another, use them all where they work best. This is where Unix got it right all those years ago; Unix isn't just a slightly more stable platform for running today's bloated and monolithic software, rather, it's an elegant system for connecting maintainably-small utilities. The shell glues said utilities together into programs. Such an approach combines the best of high and low level programming, reuse and specificity, tradition and novelty, etc.

I know shell isn't going to with this popularity contest, but a return to it is what's badly needed in CS today. Instead of attempting to recreate the shell in C# or Java's supplied libraries and subsequently becoming frustrated when interaction with the "outside world" is clumsily accomplished through an FFI pinhole, just use the shell as it was intended: as a lingua franca between utilities.

Write what requires prolog in prolog, what requires c in c, what requires awk in awk, etc. Use flat file databases such as starbase or /rdb and avoid data prisons such as MSSQL, Oracle, MySQL, etc. Make all of these utilities return sane return values and spit out JSON formatted output. Finally, tie it all together with shell. If you need a UI, code it as a thin layer in TCL/TK, python/pytk, ansi c/gtk, or, consider pdcurses, etc. Profile your program and find any weak links in the chain. Recode in a lower level language only when needed.

Programming doesn't have to be hard. As in speech, the more one says, the less one means.

In some ways, I think REST interfaces exchanging JSON are the modern equivalent. Doesn't matter what the underlying programming languages are, everything can talk to everything else through a simple (well, not as simple as pipes), broadly understood, and widely implemented interface.

The Web, of course, has been recognized as the cause of the recent proliferation of and resurgence of programming languages. As long as you speak HTTP, it doesn't matter that you're a dog.

You make a very good point.

And I think it is no coincidence that the creator of Unix is one of the designers of Go, a language that shares Unix's conceptual and implementation simplicity, makes very conscious tradeoffs and where channels work somewhat akin to pipes.

Of course interfacing with the rest of the world has become much harder thanks to XML, SOAP, XMPP and every other such monster, but as somebody else pointed out, the modern equivalent seems to be REST+JSON, I would have preferred something like 9P, but oh well, one has to pick their battles.

Reply on news.ycombinator.com