Programming languages, operating systems, despair and anger | Hacker News Reader

Programming languages, operating systems, despair and anger

xent.com

93 pointstechnikhil56 comments

For those of you finding it hard to read the paranthesis-heavy text, the very last part struck a chord:

"If I have to write one more polyglot bash / awk / python script to gather data from log files on a bunch of different machines, demux that into a time-ordered event stream, pipe it through something to munge it into some slightly different format, ship that off via post to some web address and get some JSON back, parse that into some other shit, do some computation over it like aggregation or date math over time stamps with unlike representations, wrap the results up in an HTML table and send that table in a MIME-enabled e-mail to myself I think I am going to explode."

CPAN is afaik the gold standard to make that kind of thing bearable. It isn't really a language thing.

(Since everything seems to go to Moose (a backport of most of the Perl 6 OO model) in the Perl world, there might be an impedance mismatch in a few years with old style libraries and new?)

Moose and standard/old style libraries are entirely and transparently inter-operable.

Yeah, but I was thinking more brain mismatch. On the other hand, most CPAN libraries aren't so large that they use APIs which needs to be overridden; I was probably wrong. (Anyway, it was irrelevant to my point. :-)

That post is a little rant heavy but I agree completely: simple, everyday tasks are still way more verbose and require more lines of code than they should in most languages.

Python/Ruby is probably the closest I've seen to a language that provides enough batteries to be productive but gets out of my way syntactically as much as possible, but both of them could use some further evolution.

I absolutely love Python, can't stand Ruby.

The reason I love Python is that in general when I want to write something a certain way, or what seems to be the most natural way to do something is how it is actually done. As a programmer it gets out of my way and lets me do what I need to get done.

The author to a certain degree is calling for exactly that, a language that makes tasks that every programmer does over and over extremely simple, make the stuff that is not done nearly as often harder to do, or take up more lines.

> what seems to be the most natural way to do something is how it is actually done

I love Python too, but it's not without its quirks. Eg:

    ','.join(mylist)

Which nearly everyone I know at first assumed would be:

    list.join(',')

Nobody thinks of what's being done here 'take a dot, and use it to join this list'. They think of 'take this list, and join it into a string using dot'.

> Nobody thinks of what's being done here 'take a dot, and use it to join this list'. They think of 'take this list, and join it into a string using dot'.

Even fewer people think of how to do that in the face of heterogeneous and polymorphic lists.

Intuition is not God, it's just an informant. Sometimes it's wrong, no matter the language.

I was about to write about how horrible that is when I realized that I do that all the time in jQuery:

$("<div>Foo</div>").appendTo(bar)

That's not the same, $(...) is a method which creates a list. ',' is a string. So actually you're doing exactly the opposite of the python idiom.

Possibly, but that div is a literal chunk of HTML so that's arguably closer to a string than the normal jQuery selectors.

It's a convenience so that every iterable object in the world doesn't need to implement a join() method. I pass generator expressions to join as often as lists, so it works out well that the method is on the string rather than the list.

> It's a convenience so that every iterable object in the world doesn't need to implement a join() method.

The way to do this would be to have an IterableMixin that implements join() (and a load of other stuff) so long as the subclass implements a small number of basic methods.

Sure, but is it up to the programmer to "subclass" or somehow specify that his type implements IterableMixin? Or is it up to the python interpreter to realise that it implements certain functions and automatically do this?

i like that because it's a string's method returning a string.

Methods aren't defined by what they return. I have a host method (a property, to be precise) that returns a location of the host. It wouldn't make sense for it to return another host object.

string methods are things you do to strings.

list methods are things you do to list.

Most people think of taking a list, and gluing it with a string, not taking a string, and using it as glue for a list.

good points. I was pointing out mostly a subjective 'beauty'.

just of note, the architect in me would go for 'why not have both?'

""Go" is just another language written first for the compiler and only secondarily for the programmer --- and stuck in a 70s mindset about the relationship of that programmer to the (digital) world within which they live and work!"

AKA the New Jersey design approach lives (http://www.jwz.org/doc/worse-is-better.html).

Java is interestingly an at least somewhat successful attempt using the MIT approach (as is Clojure on top of its JVM).

If everyone took to heart his "non-starter" characteristics, no one would start anything.

That said, it was a lovely rant ;-)

The thread following this post is actually full of surprisingly good discussion; well worth a read for some of the points raised in the back-and-forth.

Go is a systems programming language. It's not appropriate to expect Go to be able to send an email or create a web server in one line. Go is supposed to be a better systems programming language than C. It's not supposed to be a high level language with all of the things that he wants.

Also, language designers have to maintain a balance between improving the language and maintaining stability so that programmers can actually get work done. I think Guido is doing a good job of this (even though I might disagree with some of his design decisions).

