Live data from Hacker News

The perfect programming language

cygni.se

11–20 of 108 posts

Re: The perfect programming language

#11
post #7

Interesting perspectives on a variety of languages, at first. Then when he says that XSLT is the best language I was thinking that we are very differently minded. So I suppose it makes sense that the Tailspin language is completely incomprehensible to me.

The built-in ability to pattern match on data nested deeply within the application state (or the XML document) is radically powerful. Haskell, for example, has nothing like this.

Eve is a really interesting language where you define global pattern matches, using datalog-style unification rather than XPath, and these "templates" can result in state changes. So for example you can trivially define global invariants over the entire state, kind of like defining a database integrity constraint but for your program's state.

As an aside, I'm recently feeling disillusioned with Haskell—after loving it since 2004—as any kind of ultimate or next-level general purpose language, precisely because of the lack of this dimension. Dealing with relational data in Haskell is quite tedious. Even writing multipass compilers in Haskell is not very pleasant.

Re: The perfect programming language

#12
> I used to have a copy of "SQL for Dummies" at hand whenever I, with dread in my heart, needed to write some SQL, especially if there was any funky stuff like joins and such going on.

SQL isn't so much a programming language as a query language. It never claims to be an efficient way to write a factorial function.

And why do people freak out when they see a JOIN? It's one of the simplest concepts in databases: intersecting two sets. Everything in column A that matches everything in column B. You don't even have to concern yourself with the most optimal way to do it, just say it!

Re: The perfect programming language

#13
post #10

> The foremost is simplicity, that a language should be simple enough that the programmer should be able to know everything about it. Well, no. Translated - "a language should serve the lowest possible denominator". Apart from the obvious fact that it is impossible, it's also definitely not the way to go if you want quality software.

There is no purpose of having a so complicated language - like c++ or java - that the majority of the programmers don't even know 100% of the language. I think Elm (and somehow Go) fits this category, everyone can learn in less than a week every aspect of it. Another benefit of having a very simple language is the compile time, c++ has a awful compile time, 100kloc can take half an hour, in Elm it takes less than 5 s…

> c++ has a awful compile time

I have a thoery that C++ compiler writers obsession with pointless micro optimizations is because C++'s compilation model scales horribly. Thus they desperately want their compiler to be faster. But they are fucked because the more optimizations just slows down the compile times even more.

Re: The perfect programming language

#15
post #4
post #3

Sad to see no mention of the impure ML languages (OCaml, F#, PureScript, etc). For me these strike a great balance between powerful abstractions and the ability to throw things together.

Also no mention of anything in the APL family, sadly.

Indeed. The relevant part of k \h can be put on one side of a postcard.

Re: The perfect programming language

#16

> The foremost is simplicity, that a language should be simple enough that the programmer should be able to know everything about it. Well, no. Translated - "a language should serve the lowest possible denominator". Apart from the obvious fact that it is impossible, it's also definitely not the way to go if you want quality software.

True, although it would be possible for some. Only regarding this property, pancake stack would be nearly perfect (ok, it probably is)

Re: The perfect programming language

#17
post #6
post #3

Sad to see no mention of the impure ML languages (OCaml, F#, PureScript, etc). For me these strike a great balance between powerful abstractions and the ability to throw things together.

The article’s title says “ perfect programming language”. “Impure” means the language design is by definition compromised. The moment you allow imperative behaviors to leak into a declarative system it loses its ability to reason reliably about operations over time; and you’re back to flying seat-of-your-pants a-la C &co. Haskell at least has the good grace to firewall any imperative crap so that the remainder of the…

This compromise you speak of is called practicality. Ocaml/F# may be a dead end in evolution but a great success in appicability. The Haskell family OTOH is a gleaming pathway of continuous development into nowhere.

Re: The perfect programming language

#18

> The foremost is simplicity, that a language should be simple enough that the programmer should be able to know everything about it. Well, no. Translated - "a language should serve the lowest possible denominator". Apart from the obvious fact that it is impossible, it's also definitely not the way to go if you want quality software.

Perhaps a wiser phrasing would be “a language’s interface should be simple enough that the programmer should be able to know everything about it”. (Counterpoint: C++ syntax and semantics.)

The internal implementation can (and usually will be) heinously complicated but as long as it adheres to that external contract any nasty surprises are ones users create for themselves, not the language’s doing.

Re: The perfect programming language

#19
One language that seldom gets mentioned is Postscript. People tend to think of it as just a page descriptor language, but really that is just the built-in graphic functions.

So we have a post fix (RPN, similar to HP calculators) expression style, which is really a mirror image of Lisp. You have genuine first class functions, introspection, and something I don't see that often is first class environments. That is you can, within any part of the code, activate an environment (they call it a dictionary, which is very similar to a C structure). And they stack, so that something not in the active environment can be automatically looked up in a parent environment.

Post reply on HN