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.”
If I were to invent a programming language for the 21st century
71–80 of 184 posts
Re: If I were to invent a programming language for the 21st century
#72Earlier 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.
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
#73I 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…
Re: If I were to invent a programming language for the 21st century
#74I 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…
Re: If I were to invent a programming language for the 21st century
#75I 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.
Re: If I were to invent a programming language for the 21st century
#76Earlier 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…
Re: If I were to invent a programming language for the 21st century
#77Earlier 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…
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
#78Maybe 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
#79Author 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…