We can all agree that current programming languages have a lot of warts, but then he gets to his list of BARE MINIMUM features a language must have and the rant takes a hard left into Crazytown. Social networks and to-do lists as first-class, language-level features — not even a social network standard library, but a whole subset of the language dedicated to social networks and to-do lists.

It sounds like what he wants is a DSL, because the language he describes would be useless to most people who aren't in his exact position.

I do most of my work in infrastructure, and I'd find first class objects for IPs, networks, and humans useful.

What advantages would first class IPs, networks, & humans bring over the ability to make first class objects for anything?

Standards. I can get a random module and know it expects these objects to have the same properties and methods I do.

That would work just as well if they were part of the standard library, wouldn't it?

It seems to me as if he is mostly complaining about the lack of libraries to handle basic operations, rather than programming language syntax or design.

Which is a problem orders of magnitude easier to solve than designing a language from the ground up.

Good rant, but can we stop it with the "You need to understand category theory to do IO in Haskell" meme?

    main = do
       putStrLn "What's your name?"
       name <- getLine
       putStrLn ("Hello " ++ name)

Was that really so hard?

Yes, it's easy.

(And a few bits of category do help when you are toying around with other typeclasses. Have a look at the typeclassopedia for an introduction.)

I think he started with a point but devolved into a lot of wishful thinking.

Why not focus on the solution rather than hoping someone is going to listen to you complain and make it all better?

I'm sure they could use the help.

Wishful thinking? A lot of what he suggests have straightforward implementations as "built-in" features. (Something that looks "built-in" anyhow.)

Perl tried to be pretty much the language he suggests, but it was put together with a poor sense of language design. Ruby tried to correct Perl's mistakes, but also succumbed to the "kitchen sink" mentality. Python tried to correct many earlier mistakes, but while it was more closely integrated with the underlying OS and still managed to be a relatively simple language, it got too tied up in the underlying OS.

Most of what he's talking about could be implemented with Lisp machine or a Smalltalk VM as OS Kernel. The features he wants "built in" could simply be added to the default class library. Perhaps something based on the Erlang VM could satisfy the multi-core part.

http://www.skepdic.com/wishfulthinking.html

The premise as I understand it is that modern languages are broken and have failed to evolve. An interesting point. A good start for an argument.

However, his rant devolves into:

"REAL WORLD, modern datatypes, built-in, literal, batteries-included PLEASE!!! If the following aren't first-class types with first-class literal constructors / representations supported at the language level then your new programming language ISN'T EVEN ON THE PLAYING FIELD"

No evidence. Not even a mention as to how he's reasoned that these statements are true. Nothing.

Why does my compiler/interpreter need to have an "email" data-type? Why is my language not even "on the playing field" without it? Why are there so many successful programming languages then that survive without it?

I can empathise with his frustrations. There are plenty of times on the job when I feel more like a glorified digital plumber. Deserializing/reserializing data and pushing it through various pipes isn't glorious work. But lets take the argument from there rather than flapping our arms and making frantic claims that everything the way it is is inherently broken because it's not the way we'd like it to be.

(And maybe he does just need a good dose of Lisp ;)

I think his point is that most language designers seem concerned about abstruse things and seem less concerned about his everyday problems. Someone's got to be concerned about his everyday problems to do the best possible job of designing a language to make his life easier.

I thought it was a good rant. It's certainly been a while since I read one like that.

Although I do think he's a little too obsessed with one-liners but that could have been hyperbole on his part.

I think one of the big issues with the evolution of languages is the inherit complexity and time commitment involved in creating a language. I'm very intrigued by languages that run on VMs and provide you with an underlying platform to work with. Until language creation becomes a more reasonable task to accomplish, we won't see the the sweeping changes he wants to have.

Yes, let's slam systems-level programming language Go for not catering to application developers...because what people writing operating system components and utilities really want is an e-mail address as a first-class language feature.

Clicky on Carl Sassenrath, the Amiga and Rebol guy: http://www.sassenrath.com/

P.S. good rant on major pain points - I'd toss in the breakage in the hierarchical filesystem model.

Well, I am doing something about it :-) Look at Babel-17 (www.babel-17.com). It is not ready yet, and for the next few months it will be purely functional, but eventually, you will get it all.

But if I learn babel17 won't I become a traitor!

Of course not, just learn it, then you'll see ;-)

While I appreciate the idea and criticisms of the post, I dislike the strong wording of this rant.

I think that designing a language that can solve all possible problems is beside the point. A language is a tool and used for different tasks. Not only is the purpose different but people have also different preferences. So making everybody happy is impossible.

Languages have to go the way of the dodo. Every new one is an arguable attempt to do things better than the one which came before. That doesn't mean they really are better.

Please don't say that "languages are tools". While this is technically right, our thoughts are so dependent on programming languages that they can't be considered "mere" tools. Considering they are make us wrap languages around their implementations, rather than around their users.

