
If I were to invent a programming language for the 21st century - okaleniuk
https://wordsandbuttons.online/if_i_were_to_invent_a_programming_language_for_the_21st_century.html
======
crazygringo
> _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 middle
"=" first (easy to scan without reading) and the "(...)" in the second half
(also easy to scan).

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.

We certainly shouldn't aspire to regex-like syntax for programming... but we
also shouldn't aspire to prose. A healthy balance of words, punctuation, and
whitespace/indentation helps to let our eyes understand the structure of code
at a glance.

I'd argue that C-style syntax actually achieves this quite well, although I'm
also a fan of named (as opposed to ordered) function arguments.

~~~
cultus
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.

~~~
cm2187
I rather think Math is a good counter example. Or physics rather. There aren’t
enough greek letters in the alphabet to satisfy the average academic paper.
You first have to load in your memory the meaning of 20 different symbols then
decypher a formula before you can process it.

Now people who read lots of papers are probably used to this exercise but that
doesn’t mean it’s a good thing (you can get used to running on one leg, but
that doesn’t mean there aren’t better ways to run!). I am of the opinion that
initials, or full words should be used in formula.

~~~
Yetanfou
Those who are not used to the terminology of physics or math would not be able
to follow a paper no matter whether it was stuffed with the Greek alphabet or
nice descriptive names. They'd be baffled by the formulae and concepts and
lack the understanding needed to see the trees through the forest even if it
were written like prose, maybe even more so as a formula at least gives some
idea of what goes in and what comes out, what belongs together and in what
order things are to be seen by virtue of some easily understandable symbols.
While it is a fact that some people - often those who lack self-confidence -
revel in being obtuse to increase the appearance of them being the guardians
of some semi-magical 'Knowledge' this is not the reason why STEM-fields tend
to gravitate to their own 'secret languages'. This starts in school where
children learn that _1 + 1 = 2_ instead of _take the abstract number one, add
another abstract number one and you now have the abstract number two_.

------
reificator
> _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 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.

It's the same thing whenever someone makes a scratch clone but meant for real
work. If you limit your scope enough, _and_ you benefit from the visual
layout, I think it can be a productivity win. Otherwise, they just tend to
make the trivial stuff into drag and drop, and the easy stuff difficult or
tedious.

Unreal Engine's material and animation blueprints satisfy the above criteria,
and are a pleasure to work with IMO. But they're both laser focused on doing
one thing. With materials, seeing the output preview of each stage of the
pipeline is a great help. And with animations, it's essentially a state
machine, so seeing it graphed out in front of you is how you'd want to prepare
to write the code anyway. Both clear wins for having a visual layout, but I
want to stress that these are exceptions to the rule.

EDIT: Also should bring up Inform7[1] as another example of a focused tool
that benefits from not being code. If your goal is to write a text adventure,
it makes sense to use prose to create it. It also somewhat benefits the
authors who are typically more writers than engineers, but don't even think
that means you can just sit down and start writing it without a learning
phase.

[0]: [https://docs.unrealengine.com/en-
US/Engine/Rendering/Materia...](https://docs.unrealengine.com/en-
US/Engine/Rendering/Materials/Editor)

