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

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

wordsandbuttons.online

Post reply on HN
Print view View original

81–90 of 184 posts

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

#81

Post by Guthur »

cultus wrote: post #70
crazygringo wrote: post #12

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

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.

And yet after 30+ years no one had adequately managed to replace it. God help us if it's one of those json based abominations. My main complaint with sql is that it can be somewhat difficult top make DRY.

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

#82

Post by colejohnson66 »

tonic-music wrote: post #53
jorams wrote: post #44

> The INCITS 226–1994 standard consists of 1153 pages. This was only beaten by C++ ISO/IEC 14882:2011 standard with 1338 pages some 17 years after. C++ has to drag a bag of heritage though, it was not always that big. Common Lisp was created huge from the scratch. This is a surprisingly incorrect remark, given that the author is apparently fairly well aware of programming language history. Common Lisp is a relatively…

Indeed. The original description of Lisp included something like 10 primitives. That's it. Numerous examples of full-blown Lisps have been built from just those few primitives. One article I read even showed how arithmetic can be built from car and cdr.

Source? I’d love to read more about this

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

#83

Post by kazinator »

fooker wrote: post #76
sifoobar wrote: post #72

Earlier quoted context omitted.

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.

So the Haskell to C++ rewrite in your earlier example is supposed to be beneficial, because fresh-out-of-school code monkeys will understand it?

How so if all they speak is JS and Python.

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

#84

Post by magicmouse »

There are some good points in this article, namely that a very lengthy language specification is a sure sign that the language is overblown and probably the victim of design by committee. Modula-2 had a 100 page description, and i would take it over C++ any day. Heck C++ still doesn't have separate compilation. It is a total pile of crap IMHO.

Another good point is that languages that facilitate domain specific languages create maintenance problems, which they do. Nothing fun about taking over some giant code base that has invented its own syntax, and of course the designers left minimal (or worse, incorrect) documentation.

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

#85

Post by miguelrochefort »

crazygringo wrote: post #12

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

> The second example is all words without punctuation, which requires me to read the entire thing word-for-word to figure out what it's doing.

Do you think that's also a problem with natural languages (e.g. English)? Should we switch to a more readable natural language with a syntax inspired by programming languages (or even visual programming languages)?

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

#87

Post by munchbunny »

crazygringo wrote: post #12

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

I think the goal in general should be to minimize conceptual depth and maximize predictability for the problem domain you are trying to address.

I dislike the C style for several reasons:

> FILE * test_file = fopen(“/tmp/test.txt”, “w+”);

First, you have to understand the implications of it being a pointer, which includes the little warning light in your head about ownership and allocation/deallocation. Then you have to remember that "w+" translates to "write in append mode". The fact that it's a string means you know it by memorization. But also there are warning lights in your head about text encoding... just standard things you're trained to be vigilant about. Where you can avoid triggering those reactions, I think it's worth trying.

These days we have the help of IDE's as memory aids, so for things like "w+" I prefer enums so that a tap of the auto-complete button shows you "write mode" and "append mode" options.

I suppose if I were to have any marginally controversial opinion on this topic, it's that I believe we should be embracing IDE's as "portable stack overflows" and designing languages with IDE assistance in mind.

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

#88

Post by dkersten »

cultus wrote: post #70
crazygringo wrote: post #12

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

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.

Personally, I much prefer writing queries in plain SQL than using an ORM unless it’s for trivial things.

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

#90

Post by MauranKilom »

jacobolus wrote: post #38
justinator wrote: post #14

Earlier quoted context omitted.

I think the OP perhaps wants to look at Apple Script?

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.

Post reply on HN