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

All Programming Languages are Wrong (2018)

users.rcn.com

Post reply on HN
Print view View original

61–70 of 79 posts

Re: All Programming Languages are Wrong (2018)

#61

Post by jerome-jh »

mfDjB wrote: post #16

Does anyone else consider these type of articles the clickbait of the programming world? They tend to all follow the formula of 1. Make over the top statement in title. 2. Vaguely address the over the top statement in content. For example the author hasn't shown us why "All" programming languages are "wrong". They haven't shown how they would fix them to make them "right". Their premises (e.g. "computation is almost…

It is not an article but the annex of a complete book, whose author was not arrogant enough to make this text the introduction. Nonetheless I agreed with most of the points and saved the URL of the table of content for later review.

Re: All Programming Languages are Wrong (2018)

#63

Post by _bxg1 »

gridlockd wrote: post #55
_bxg1 wrote: post #6

Pretty vague and empty argument (rant?). Doesn't really say anything I haven't seen complained about (and disputed) elsewhere and doesn't really propose any actual solutions.

> ...doesn't really propose any actual solutions. The proposed solution is the language he designed: http://users.rcn.com/david-moon/Lunar/introduction.html

Ah. That could've been made more clear in the link title

Re: All Programming Languages are Wrong (2018)

#64

Post by mrgriffin »

karmakaze wrote: post #57
dkersten wrote: post #34

Earlier quoted context omitted.

Slightly off topic, but what should a map or flatMap implementation on boolean do? Presumably run on true and skip on false? That’s not really what I expect from map (that it’s filtered the input). I could imagine book.filter.map as a way to conditionally execute

I rather like that, `if condition` is a 0/1 iteration with no input. flatMap can return empty, what should map return when run on false, None?

I'd probably think of Bool as being isomorphic to Maybe (), which would mean your map implementation looks a bit like:

    map :: Bool -> (() -> b) -> Maybe b
    map True f = Just (f ())
    map False _ = Nothing
Or, in Haskell because you've got laziness you could go with:

    map :: Bool -> b -> Maybe b
Which already exists as a combination of Control.Monad.guard and Data.Functor.(
    map tf b = b

Re: All Programming Languages are Wrong (2018)

#65

Post by valenciarose »

Referring to David Moon namelessly as "the author" in comments about language design (on Hacker News of all places) does not inspire confidence. Whether or not you agree with him, Moon has been involved in language design and implementation for decades. His perspective is directly relevant to discussion that's primarily focused on large scale trends in language design. I don't necessarily agree with everything he says here, but it is definitely worth thinking about, especially where it challenges accepted dogma.

Re: All Programming Languages are Wrong (2018)

#66

Post by dllthomas »

krzepah wrote: post #59
mfDjB wrote: post #16

Does anyone else consider these type of articles the clickbait of the programming world? They tend to all follow the formula of 1. Make over the top statement in title. 2. Vaguely address the over the top statement in content. For example the author hasn't shown us why "All" programming languages are "wrong". They haven't shown how they would fix them to make them "right". Their premises (e.g. "computation is almost…

I simply agree with what you said. "Computation is always free" made me cringe as well. I also felt that the initial page is abruptly stopped without giving any kind of explanation. Then clicking next you get jumped into a new language implementation : /

The statement was "almost free", which is much more defensible than "always free", even if it doesn't fit every context.

If we're limiting what we mean by "computation" to a few extra non-branching instructions on data we already have, I would probably even endorse it outside particularly unusual settings.

Re: All Programming Languages are Wrong (2018)

#67

Post by dllthomas »

warpspin wrote: post #50
quelltext wrote: post #14

Earlier quoted context omitted.

I am probably in the minority here but I think Java was on the right track with checked exceptions.

Always hated checked exceptions because there seems the basic assumption underlying them, that exceptions can usually be handled as near to the code throwing it as possible, while in every real world project I ever was involved in, 90% of the possible exceptions usually had to be handled "far away". So this means, you will have a whole bunch of re-throws, or exceptions wrapped in "higher design level" exceptions whic…

I think the problem with checked exceptions was that we got a woefully limited language for talking about them. Checked exceptions with generics (and inference?) might be a very different experience.

For instance, Java's checked exceptions break higher-order functions. A map function should be able to say "I can throw anything my argument can throw". Some wrapper functions might say "anything my argument can throw, minus FooException because I catch it, plus BarException because I might raise that myself."

Re: All Programming Languages are Wrong (2018)

#68

Post by patrec »

perfobotto wrote: post #8

What a bunch of bs. There are so many places where computation is far from free and size matters (embedded, HPC for example). And the end of Moore law is just gonna emphasize the need for performance even more. This article just tells me that the author didn’t have to write any performance critical code in his life and he just extended his experience to everything

Yeah, what would David Moon of all people know about performance critical code.

https://www.h2o.ai/blog/a-brief-conversation-with-david-moon...

Re: All Programming Languages are Wrong (2018)

#69

Post by bedobi »

warpspin wrote: post #50
quelltext wrote: post #14

Earlier quoted context omitted.

I am probably in the minority here but I think Java was on the right track with checked exceptions.

Always hated checked exceptions because there seems the basic assumption underlying them, that exceptions can usually be handled as near to the code throwing it as possible, while in every real world project I ever was involved in, 90% of the possible exceptions usually had to be handled "far away". So this means, you will have a whole bunch of re-throws, or exceptions wrapped in "higher design level" exceptions whic…

With functional error handling, every method just returns an object. If the caller doesn't want to do anything with it, it can just pass it on somewhere else. Only once you actually care about filtering, mapping, flatMapping, folding etc do you actually need to handle the different cases.

It's just so much better and easier to understand than exceptions! Doesn't require any special syntax or mental gymnastics to understand the execution path either.

Re: All Programming Languages are Wrong (2018)

#70

Post by bedobi »

dllthomas wrote: post #67
warpspin wrote: post #50

Earlier quoted context omitted.

Always hated checked exceptions because there seems the basic assumption underlying them, that exceptions can usually be handled as near to the code throwing it as possible, while in every real world project I ever was involved in, 90% of the possible exceptions usually had to be handled "far away". So this means, you will have a whole bunch of re-throws, or exceptions wrapped in "higher design level" exceptions whic…

I think the problem with checked exceptions was that we got a woefully limited language for talking about them. Checked exceptions with generics (and inference?) might be a very different experience. For instance, Java's checked exceptions break higher-order functions. A map function should be able to say "I can throw anything my argument can throw". Some wrapper functions might say "anything my argument can throw, m…

With functional error handling, you don't need neither checked nor unchecked exceptions, everything just returns objects, and the language and syntax used for talking about them is the same as the language and syntax used for everything else (map, filter, flatMap, fold etc etc).
Post reply on HN