[1]: [http://inform7.com/](http://inform7.com/)

~~~
piinbinary
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

~~~
reificator
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

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

Not sure this is a popular opinion as presented by the author? I'd say the
most sought-after PL features would be expressive type systems and those that
reduce boilerplate. I've never heard someone long for a more "business
oriented" programming language.

>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 […] I feel like the
core issue here is in the domain of sociology and psychology, and not the
programming.

I'd disagree, e.g. Rust's semantics rule out whole classes of common runtime
errors. More expressive languages such as Kotlin, Scala, Swift, … are seeing
rapid adoption over their more boilerplate heavy counterparts, such as Java or
Obj-C. The desire for better languages is justified imho, as there's still a
lot to gain. New PL development is not rooted in neurotic unhappiness, real
progress is made.

~~~
kyle-rb
>I've never heard someone long for a more "business oriented" programming
language. I don't think that was a genuine opinion of the author, more just a
cheeky hint at the reveal that they were describing COBOL (COmmon Business
Oriented Language) the whole time.

------
mixedCase
>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".

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

~~~
twtw
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."

~~~
mattnewport
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.

------
jchw
I'm glad this took a turn because I was not following, AT ALL. But even that
last conclusion I only sort of agree with. If they are suggesting Go and Rust
and Kotlin bring nothing useful to the table, I suggest they reevaluate. I am
way more productive writing Go than C++, Mozilla invented Rust literally to
solve concurrency problems, and Kotlin saves you a ton of typing, which speaks
on it's own.

Yes there's hype. It's not about hype. It's about exploring permutations of
the tried and true. Applying what we've learned. You see a lot of composition
over inheritance - not because composition is a new concept, but because we
learned how inheritance can be bad. It's that simple.

~~~
orangecat
_Kotlin saves you a ton of typing_

And more importantly, it saves time and focus when reading code. You don't
have to manually parse dozens of lines to verify "yes, this is a standard
value object".

------
scarface74
Having a language that almost looks like English is actually harder to program
in than one that has a well defined strict syntax.

It falls into a sort of uncanny valley. Apple tried that sort of successfully
with Hypertalk but really badly with AppleScript.

------
defanor
The hidden twist itself is interesting, but the described features didn't
sound like they incorporate any PLT advancements of the past decades, with the
first one indeed reminding of older languages: I thought it's just somebody
describing the language bits they like for some reason, and saying that they'd
like new languages like that.

If they were more convincing, it would be surprising to see that they all were
already present in an old and somewhat forgotten language. Though the overall
article (and the conclusion in particular) seems to be more about rhetoric
than about reasoning. I agree with the conclusion, but it doesn't seem to be
backed well with (follow from) the rest of the article.

------
lispm
> And it’s huge. 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.

Common Lisp the Language was published in 1984 and it had 460+ pages.
Heritage? The language itself was mostly based on a larger earlier language:
Lisp Machine Lisp. That one had a language documentation, but not a standard.
The standard for Common Lisp was published in 1994, after eight years of work
from 1986 on. It was based on the 1984 Common Lisp, which was based on NIL,
S-1 Lisp, Lisp Machine Lisp and Spice Lisp - all projects which developed a
successor of Maclisp.

> A programming language should not be that huge. Not at all. It’s just that
> it should have a decent standard library filled with all the goodies so
> people wouldn't have to reinvent them.

Common Lisp in part is a larger Lisp dialect (but with a relatively small
number of built-in constructs:
[http://www.lispworks.com/documentation/HyperSpec/Body/03_aba...](http://www.lispworks.com/documentation/HyperSpec/Body/03_ababa.htm)
) and the standard includes a standard library - without actually dividing the
language into a core and a library.

------
Iv
If I were to invent a programming language for the 21st century, the main
feature that would make people frown is that it would not be laid down in a
flat text file.

\- It would allow high-level programming like constraints statements a la
Prolog.

\- It would allow graphical block building a la PureData

\- It would generate lower level version of these and allow a user to "zoom"
into the generated code down to the machine code (or pseudo-code).

\- It would allow to link from lower level imperative routines.

\- It would have a fucking wysiwyg GUI editor.

\- It would be designed to have a powerful IDE and a top-notch Intellisense. I
believe these need to be thought at the design step of the language, not added
later.

~~~
kens
> If I were to invent a programming language for the 21st century, the main
> feature that would make people frown is that it would not be laid down in a
> flat text file.

Yes! It drives me crazy that due to a historical accident, we're still
essentially writing programs as decks of 80-column punch cards. Nowadays the
decks are virtual and the editing tools are better, but languages really
haven't evolved to take advantage of modern I/O. I'll point out that the Xerox
Alto (1973) let you write your source code with full WYSIWYG formatting
(fonts, bold, italics, etc), so we've taken a step back since then.

~~~
dumbfoundded
I think that'd be useful for commenting but nothing else.

Whenever I see something in code, I wonder, what does this do? If I started
seeing bold and italics and it did nothing but draw attention, I would almost
certainly feel it a distraction.

~~~
henrikeh
> I think that'd be useful for commenting but nothing else.

But isn’t that a good enough use case?

Almost nobody bothers to put proper formatting, diagrams, tables, formulas,
references etc in their source code. At best we get ASCII approximations.

To see some examples of what it could be like look at Mathematica, Jupyter,
literate programming, and org-babel.

~~~
Retra
.. all of which require some kind of rendering software that has to actually
be installed on your machine.

~~~
henrikeh
So do you need for images, photos, spreadsheets, PDF files, websites,
schematics, board layouts, databases, mechanical drawings and models, neural
network models, music masters, audio tracks, video footage and any other file
format used by professionals.

Better yet, all the formats I mentioned are raw text and not even binary. And
all have well developed tools for editing.

------
jorams
> 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.

~~~
tonic-music
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.

~~~
colejohnson66
Source? I’d love to read more about this

~~~
AnaniasAnanas
Not car and cdr but close enough
[https://en.wikipedia.org/wiki/Church_encoding](https://en.wikipedia.org/wiki/Church_encoding)

~~~
Someone
Also, _cons_ , _car_ , and _cdr_ need not be primitives. They can be built out
of lambdas. In Scheme:

    
    
      (define (cons x y)
        (lambda (m) (m x y)))
    
      (define (car z)
        (z (lambda (p q) p)))
    
      (define (cdr z)
        (z (lambda (p q) q)))
    

(From [https://mitpress.mit.edu/sites/default/files/sicp/full-
text/...](https://mitpress.mit.edu/sites/default/files/sicp/full-
text/book/book-Z-H-14.html#%25_sec_2.1.3), exercise 2.4)

~~~
kazinator
Sure. Now to implement _consp_ , all you need is a global list which tracks
all lambdas that came from the _cons_ function; if the argument object is _eq_
to anything on that list, then it is a cons! We also now need another
primitive: weak pointers. We don't want our global list to prevent otherwise
unreferenced cells from being reclaimed.

 _typecase_ is going to be fun to develop and optimize, with everything being
a _lambda_.

------
JoshuaAshton
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.

------
tonic-music
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._

~~~
reificator
The buttons at the bottom are not a survey, the rest of the article is hidden
behind them.

~~~
tonic-music
That's a poor UI for an article. Just say what you want to say! If this
article were written in the hypothetical, it would make the point much better.

~~~
Technetium_Hat
That appears to be the gimmick of that entire website, based on the URL.

------
vharuck
The twist would've been better with more set up. I can't fault people for not
reading the whole thing and guessing a language at the end.

------
zekrioca
> But realistically, how often do you have to program high-performance
> computations? I suppose, unless you work in a narrow field of research and
> engineering that requires exactly that, not very often. And if you do, you
> have to use specialized hardware and compilers anyway. I’ll just presume, a
> typical 21st-century programmer don't have to solve differential equations
> very often.

Does the author know about all the efforts in this area, things such as
Machine Learning and statistics? This type of argumentation is so... 20th
century? :)

~~~
freeone3000
Ah, but we do use specialized hardware and compilers! (nevermind that they're
sold by nvidia, nobody else is buying quadros by the truckload) And moreover,
you don't do the differential equation in the code, you do the partial
specialization by hand and throw that into your pytorch kernel.

The fact that we are using python, instead of fortran or matlab, really does
show exactly how little hard math is being done by the computer, even in these
fields.

------
dumbfoundded
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 professional ones. The lack of syntax
makes python a great language for prototyping but a nightmare for scaling.

To choose which language you should use, I suggest figuring out the following:

\- What problem are you solving? Web app, scalable service, low level
processing?

\- How correct does it have to be? Are bugs and edge cases okay to be
tolerated? If not, I'd recommend a more functional language

\- How many people are working on it? If many people are working on it, I'd
recommend something with a strong type system.

\- How "fast" does it have to be?

These aren't all the considerations but I really dislike the idea of modern vs
antiquated. Languages will lots of usage are rarely outright bad (except
javascript, I love typescript btw)

~~~
daliusd
Link to increase your knowledge on non personal python projects
[https://wiki.python.org/moin/OrganizationsUsingPython](https://wiki.python.org/moin/OrganizationsUsingPython)

What about questions like:

* How happy / stress free you want to be in your work?

* How fast you want to deliver?

In result programming language's syntax is just one component and should be
considered in the context of various practices and tools in use. E.g. unit
tested Python code is better than not unit tested C#.

~~~
dumbfoundded
There are certainly many many professional python projects because the world
is a giant place but in general, I see it as a less professional language
(unless you're talking about data science).

As a full stack dev, I'd rarely if ever recommend python for any of the
problems I face professionally. For data science problems, Jupyter + Pandas +
Scipy makes a pretty awesome combination.

As for unit tests, I think that misses the point of my argument completely.
This is the situation I would evaluate python: you're starting from scratch,
what types of problems would you use python to solve? The answer is there
aren't that many. I think the most common reason people choose python is that
that's the language they feel comfortable with.

------
travisgriggs
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.”

~~~
andy_ppp
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.

------
dom96
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.

~~~
andy_ppp
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.

------
incadenza
This article is like a litmus year for who actually reads the full article.

~~~
andrewflnr
Eh, it's a litmus test for who sees through the framing device of the "survey"
at the end. I respect the impulse to skip the "bullshit reader engagement
stunt" or however they interpreted it... But I do agree that this thread is
hilarious.

------
jancsika
I upgraded Firefox on a Pine64 laptop that brought in all the schmancy
concurrent CSS handling that I'm assuming Rust made possible.

It was like upgrading the computer from a barely workable state to a pleasant
browsing experience for $0.

Could COBOL have been used instead to provide that same "set of rails" atop
which Mozilla drove that concurrency development?

To be clear-- I'm not asking if COBOL is turing complete. Mozilla _could have_
coded all that in C++ if they wanted to. I'm asking if COBOL would have so
clearly helped the devs reason about concurrency that it would have been worth
the effort of adding a new language instead of writing it in C++.

------
zzo38computer
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.

------
mattnewport
This seems to be missing an important piece: who is the target audience and
what problem domains is it targeted at. "For the 21st Century" doesn't answer
either of those questions.

------
tluyben2
Another language that is very English like syntax is Livecode. It is an
extremely battery included IDE; very much Hypercard. I like it because I can
download one binary and click together software that runs on most OSs. But the
language I cannot get used to ; far too much typing and I find it really
difficult to remember things. For me the j code he mentions is easier to
learn. Not to read maybe (although it is not that hard, but it is dense so it
is normal it would take a little more time to see what it exactly does even if
I program it every day), but to write I find the English and Verbosity
annoying.

offtopic:

What other environments could learn is the battery included part: I spent
another 3 hours today updating a .NET project. In return I get functionality I
do not use and will not use. So why do I update. Because the IDE is nagging
about it.

Does something exist that will ask me if or what to update based on what I
used and the available updates? Like;

New features:

[ ] QR code

Bug fixed:

[ ] ListView \- crashes when Clear is called and a row was selected

Performance:

[ ] Latency on tcp sockets improved — Linux only

etc.

Because I probably care about none of these or maybe only one.

And yet I have to spend hours on dependencies which I did not want in the
first place. Or maybe I wanted only the latency fix but not the rest.

Sorry, ranting.

~~~
zzo38computer
I think something like this was mentioned in 2600 once, where you can examine
the list of changes and the code before accepting the updates, as well as to
install only some changes instead of all of them. It seem good idea but may be
impractical.

I have disabled automatic updates on my computer and instead manually select
updates.

------
ktpsns
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.

------
Lichtso
> 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.

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

~~~
augustk
And Oberon (also by Niklaus Wirth) has a 20 page description.

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

He then proceeds to list 8 OOP mutable languages and one functional immutable
language (Haskell). FFS.

I hate to relay the news to the OOP zealots but (having spent decades in
OOP/procedural and about 3 years in Elixir) the future of reliable software is
in functional languages with immutable data and, ideally, process supervision
and massive concurrency (due to the breakdown of Moore's Law). The only
language that does all this handily is the BEAM VM (via Erlang and Elixir) and
possibly Haskell.

------
kwhitefoot
All I want is to be able to easily call routines written in other languages.

------
faragon
I would recommend a Brian Kernighan talk on that regard (2015):

[https://www.youtube.com/watch?v=Sg4U4r_AgJU](https://www.youtube.com/watch?v=Sg4U4r_AgJU)

------
crb002
At Global Day of Code Retreat today, the easiest Game of Life implementation
we did was in SQL.

As Elixir is to Erlang, we can create a better COBOL for the 95% of code that
is simple business logic.

------
melling
Really, this is worse?

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

than

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

Yeah, remove the ; and duplication of type:

let test_file = fopen(“/tmp/test.txt”, “w+”)

~~~
singularity2001
File test = open /tmp/test.txt for writing

------
oscardz88
We should not be constrained of only text notation, so a technology like the
projectional editor of Jetbrains mps should be there.
[https://www.youtube.com/watch?v=iN2PflvXUqQ](https://www.youtube.com/watch?v=iN2PflvXUqQ)

------
mwkaufma
Invent it or don't invent it. There is no "if" \-- that's just bikeshedding.
Programming languages are tools, not products. Durable languages evolve to
suit the needs of projects, not the aesthetics of the coders. We see recent
languages "do the same but better" (as OP opines) because the nature of the
projects haven't fundamentally changed.

------
iovrthoughtthis
I think programing in the future needs to:

\- treat a program as a database

\- allow programs to be visualised in many formats (visually as graphs,
textually as code etc)

\- allow programs to be manipulated through many interfaces (visually,
textually, programatically)

It’s not that text and syntax should die, it’s that different visualization
and manipulation paradigms are appropriate for different levels of
abstractions within programs.

2c

~~~
gary__
Reminisent of language workbenches like MPS in a way

[https://www.jetbrains.com/mps/](https://www.jetbrains.com/mps/)

------
rurban
> However, the distinct feature of the 21st-century language design is the
> absence of any distinct features in the languages themselves.

I would qualify Pony as only fast, concurrency-safe, new language noteworthy,
also it's capabilities system and complete lack of blocking IO, needed to
provide concurrency safety. Also its GC, which is completely new.

------
javajosh
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!

------
vorg
> Swift, Kotlin, and Go are probably among the most popular. [...] They don’t
> have anything new in them at all; they are all made by the “something done
> right” formula, this something being Objective-C, Java or C

Go isn't just C done right, but both C _and_ C++ done right. Similarly, Kotlin
is both Java and Apache Groovy done right.

~~~
jimktrains2
I wouldn't say go is c++ done right by any stretch. The lack of any memory
control and the lack of any sort of generic or templates leads to a
significantly less robust type system and code duplication.

------
seanmcdirmid
For a better take on this solution space, checkout Crista Lopes’s essay on
naturalistic programming:
[http://www.dourish.com/publications/2003/oopsla2003-naturali...](http://www.dourish.com/publications/2003/oopsla2003-naturalistic.pdf)

------
viach
"create file /tmp/test.txt for input and output as test_file"

Now wrap it in a buffered stream, filtered stream and try catch block and do
it using this "plain English" approach. I think it will end up with unbearable
paragraph of bad prose :)

------
talltimtom
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”.

------
qznc
What I learned from these comments: Never hide essential parts of an article
behind a button. People don't click it and miss your point.

------
Impossible
This submission is kind of genius because it shows how often people don't
finish reading articles. There are no spoiler tags on HN, but thr TLDR is the
author is describing the design goals of COBOL, and is making a point that
there is no programming language or environment that can solve all your
problems. I slightly disagree in a "use the right tool for the right job"
sense, but it clearly helps to understand your craft.

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

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

~~~
twtw
"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.

~~~
tluyben2
The only language that conformed is COBOL; if he put in Livecode for a twist,
then it would've been slightly harder. Still the business oriented would've
made me pick COBOL.

------
shion
You can't ignore this project. [https://cloudflare-
ipfs.com/ipfs/QmZm1zqUz44xF8fJAJJjUwmsuTb...](https://cloudflare-
ipfs.com/ipfs/QmZm1zqUz44xF8fJAJJjUwmsuTbWQCJLQLscpGivviqgHX/)

------
bytematic
Some way to have type inference without the cons of type inference or the
verbosity of static typing

------
nixpulvis
lol, the way this ends.

------
kensign
isn't this more about declarative vs. imperative?

------
_Nat_
The ideal structure of a programming language seems to depend on the user. I
mean, if someone thinks in machine code and can't understand anything else,
then machine code's optimal for them, regardless of how impractical it might
be for just about everyone else.

What we really need is intentional programming: we specify what we want, in
whatever manner is most natural to the user, and the computer figures out how
to make that happen. The computational expense of transforming intent into
machine code is unavoidable; it has to be paid through some combination of
human and machine effort, so there's no additional cost incurred by having a
machine do it.

The really cool part about all of this is that, once you have a system that
can transform intent into code, it's trivially meta-circular, causing it to
become self-optimizing. And once you integrate machine learning into its
optimization logic, it becomes intelligent, using machine learning to optimize
its own logic, including the machine learning, continuously reemitting further
optimized variants of itself to whatever computational resources it has
available; getting it to utilize various CPU's, GPU's, distributed
architectures, etc., becomes a matter of specifying their operation, such that
it's like writing drivers (except the system merely needs to know what the
computational resources _can_ do; the problem of how to make best use of those
abilities remains a problem for the intentional logic itself).

Anyway, that's the premise of my startup, Intentional Systems. I've been
working on this for a good while, and ended up applying to YCombinator's W2019
round. Regardless of how that goes, this is what's happening; intentional
operation's the future. And it's awesome!

With respect to this blog post, my point's that we don't really need a
"language" for the 21st century, but rather a system that allows users to
specify what they want in whatever terms make sense to them -- whether that's
machine code, C, Lisp, JavaScript, engineering flowsheets with equations,
English, or pig-Elvish -- so long as that language has a definition that
provides mappings to machine code, the problem of how to map that language to
machine code is a logical problem that a machine can address.

The example in the blog is a special case: 1\. > FILE * test_file =
fopen(“/tmp/test.txt”, “w+”); 2\. > create file /tmp/test.txt for input and
output as test_file Here, the two languages have the same logic, varying only
superficially. This allows an IDE to save that logic as an AST, then display
it to a user according to their personal display preferences. There's no
reason anyone opening that code in their IDE has to see it in Format 1 vs.
Format 2 any more than they have to see it in Font 12 vs. Font 14. I think the
folks behind Roslyn tried to capture the source code's features that were
extraneous to the AST as ["syntax
trivia"]([https://github.com/dotnet/roslyn/wiki/Roslyn-
Overview#syntax...](https://github.com/dotnet/roslyn/wiki/Roslyn-
Overview#syntax-trivia)).

It's a less trivial issue when the code isn't so transparently bijective. For
example, programmers collaborating on the same project would have more trouble
interacting if some prefer to program in [Rule
110]([https://en.wikipedia.org/wiki/Rule_110](https://en.wikipedia.org/wiki/Rule_110))
while others prefer idiomatic JavaScript. I mean, that's an addressable
scenario, but it's more complicated.

------
tobyhinloopen
two plus two equals four.

See that isn’t readable at all. I prefer syntax.

Edit: Ah u failed to actually press the button at the bottom!

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

Python, of course.

------
hzhou321
He is clueless about what makes a good programming language. The entire
article seems to be making up straw men and then knock them down.

------
sifoobar
I read that as: less syntax, less leaky abstractions and less macros; and I
mostly agree.

I would add better integration with the C tool chain, more separation of
concerns and less academic ego bullshit.

I've been working on something like that [0] lately.

[https://gitlab.com/sifoo/snigl](https://gitlab.com/sifoo/snigl)

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

~~~
hazz99
Ada has a lot of syntax, but also gains a lot in terms of functionality (and
arguably readability, but I disagree) for those extra characters.

Syntax for the sake of syntax is pointless, imo. Obviously there's a balance
here - APL and Applescript both suffer from either extreme.

~~~
fiddlerwoaroof
I have a suspicion that something like APL is only a problem as far as the
learning curve is concerned. For example, the syntax of advanced mathematics
is nearly illegible to me but, for a physicist or mathematician who does this
every day, it's the most efficient way of communicating information.

