Live data from Hacker News

Most(ly dead) Influential Programming Languages

hillelwayne.com

281–290 of 291 posts

Re: Most(ly dead) Influential Programming Languages

#281
post #241
post #127

Earlier quoted context omitted.

Not sure I understand that one. I know Larry Wall is a linguist. But there's not much about Perl, to me, that seems like a human language. If I dig into the gripes about the syntax, it's usually use of the implied $_ variable, wide use of sigils ($, @, %), derefs of complex data structures (hash of lists of hashes, etc) or regex syntax that people are talking about.

That is one of the things that are so brilliant about Perl. Tell a developer to create a programming language inspired by natural languages and you'll get verbose crap like COBOL which superficially looks "natural" but is very far from how languages work. Perl, on the other hand, looks just like a programming language would if it was the only way we could talk to computers, day in, day out: - Implicit "it" variable,…

> That is one of the things that are so brilliant about Perl.

> - More than one way to say things

I respect that others may disagree, but I actually find this to be a major disadvantage in a programming language. From a readability perspective[1], having more than one way to express the same task is in my opinion a bad thing. As a trivial example, Perl supports both pre- and post-conditionals:

    if something then x = 1
or

    x = 1 if something
which I find super cumbersome to parse. In all cases, I have to keep the whole phrase in mind before I can understand it, because I don't know which way the phrase will go. If there was only pre-conditionals, or only post-conditionals, then I would know how to parse each part of the phrase before I have read the entire phrase, which makes it easier to parse complex phrases.

I think this is one major reason languages like Perl or C++ are often considered hard to read. Having so many ways to express the same thing means a major mental load until you've figured out what is trying to be expressed.

[1] By now we've all come to agree that easy reading of code is far more important than easy writing of code, right?

Re: Most(ly dead) Influential Programming Languages

#282
post #264

Earlier quoted context omitted.

If you leave the HN/SV bubble, you find huge amounts of Fortran. It's still plays a significant role in scientific computing. If you lost track of it in the '80s, you might be interested that the language had major updates in '90, '95, '03, '08 and 2018. It's just not a part of the world of cat pix sharing websites and innumerable "Foo of Bar" startups. Same with COBOL.

One thing I credit COBOL with is the use of descriptive variable naming. In FORTRAN you see variables named i, j, x etc (just look at Numerical Recipes) but in COBOL you see TOTAL_MONTH_SALES and the like. It is considered good style and “self-documenting” to do that today.

COBOL was intended from the start to be "self-documenting" and English-like with the thinking being that it could be used by 'non-programmers' to create business logic. Not sure that I buy it achieved that goal, but it was the intent.

Re: Most(ly dead) Influential Programming Languages

#283
post #255

Earlier quoted context omitted.

This is something else I've been thinking about lately as I read more about Smalltalk and Lisp. The people who have used the commercial Smalltalk and Lisp offerings from the 1980s and 1990s, including Lisp machines, seem to have had great experiences with these environments. They felt very productive in these environments, and they also lament the state of today's development tools for more popular commercially-used…

That is why many of us that experienced those environments ended up gravitating around Delphi, Android, iOS, Java and .NET tooling. While not the same, it is the most mainstream stacks that are somehow close to those ones.

I can't see how something like Pharo Smalltalk is anything near something like Java unless you're comparing it to C++. Same thing with .NET. Those tools are all fine in their own way (high performance, extremely fine tuned garbage collectors, and extremely large libraries), but I can't see them being as productive once you're up to speed.

Re: Most(ly dead) Influential Programming Languages

#284

Earlier quoted context omitted.

I'm still trying to reconcile "most influential" with "nobody's ever heard of". It may be that CLU implemented in premiere some concepts, but if later those concepts may as well just have been rediscovered (like the iterator design pattern) as the obvious thing to do, then what that leaves us?

> reconcile "most influential" with "nobody's ever heard of" We ignore the past. I've worked with people who hadn't heard of Alan Kay. I worked with a guy tasked to revamp an expert system who had never heard of Prolog.

