Live data from Hacker News

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

wordsandbuttons.online

41–50 of 184 posts

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

#41

> 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 wholeheartedly agree with you on this.

`create file /tmp/test.txt for input and output as test_file`

To me, this does not explain what's happening here with any clarity. I'm left feeling overwhelmed with uncertainty and ambiguity.

Is there an iterable being acted on? Is this blocking? Is it creating a variable? Two variables? What type is /tmp/test.txt when it has no quotation marks, and how does it handle spaces or concatenation/methods?

Those questions are just the tip of the iceberg. It goes on and on.

Not only that, but you're actually saving time by utilizing symbols rather than words. There's so much decoding that goes into reading a whole entire word/sentence rather than just flowing and gliding along symbols and keywords. There's a reason why mathematics in general typically uses symbols rather than these huge verbose chunks that are open to interpretation.

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

#42

Earlier quoted context omitted.

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

The OP wants a modernized COBOL.

In fact, that's what they say after clicking the buttons at the bottom - which are actually part of the article.

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

#43
I do not agree much of that. English language writing is not precise enough to program a computer; it should be made more concise. You need to have more types such as integer or floating, 32-bits or 16-bits or 64-bits, etc. Better macros than C should be needed, in order to make the more powewrful kind of macro. I don't like "read only" programming languages such as Inform7. Also, different program languages are made for different use, and so should have different stuff in their doing. For programming one specific kind of computer, you can use assembly language.

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

#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 successful attempt to standardize and bring together a lot of different Lisp varieties that evolved over decades.

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

#45

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

In support of what your are saying, here are some things that make programming _actually_ difficult:

- Reasoning about what the program should do in edge cases (e.g. if one write succeeds but the other fails)

- Designing data structures to represent complex information (e.g. deciding how to annotate an AST with type information)

- Determining if some functionality of a method is ever used

- Avoiding leaking data, even through side channels (like timing attacks)

- Making an interface that is hard to misuse

- Understanding how to use a poorly designed interface

- Understanding the performance implications of different designs

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

#46
> Down with the syntax!

Yes, exactly! But replacing one syntax by another is not "down" with the syntax. Even the natural language inspired version is still a text. A sequence of characters bound by a syntax and comes with the same limitations. I would like to see more projectional editing / structure editors.

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

#47
post #15

People, don't comment before you read the whole article (and click on the survey on the bottom)...

Thanks for pointing this out. There really isn't any way to tell that the rando survey at the bottom is not actually a survey. I read what I thought was the whole article, but demurred from participating in the "survey."

The problem with English is that it's so ambiguous. The author wanted it to be obvious that you should click that button to see his conclusion but ambiguous English seems to have led many readers to misunderstand his intent. If only we had languages that could express things with less ambiguity, perhaps by incorporating symbols and stricter grammar.

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

#48

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

In support of what your are saying, here are some things that make programming _actually_ difficult: - Reasoning about what the program should do in edge cases (e.g. if one write succeeds but the other fails) - Designing data structures to represent complex information (e.g. deciding how to annotate an AST with type information) - Determining if some functionality of a method is ever used - Avoiding leaking data, eve…

I'm going to take it one further. All of those are good but I think there are some "easier" and more fundamental things that are massive roadblocks for beginning programmers.

- Understanding the problem itself

- Determining how to actually solve that problem

- Expressing all the details of the solution you've chosen.

- Determining what has gone wrong and why

- Knowing when to step back and try another approach

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

#49
post #39
post #20

Earlier quoted context omitted.

I don't think you can blame the people for reading all the words and deciding not to vote on the survey.

If you read all the words, wasn't it fairly obvious already without clicking to vote from the last few lines?

"The language for the 21st century should be business oriented, English-like and not dependent on native types.

The most exciting thing, we already have the language exactly like this! What do you think it is?"

Not to me, no. I thought this what some poll to gauge popularity of he various languages or some such.

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

#50
So, COBOL for everyone then? lol. Your "create file" example looks exactly like COBOL. I disagree completely that business-oriented languages (the BO in COBOL stands for "Business Oriented") are the answer.

You decry DSLs because they are "worthless" for the user to learn -- but you forget that they make the work of the original developers that much easier, which is why they exist.

You bring up Lisp as an example and then are upset at its size. If there is one language to rule them all (or at least one that's covered all the bases), it would have to be Lisp. Of course, there's no one perfect language for everything. To paraphrase Ansel Adams, there's no perfect language only the perfect language for the kind of programs you write.

Post reply on HN