Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The perfect programming language

cygni.se

Post reply on HN
Print view View original

91–100 of 108 posts

Re: The perfect programming language

#91

Post by kick »

gmueckl wrote: post #9
nickserv wrote: 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.

For me it was the blatant rejection of C++ without any further discussion. C++ has a lot of baggage from C, but it also sports powerful metaprogramming, even though that is flawed (the necessity of SFINAE speaks volumes...). There are newer languages that improve on that a lot. The author doesn't even care to mention them by name. To me, it is pretty clear that the author has a very specific world view, probably defi…

You just acknowledged that C++ was not the perfect programming language in your (rather biased for it) comment.

Re: The perfect programming language

#93

Post by Quekid5 »

abathologist wrote: post #81
tome wrote: post #72

Earlier quoted context omitted.

> By your (imo, extremist) line of reasoning, wouldn't the existence of `unsafePerformIO` mean Haskell itself "looses its ability to reason reliably about operations over time"? By your (imo, extremist) line of reasoning, wouldn't the existence of `unsafePerformIO` mean Haskell itself "looses its ability to reason reliably about operations over time"? Well no, because for some reason, be it social or technical, peopl…

Yeah, that's my point. Contrary to the claim in the post I'm replying to, it seems clear that having the ability to do unsafe impure things in a language doesn't mean users of that language "loose all ability to reason reliably". To the extent that the libraries and the ecosystem doen't make inappropriate use of unsafe behavior, you can have your impurity and reliable referential transparency too.

I definitely agree that "lose all ability[...]" is probably a tad too strong :).

> To the extent that the libraries and the ecosystem doen't make inappropriate use of unsafe behavior, you can have your impurity and reliable referential transparency too.

The key qualitative difference between Haskell and e.g. O'Caml/Scala/whatever here is that it's quite trivial to verify that your program doesn't use side effects inappropriately (aka. is not referentially transparent): Just make sure it contains no unsafeFoo calls. There's no such mechanism in O'Caml/Scala, etc. (I'm not sure, but I imagine it might even be undecidable unless you restrict to a teeny tiny subset of the language, e.g. just the pure arithmetic expression language.)

The qualitative difference in how confident you can be that moving a bit of code around won't change the semantics of your program is profound (or: bonkers) -- and before I'd experienced it myself I could have (rightly!) been extremely skeptical of such claims, yet here I am making that claim.

Yes, unless you really want to fully vet all of your transitive dependencies you will have quite a large TCB, but I find that it's actually really rare for libraries to use unsafeFoo willy-nilly. Some of the low-level stuff like Text, Vector, etc. do, but AFAICT it's mostly for performance reasons... and DGMW quite serious bugs have been found in these. However, because these are isolated data structures these bugs get fixed once and they are immediately fixed for all users.

Another wart wrt. a large TCB in Haskell is IO. Unfortunately, it has a very large surface area, but there's no really much that can be done about that at this point. Even still, as a programmer you can choose to use e.g. polysemy/fused-effects/etc. to define the semantics of effectful code in a much more fine-grained way such that the only point of contact between your code and IO is in a tiny "interpretation of semantics" layer.

Re: The perfect programming language

#94

Post by Mikhail_Edoshin »

otabdeveloper4 wrote: post #5

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

Could you please elaborate? Deep down everything is machine code anyway; the farther we get from that, the less and less "real" our concepts are. Closures, monads, or lenses (I still have no idea what the latter two are) -- they feel kind of powerful but they're really only rearrangements of the same plain old data structures plus some implied pattern of their usage. Do you feel they're necessary for quality? What is your definition of quality?

At the very least these concepts are less efficient, which lowers quality in the efficiency dimension. For example, in assembly it's very easy to detect integer overflow; in C, which is still fairly low-level, there's no direct way to do this and people invented various workarounds. They are less efficient, but portable. Does this raise the quality as you understand it?

(BTW, there were a few attempts to write an OS in assembly (Menuet, Kolibri), now they seem to be mostly abandoned, but the intermediate results were fairly impressive: getting from boot to GUI in less than 10 seconds is something modern "big" OSes are utterly incapable of. This definitely looks like quality at least in some dimension.)

edit: typos.

Re: The perfect programming language

#95

Post by pjmlp »

majewsky wrote: post #85
pjmlp wrote: post #78

Earlier quoted context omitted.

It is, because the issue is the language semantics to deal with typical UI workflows. You are forced to use Rc > and clone everywhere, or copy objects around, reactive style, to kind of work around borrow checker ergonomics.

Only if you use a binding to a traditional UI framework. There is an opportunity here to research wholly new classes of UI frameworks. Data binding like in React lends itself nicely to ownership/borrowing semantics, for example. The React-like Relm may only be a first glimpse of what's to come.

Reactive UIs produce too many allocations, most developers aren't comfortable using them and most importantly lack of UI designers.

Re: The perfect programming language

#97

Post by pjmlp »

bwanab wrote: post #68

I worked at one of those other company's that designed Ada specs that didn't get selected, but we did do the first official ALS (Ada Language System). "first Ada was so complex that even the compilers had performance problems, so there was a bit of a delay getting it out" This was largely true. The complexity of compilation really bit. But, ", and then, second, C and Unix happened" This is silly. Unix and C had been…

Maybe he means, "happened across the industry".

Until the mid-90's Portuguese computing world, UNIX was only seen at some universities and eventually government level businesses.

Everyone else was using some kind of mainframe, or the typical 8 and 16 bit micros, mostly networking over Novel NetWare.

I only bothered to learn C when we had introduction to OSes, where our teacher would carry a single 486 PC from an university lab into the class room, running Xenix, to be shared across the whole set of students.

Each preparing their samples in Atari, Amiga and MS-DOS systems, followed by copying the stuff into a floppy and being allowed a short timeslot to try out our stuff.

So maybe that was where he was coming from, or then again, maybe not.

Re: The perfect programming language

#98

Post by pjmlp »

Mikhail_Edoshin wrote: post #94
otabdeveloper4 wrote: post #5

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

Could you please elaborate? Deep down everything is machine code anyway; the farther we get from that, the less and less "real" our concepts are. Closures, monads, or lenses (I still have no idea what the latter two are) -- they feel kind of powerful but they're really only rearrangements of the same plain old data structures plus some implied pattern of their usage. Do you feel they're necessary for quality? What is…

I guess you mean a few attempts to write FOSS OS in Assembly, plenty of past OSes where written in Assembly, with CP/M alongside MS-DOS and their derivatives being the most successful ones commercially.

Re: The perfect programming language

#99

Post by pjmlp »

Gibbon1 wrote: post #87
MaxBarraclough wrote: post #84

Earlier quoted context omitted.

You can disable optimisation if you want faster builds. The existence of optional optimisations isn't a problem.

Of course not the problem is C++ compilation and link model is fundamentally broken from a performance stand point.

Hence C++20 modules.

Re: The perfect programming language

#100

Post by pjmlp »

hhas01 wrote: post #18
otabdeveloper4 wrote: post #5

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

I doubt there is any C developer in the universe that would be able to win a Pub Quiz with 100% success rate, yet many would deem the language as being simple.
Post reply on HN