Live data from Hacker News

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

wordsandbuttons.online

141–150 of 184 posts

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

#141

Earlier quoted context omitted.

Yes, this proposal is basically AppleScript. AppleScript is (relatively) easy for non-programmers to read and understand, because it is built on natural language. Unfortunately AppleScript is a huge pain to write , because as a programming language it is still quite strict about what type of syntax it will accept. It also is fairly limited, because speccing a natural language programming vocabulary/grammar gets incre…

In my experience, the problem people have with learning programming is not syntax or abstraction - it's thinking like the abstract machine. Or in other words, understanding that having an array and a loop in your code isn't enough to make the computer understand and do what you want. Basically, the thing that the PB&J exact instructions challenge teaches.

It's interesting you mention an array and a loop, because those can be separate abstractions too.

no need to think about loops: array.each {|x| puts x}

need think about loops: for i in 0...array.length do puts array[i] end

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

#142
post #138
post #70

Earlier quoted context omitted.

Very much agree. Programming notation, like math, is supposed to be easy to convey exact meaning, unlike human language. Every attempt there has been to make code look like English hasn't worked out well. SQL, for example, is incredibly verbose, with complex syntax. This obscures what is otherwise very good semantics. I think this is why a lot of people hate writing queries.

>Every attempt there has been to make code look like English hasn't worked out well Not true. Ruby is incredibly readable

I'm not a Ruby programmer but have over the course of my career had numerous occasions where I had to look at "incredibly readable" Ruby code.

No, no it isn't. Sure, you can infer some meaning in the various "DSLs" without knowing any Ruby but you're left facing exactly the problems of ambiguity the GP pointed out.

You know what the words mean because they're just English words but you don't know their exact definitions in that specific context. And even if two "DSLs" use some of the same vocabulary that doesn't mean the words will mean exactly the same thing.

It's just hiding the arbitrary implementation behind a very ambiguous API that might read as two completely different things to two different readers. Let alone trying to manipulate the program (at which point you realise that even though it's supposedly a "DSL for laypeople" you still need to understand Ruby idiosyncrasies to be able to work with it).

Ruby is not incredibly readable. Ruby is however capable of letting you create APIs that make code look a lot like plain English language. That doesn't mean the code "reads" like plain English language because unlike plain English language it's just a bunch of whimsical function and variable names with arbitrary implementations.

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

#143

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

Completely agree. A balance is needed between the tenseness of Perl and the verbosity of AppleScript. Too compact, and the language becomes a pain to read — although I am sure the author feels clever at having accomplished so much in so little code. On the other side, too verbose and it is a pain to write and read. I absolutely hate reading through or writing pages upon pages of code to accomplish a trivial task.

Perhaps that is the reason languages like Python have been so successful. They seem to strike a good balance. I am not suggesting they are perfect by any means — they have their own fair share of compromises, but they do the job well enough. And I certainly don’t want to be writing COBOL in 21st century. :-)

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

#144

> The language for the 21st century should be business oriented, English-like and not dependent on native types. It is shocking to me how often the problem of "programming is difficult and time consuming and unintuitive" is to be resolved by "making programming languages more like English". The language is there as a tool to make programming easier! Do you know how many times I've taken someone's keyboard to type a t…

> Do you know how many times I've taken someone's keyboard to type a tiny snippet and then explained it in English with the code as reference? Why do you think I don't just explain it in English first? Because English is verbose and ambiguous and not suited to describing logic. That's what programming languages are for.

Exactly this — and it is true about any human language. They were built for humans who are capable of interpreting things given the context. Try covering every single case in English and you have a lengthy legal document which no one wants to read — and it still has some ambiguity left.

If you want an example of what English would look like if used for programming, take a legal document and multiply it by 100.

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

#145
Programmers are too myopic about programming. It always looks the same - long strings of text. And that's the only domain in which we can think. Any (developer) usability problem is always seen as a language problem.

Well, creativity is constraint. What we're actually doing with all of this language is exploring a space of constraints on the Turing machine. But I would argue it's actually a small sub-space of the full thing. For example, you could fix (modern) browser JavaScript and explore what you can do with that. And this is, in fact, what "frameworks" actually do! And a framework does this by providing a higher-order data-structure that the programmer "fills in" with tiny bits of programming language.

Meanwhile, this higher-order data-structure is informed by the lower-level constraints of the language, both in form (syntax) and function (paradigm). So basically this is a huge space, but it feels like parts of it are falling into place. Emphasising pure functions, immutable, serializable data-structures, certainly makes filling in those lines of code much more pleasant! So, Elm and Redux in particular have staked out an excellent spot in this space, in my humble opinion.

But the problem of developer usability is much bigger than language!

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

#146

What's the purpose of a new language? You can't just say build a language for the 21st century. That's pretty arbitrary. Each computer language is designed to solve a particular set of problems. No language is the best. The down with syntax stuff is a particularly meaningless argument. Python probably has the most intuitive syntax of any "modern" language. I know many personal projects in python but very few professi…

> The lack of syntax makes python a great language for prototyping

And I thought Lisp had a lack of syntax.

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

#147

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

Which of these forms you use does not matter all that much. They both have the same semantics where a file is opened, and it is up to the programmer to remember to close it. What actually is a an improvement is Common Lisp's with-open-file or similarly, python's with:

  with open("somefile.dat", "wb") as f:
    f.write(somevar)
which automatically closes the file when it leaves the scope.

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

#148
I love this. The piece does a great job of showing that the languages you use won’t solve the problems inherently due to the programmers. Also does a nice job of showing how few people actually read the content before deciding that “they know better”.

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

#150
I like that the general feedback here is against Applescript-like "native english" syntax. There are certainly also good arguments for and against native types, which are critized by the OP.

However, I think blaming meta languages is a bit too meta. Sometimes they are just diabolical tools such as a C preprocessor (some of us hate C/C++ for lacking a proper dependency/build system, isnt it). I personally also will never be happy with the knotty C++ template programming, despite being functional.

But sometimes meta programming is put into a language from the first place with good intentions in mind -- think about Pythons class and function annotations (which I have found very nice frameworks built with) or the way how LISP programs work. Actually I also find RUST and Julia great for having the meta programming concept right at the core!

Doing HPC and bare metal programming daily, I cannot stress more that a well-engineered programming language like RUST would make my life so much easier. Code generation as a preceding step is daily buisness in my subject and that's not programming for the 21st century.

Post reply on HN