I can understand your point, but I came to the conclusion (after 20+ languages) that thinking in just one language can be quite harmful to find a good solution for a problem.

Actually PG puts it really nicely [1]:

"The right way to solve that problem, I think, is to separate the meaning of a program from the implementation details."

"What program would one like to write? Whatever is least work. Except not quite: whatever would be least work if your ideas about programming weren't already influenced by the languages you're currently used to. Such influence can be so pervasive that it takes a great effort to overcome it. You'd think it would be obvious to creatures as lazy as us how to express a program with the least effort. In fact, our ideas about what's possible tend to be so limited by whatever language we think in that easier formulations of programs seem very surprising. They're something you have to discover, not something you naturally sink into."

http://www.paulgraham.com/hundred.html http://www.paulgraham.com/avg.html http://stackoverflow.com/questions/1003940/learn-a-new-langu...

Sure. But the gist of the rant is that he keeps doing the same repetitive, mundane tasks over and over again, merely to shuffle data from one part of the system to another and convert between representations on the way.

Like when you have a database, a server application and an AJAX web page, you may have four to five different representations of the same data (DB table, server language object, JSON, Javascript object and finally HTML) and need a whole bunch of code just to move data from A to B and convert between representations.

It's not just a language problem. It's just as much a problem of impedance mismatch between different systems, protocols and data formats. Various frameworks attempt to reduce the tediousness, but tend to come with issues of their own.

PG has something on this too:

"Of course the ultimate in brevity is to have the program already written for you, and merely to call it. And this brings us to what I think will be an increasingly important feature of programming languages: library functions."

"I think a lot of the advances that happen in programming languages in the next fifty years will have to do with library functions. I think future programming languages will have libraries that are as carefully designed as the core language."

http://www.paulgraham.com/popular.html

Whether the common case is made simple by the language, libraries, frameworks or standardization (we may need all of them) ultimately does not matter much to the developer, only that you can handle conceptually trivial everyday tasks with the minimum of fuss.

We have a long way to go before this becomes a reality.

You are absolutely right. Alas, this is mostly applicable when you still have the choice of the languages you will use or build to solve your problem.

When we have settled for one language, though, no matter what we do, it greatly influences our thinking. For instance, I know and love Ocaml and Haskell, yet when I do C++, I have to think in C++ to a great extent. If I think more abstractly (declarative description of my problem, proper separation of concerns, algebraic properties…), I can guarantee the C++ translation will be utterly unreadable, because the mismatch is too great.

When all you have is a hammer, everything looks like a nail. A hammer is a tool. Therefore "mere" tools can be said to shape ones thoughts.

Yes. I just think programming languages, as mental tools, have much more influence on our thinking than physical tools. It's easy to observe: I have colleagues who don't know currying and lambdas, others who don't find them useful, and others who plainly don't get it. Programmers. I doubt such blindness applies to physical tools. But that may be because I'm not proficient in manual works.

That said, even if I am wrong, "languages are just tools" is still harmful. This phrase is often followed by statements like "the choice of languages don't matter that much", or "don't whine about your language". These are valid to the extent you have to take into account existing code (read: past mistakes), and team expertise (read: ignorance). However, they tend to overstate these issues. For any big enough project, the technical merits of a language trumps anything else.

We all like to write a game like following, but...

Create football stadium and football players. Start the game when user presses spacebar. Make players have red shirts and white socks.

http://thedailywtf.com/Comments/Could-You-Explain-Programmin...

Personally, I don't believe that a proliferation of programming languages is really required. Most languages do the same sort of thing with slightly different syntax and degrees of efficiency. If you're really unhappy and frustrated about the current state of programming languages my advice is to go and develop your own.

I think the proliferation of languages is due to people following your advice: they go off to make their own language, realize it's hard to make something radically different and end up just fixing a couple of their pet peeved from another language.

"Somebody do something about this, before I LOSE MY FUCKING MIND!?!?!"

Um, what, exactly, is stopping the ranter from doing something about it himself? Is there a law that only people born into a special caste are allowed to create programming languages?

Or is he just too lazy to do more than bitch about the world being sub-optimal?

If he did, he would risk learning why things are the way they are. There's definitely room for improvement, but modern languages have evolved this way for a reason. If he wants his own bloated DSL, then best of luck; but I probably don't want that same language for my projects.

Most surveyors don't know how to actually build the road, they just know which way it should go.

too many new languages introduced in the last decade, no doubt, while most of them are just similar to the others, or simply as bad/boring as the others.

Unfortunately, what he talks about is some yet another scripting language, not a system, close-to-hardware-level programming language.

Go is just a C 2.0 developed by its fathers and it's based on early works on Plan 9 project (if I understands correctly).

So, it is language for OS-level programming and, perhaps, google's own native client, and community will code and release lots of high-level libraries, as it happened for C or, say, perl.

Reply on news.ycombinator.com