I work with a lot of people who write software and a few professional developers (~10-20 years experience in .NET & Java) and only one of them (has a computer science degree) has ever heard of Prolog and neither had ever heard of Smalltalk, APL, Forth, or Lisp when I brought them up around lunch. They're great at what they do and are much more experienced/talented than I at creating software, but it always makes me wonder why more professional software developers aren't more curious about the past and other alternative solutions. I can tell you how engineers did my job each decade going about 100 years back and how all the tools evolved over that time.

Re: Most(ly dead) Influential Programming Languages

#285

Earlier quoted context omitted.

> reconcile "most influential" with "nobody's ever heard of" We ignore the past. I've worked with people who hadn't heard of Alan Kay. I worked with a guy tasked to revamp an expert system who had never heard of Prolog.

I work with a lot of people who write software and a few professional developers (~10-20 years experience in .NET & Java) and only one of them (has a computer science degree) has ever heard of Prolog and neither had ever heard of Smalltalk, APL, Forth, or Lisp when I brought them up around lunch. They're great at what they do and are much more experienced/talented than I at creating software, but it always makes me w…

[deleted]

Re: Most(ly dead) Influential Programming Languages

#286

Earlier quoted context omitted.

It makes your eyes bleed? If you thought mine was a take ... Anyways, let's not act like ES6 classes aren't without their slew of issues, obscure syntax, and most importantly, problems when it comes to transpiling and backwards compatibility: https://medium.com/@WebReflection/a-case-for-js-classes-with...

"Let's" not, but I don't care about much of anything in that article. I haven't written something that targets a browser that isn't ES2015 since...2016. It's 2020. Things move on.

Great attitude. Let's move on and leave 13% of the global internet population behind.

Re: Most(ly dead) Influential Programming Languages

#287

If you're at all interested in this topic and have access to the ACM library, the 'History Of Programming Languages' (HOPL) conference includes papers on these and many other languages and is fascinating reading.

And they just opened this up today! https://dl.acm.org/action/doSearch?AllField=HOPL&startPage=&...

Re: Most(ly dead) Influential Programming Languages

#288
post #241

Earlier quoted context omitted.

That is one of the things that are so brilliant about Perl. Tell a developer to create a programming language inspired by natural languages and you'll get verbose crap like COBOL which superficially looks "natural" but is very far from how languages work. Perl, on the other hand, looks just like a programming language would if it was the only way we could talk to computers, day in, day out: - Implicit "it" variable,…

> That is one of the things that are so brilliant about Perl. > - More than one way to say things I respect that others may disagree, but I actually find this to be a major disadvantage in a programming language. From a readability perspective[1], having more than one way to express the same task is in my opinion a bad thing. As a trivial example, Perl supports both pre- and post-conditionals: if something then x = 1…

Reading code is more important than writing it, but I'm not convinced that two ways to phrase the same conditional assignment is a bad thing. Or, rather, it might not be a bad thing that there are two ways to phrase the same conditional assignment.

See what I did there? Same meaning, different order of clauses. Emphasis ended up on different parts of the sentence! This is a very powerful out-of-band signaling path to control how the reader interprets the literal words, and being used to Perl where we also have it, it is weird to not have it in other languages.

Sometimes the actual predicate is the important/interesting bit, in which case putting it first makes sense: `if (user_is_underaged) return;`. Sometimes the predicate is not as interesting as the expression it's conditioning: `say "message" if debug_mode;`.

Re: Most(ly dead) Influential Programming Languages

#289
post #17
post #7

There are a few things present in COBOL that I would like to see lifted into more modern languages. One is the use of the full stop as an expression terminator, as in English, instead of the semicolon. Another is the whole "picture" mechanism for number formats. More languages should also steal Verilog's use of _ as an optional digit separator. It's just arrived in C# 7.

I think Nim also has digit separator.

It does.

Re: Most(ly dead) Influential Programming Languages

#290
post #241

Earlier quoted context omitted.

