Live data from Hacker News

If I were to invent a programming language for the 21st century

wordsandbuttons.online

71–80 of 184 posts

Re: If I were to invent a programming language for the 21st century

#71
I would love to see a language re-embrace the elegance of Smalltalk block closures. I quit doing Smalltalk 8ish years ago. I’m happy enough with python and swift and Kotlin (and a lot of firmware C as well). They all have closure/lambda like stuff, but none of them are as simple/universal as the Smalltalk semantics/model of closures was.

The other thing I’d want is something better than generics. As I moved away from dynamic languages, I found I was ok with the swift/Kotlin type system mostly. Except for when generics get involved. For all but the trivial cases, I always feel like I have to really downshift to work through the compiler errors. It’s like me and the compiler just quit understanding each other. I don’t have the tools to express “this is what I want to do, you figure it out” and the compilers just say things “all your types are belong to us.”

Re: If I were to invent a programming language for the 21st century

#72
post #67

Earlier quoted context omitted.

How much experience do you have from C, Forth & Lisp? Spend enough time in these languages and you start seeing the world differently. Less syntax (when designed well) doesn't have to be unreadable.

How much experience do you have with 10000 lines+ codebases written in Forth or Lisp? There is a reason people choose boring imperative languages for large projects. I did an internship at an 'Big 4' company which (from folklore) had a moderately large server written in Haskell, the codebase was a nightmare and eventually they ended up rewriting it in C++, which I believe they still use.

None, but that has very little to do with how capable the languages are in the hands of experienced coders. There's a ton of Forth being written in embedded circles, and several well known Lisp projects that are most probably even bigger.

And that's fine, they can keep writing their big projects using dumbed down languages and fresh out of school code monkeys. But there is plenty of code written that doesn't fit into that description.

Re: If I were to invent a programming language for the 21st century

#73

I would love to see a language re-embrace the elegance of Smalltalk block closures. I quit doing Smalltalk 8ish years ago. I’m happy enough with python and swift and Kotlin (and a lot of firmware C as well). They all have closure/lambda like stuff, but none of them are as simple/universal as the Smalltalk semantics/model of closures was. The other thing I’d want is something better than generics. As I moved away from…

I’d like to see Macros used to solve this instead of generics, then you have control to say what and how you are retrieving.

Re: If I were to invent a programming language for the 21st century

#74

I would love to see a language re-embrace the elegance of Smalltalk block closures. I quit doing Smalltalk 8ish years ago. I’m happy enough with python and swift and Kotlin (and a lot of firmware C as well). They all have closure/lambda like stuff, but none of them are as simple/universal as the Smalltalk semantics/model of closures was. The other thing I’d want is something better than generics. As I moved away from…

Scala blocks-as-closures are fairly simple and universal.

Re: If I were to invent a programming language for the 21st century

#75
post #9

I really disagree with the author's points about macros. If your language doesn't support macros you'll end up with programs that parse some arbitrary code and generate code in the language you're working with. That's far worse than a macro system that at least works in the confines of a language's syntax.

Yes I completely agree, I wish Golang would add compile time macros that have enough information to replace the desire some have for generics. It would make Go a much superior language as you would be able to supply a sensible amount of DRY to your code.

Re: If I were to invent a programming language for the 21st century

#76
post #67

Earlier quoted context omitted.

How much experience do you have with 10000 lines+ codebases written in Forth or Lisp? There is a reason people choose boring imperative languages for large projects. I did an internship at an 'Big 4' company which (from folklore) had a moderately large server written in Haskell, the codebase was a nightmare and eventually they ended up rewriting it in C++, which I believe they still use.

None, but that has very little to do with how capable the languages are in the hands of experienced coders. There's a ton of Forth being written in embedded circles, and several well known Lisp projects that are most probably even bigger. And that's fine, they can keep writing their big projects using dumbed down languages and fresh out of school code monkeys. But there is plenty of code written that doesn't fit into…

Sure, they are awesome languages. We are talking about readability though, which unfortunately means your code has to be readable by "fresh out of school code monkeys" and not just experienced coders.

Re: If I were to invent a programming language for the 21st century

#77
post #7

Earlier quoted context omitted.

I don't agree with 'less syntax'. More syntax (when designed well) results is significantly more readable code.

Up to a point, perhaps. Say you have both `if` and `unless` control structures. Two keywords where you could have just one, but they're closely related enough that there's not much burden. But what if their grammar was completely different, like say: ifStmt := "if" "(" expression ")" statement ( "else" statement )? unlessStmt := "{" exprStmt exprStmt* "}" "unless" expression ";" I doubt this additional syntax would b…

Would you same the same thing about loops?

You can get away with just providing a 'while' loop (or maybe just goto and labels).

Most languages end up with a for and maybe a repeat-until syntax for the sake of natural looking constructs.

Re: If I were to invent a programming language for the 21st century

#78
I like the twist at the end of saying it already exists and it is COBOL.

Maybe the reason nobody uses COBOL is for the exact reasons mentioned in the article.

The author really wants to make an ambiguous, confusing language not fit for logic or any form of serious data processing. Which is pretty much entirely useless.

Re: If I were to invent a programming language for the 21st century

#79
>It’s naïve to think that the language is responsible for the quality of code and that by adding some bells and whistles (or removing some bells and whistles), we can automatically make everything better.

Author doesn't understand the work done in language research, thus must be pointless.

>We were not happy with Fortran and COBOL, so we invented C++ and Java only to be unhappy with them too in some 20–30 years.

Great, so let's stick to the thing that made us even less happy. Screw gradual improvements, revamp the field or go bust.

>But we have to blame something. Being software engineers partially responsible for the world of crappy software, we wouldn’t blame ourselves, would we? So let’s blame the tools instead!

I fuck up all the time, my colleagues fuck up all the time. Some tools are actively helping us make fewer fuck ups over time.

With this article, the author is pretty much coming out as the archetypic blub programmer. He sees all this "new, seemingly pointless stuff" polluting an area he believes to be knowledgeable at, and rather than make the effort involved in trying to understand why people are bothering at all, it's easier to say "it's all a waste, you should just learn to program in blub, since you're only reinventing blub but with crap added in".

Re: If I were to invent a programming language for the 21st century

#80

> Ultimately this: > FILE * test_file = fopen(“/tmp/test.txt”, “w+”); > Should become something like this: > create file /tmp/test.txt for input and output as test_file > Syntax highlighting should work instead of syntax notation just fine. I couldn't disagree more. The first example is easily scannable visually -- a variable is being created from a function call. I can tell because my eyes immediately notice the mid…

Someone didn't finish reading the article...
Post reply on HN