That is one of the things that are so brilliant about Perl. Tell a developer to create a programming language inspired by natural languages and you'll get verbose crap like COBOL which superficially looks "natural" but is very far from how languages work. Perl, on the other hand, looks just like a programming language would if it was the only way we could talk to computers, day in, day out: - Implicit "it" variable,…

> That is one of the things that are so brilliant about Perl. > - More than one way to say things I respect that others may disagree, but I actually find this to be a major disadvantage in a programming language. From a readability perspective[1], having more than one way to express the same task is in my opinion a bad thing. As a trivial example, Perl supports both pre- and post-conditionals: if something then x = 1…

You do realize that comes from english right?

    if $you-are-hungry { make-a-sandwich() }

    make-a-sandwich() if $you-are-hungry;
If you remove all of the non-letter characters, you are left with very understandable english sentences.

    if you are hungry make a sandwich

    make a sandwich if you are hungry
So unless english is a second language to you, it should be fairly easy to understand.

If you pay attention to how people use those different forms in english, you will also notice that the infix form of “if” tends to be used for simple short sentences. Which is exactly how I use it in Perl and Raku.

    sub factorial ( UInt $n ){
      return 1 if $n == 0;
      return 1 if $n == 1;

      return $n * factorial($n - 1)
    }
Though I might consider using `when` instead.

    sub factorial ( UInt $_ ){
      return 1 when 0;
      return 1 when 1;

      return $_ * factorial($_ - 1)
    }
Of course a junction would be useful

    sub factorial ( UInt $_ ){
      return 1 when 0|1;

      return $_ * factorial($_ - 1)
    }
You are probably having fits with that to.

The thing is, that also reads fairly well in english.

    return one when [it is] zero or one
Often times in informal english the “it is” in such a sentence is left off for brevity. So I left it off, because we are obviously talking about “it" (`$_`). I mean, what else could we be talking about? I could easily see this being said as a response to another person.

    > Alice: What result should we give the user?
    >
    > Bob: Return one when zero or one.  
    > Otherwise multiply it by …
You are probably thinking that communicating with a computer should be more formal. You should also be wearing nicely ironed clothes with a jacket and tie.

The problem with that is that you aren't communicating with a computer. You are communicating with everyone that is going to read your code. Reading a technical manual can be very tiring for even the most stoic of readers.

I prefer to read a well written novel. Good Perl and Raku code often reads more like a novel than a technical manual. Even when it is kept very precise about its semantics.

Which means that when I am done doing something in Perl or Raku, I want to continue doing more of that. I don't want to stop.

Sometimes I will find myself re-reading the same line repeatedly at 3am.

---

Further, note how I used the infix form of “if”.

    return 1 if $n == 0;
    return 1 if $n == 1;
The result on the left is very simple. Not only is it simple, it is the same for both lines.

It is very common to use it in this manner. Where they sit at the very beginning of a function as a kind of guard clause. The real important bit is the right part of the lines. Which actually stands out more than the left half, because it is closer to the center of the screen.

After those two lines, we know two things about `$_`. It is neither a `0` or a `1`, because we already dealt with both cases. So we don't have to worry about them in the rest of the function.

For the most part, when I see a line like that I know that I can safely skip over it. That is because it is almost only ever used for that type of thing. As a way to deal with simple cases early in the lifetime of a function. It also means that I can very quickly glean the information I need for that very same reason.

---

People tend to have a lot of bad things to say about Perl and Raku.

Almost everyone who has used them enough to get comfortable with either of the two languages would say just about the opposite to most of those things.

Basically, it's bad in theory, but it's good in practice.

Reminds me of a video “Clay Shirky on Love, Internet Style” https://www.youtube.com/watch?v=Xe1TZaElTAs (9m14s long)

Particularly this line:

> And it was at that moment that I understood what was going on. Because they didn't care.

> They didn't care that they had seen it work in practice, because they already knew it couldn't work in theory.

---

I very much agree that it is far more important to be easy to read. Which is why I find Perl and Raku to be awesome.

I can write things in the most readable way for a person as possible, rather than the only way the compiler can understand.

Post reply on HN