14 ms·

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

121 points by okaleniuk 8y ago

deleted 8y ago
[deleted]
sifoobar 8y ago
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 8y ago
  I don't agree with 'less syntax'. More syntax (when designed well) results is significantly more readable code.
  - hazz99 8y ago
    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 8y ago
      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.
  - sifoobar 8y ago
    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.
    - fooker 8y ago
      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.
      - sifoobar 8y ago
        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 that description.
        fooker 8y ago
        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.
        kazinator 8y ago
        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.
        8y ago
  - wool_gather 8y ago
    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 be a positive for the language's user. And the divergence will almost certainly make implementation changes more difficult. If we had instead: ifStmt := "if" "(" expression ")" statement ( "else" statement )? | "unless" "(" expression ")" statement This smaller amount of syntax is easily understood, increases expressibility, and `unless` will most likely be implemented as simple sugar, just a negation of the expression in an `if`. There's definitely some sweet spot in the middle, taking scan-ability and symmetry both into account.
    - fooker 8y ago
      Would you same the same thing about loops? 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.
- ASipos 8y ago
  "an embedded Forth with a Lisp in C" :) Sounds like the opposite of what the post is advocating.
  - sifoobar 8y ago
    Yet it's not; Forth and C are too primitive for most tasks, and Common Lisp too magical. Snigl aims to find a middle way. Programming languages will always be compromises, you always trade something in to get what you want. Anyone telling you otherwise is trying to sell you a new religion.
melling 8y ago
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+”)
- devxpy 8y ago
  or remove any declaration syntax altogether! f = open("/tmp/test.txt", "w+")
- singularity2001 8y ago
  File test = open /tmp/test.txt for writing
- crpatino 8y ago
  Personally, I'd go with: Var Test_file = CreateFile("/tmp/test.txt", erase-prev-version, open-as-read-write); ... but of course that smells like Redmond's bait.
nixpulvis 8y ago
lol, the way this ends.
mattnewport 8y ago
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.
deleted 8y ago
[deleted]
dom96 8y ago
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 8y ago
  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.
qalmakka 8y ago
People, don't comment before you read the whole article (and click on the survey on the bottom)...
- twtw 8y ago
  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 8y ago
    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.
- c3534l 8y ago
  Don't forget your sense of sarcasm either. The top comments in this thread apparently didn't get the point of the article or stopped reading early.
  - wild_preference 8y ago
    And it's pinned to the top because anyone who didn't read the article is basically expecting that sort of "hah, nice try dummy" criticism in the comments. It's like candy.
crazygringo 8y ago
> 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.
- justinator 8y ago
  I think the OP perhaps wants to look at Apple Script?
  - jandrese 8y ago
    The OP wants a modernized COBOL.
    - Vinnl 8y ago
      In fact, that's what they say after clicking the buttons at the bottom - which are actually part of the article.
      - reitanqild 8y ago
        Actually not if one reads carefully.
        Vinnl 8y ago
bauerd 8y ago
>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 8y ago
  >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.
vharuck 8y ago
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.
scarface74 8y ago
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.
Impossible 8y ago
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 8y ago
  I don't think you can blame the people for reading all the words and deciding not to vote on the survey.
  - detaro 8y ago
    If you read all the words, wasn't it fairly obvious already without clicking to vote from the last few lines?
    - twtw 8y ago
      "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 8y ago
        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.
- ACow_Adonis 8y ago
  To be fair, half of us thought that the article was finished. Don't blame us for not being told that you have to click on the survey at the bottom, and that when you do so, the next bit would magically appear...
rluble 8y ago
> create file /tmp/test.txt for input and output as test_file Maybe OP should learn COBOL :)
jchw 8y ago
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 8y ago
  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".
faragon 8y ago
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
bytematic 8y ago
Some way to have type inference without the cons of type inference or the verbosity of static typing
incadenza 8y ago
This article is like a litmus year for who actually reads the full article.
- andrewflnr 8y ago
  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.
defanor 8y ago
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.
zekrioca 8y ago
> 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 8y ago
  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.
reificator 8y ago
> 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/Materials/Editor https://docs.unrealengine.com/en-US/Engine/Rendering/Materia... [1]: http://inform7.com/ http://inform7.com/
- piinbinary 8y ago
  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
zzo38computer 8y ago
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.
jorams 8y ago
> 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 8y ago
  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 8y ago
    Source? I’d love to read more about this
    - AnaniasAnanas 8y ago
      Not car and cdr but close enough https://en.wikipedia.org/wiki/Church_encoding https://en.wikipedia.org/wiki/Church_encoding
      - Someone 8y ago
        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/book/book-Z-H-14.html#%25_sec_2.1.3 https://mitpress.mit.edu/sites/default/files/sicp/full-text/..., exercise 2.4)
        8y ago
Lichtso 8y ago
> 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.
tonic-music 8y ago
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 8y ago
  The buttons at the bottom are not a survey, the rest of the article is hidden behind them.
  - tonic-music 8y ago
    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 8y ago
      That appears to be the gimmick of that entire website, based on the URL.
deleted 8y ago
[deleted]
BerislavLopac 8y ago
> The most exciting thing, we already have the language exactly like this! What do you think it is? Python, of course.
tobyhinloopen 8y ago
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!
seanmcdirmid 8y ago
For a better take on this solution space, checkout Crista Lopes’s essay on naturalistic programming: http://www.dourish.com/publications/2003/oopsla2003-naturalistic.pdf http://www.dourish.com/publications/2003/oopsla2003-naturali...
travisgriggs 8y ago
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 8y ago
  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.
- pacala 8y ago
  Scala blocks-as-closures are fairly simple and universal.
JoshuaAshton 8y ago
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.
mixedCase 8y ago
>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".
magicmouse 8y ago
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 8y ago
  And Oberon (also by Niklaus Wirth) has a 20 page description.
deleted 8y ago
[deleted]
crb002 8y ago
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.
dumbfoundded 8y ago
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 8y ago
  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 8y ago
    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.
Iv 8y ago
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 8y ago
  > 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 8y ago
    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 8y ago
      > 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.
pmarreck 8y ago
> 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.
lispm 8y ago
> 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_ababa.htm http://www.lispworks.com/documentation/HyperSpec/Body/03_aba... ) and the standard includes a standard library - without actually dividing the language into a core and a library.
jancsika 8y ago
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++.
kensign 8y ago
isn't this more about declarative vs. imperative?
kwhitefoot 8y ago
All I want is to be able to easily call routines written in other languages.
tluyben2 8y ago
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 8y ago
  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.
_Nat_ 8y ago
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-trivia https://github.com/dotnet/roslyn/wiki/Roslyn-Overview#syntax...). 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.
viach 8y ago
"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 :)
qznc 8y ago
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.
javajosh 8y ago
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!
talltimtom 8y ago
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”.
shion 8y ago
You can't ignore this project. https://cloudflare-ipfs.com/ipfs/QmZm1zqUz44xF8fJAJJjUwmsuTbWQCJLQLscpGivviqgHX/ https://cloudflare-ipfs.com/ipfs/QmZm1zqUz44xF8fJAJJjUwmsuTb...
ktpsns 8y ago
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.
iovrthoughtthis 8y ago
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__ 8y ago
  Reminisent of language workbenches like MPS in a way https://www.jetbrains.com/mps/ https://www.jetbrains.com/mps/
rurban 8y ago
> 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.
vorg 8y ago
> 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 8y ago
  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.
hzhou321 8y ago
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.
mwkaufma 8y ago
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.
oscardz88 8y ago
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

121 points by okaleniuk 8y ago

deleted 8y ago

[deleted]

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 8y ago
I don't agree with 'less syntax'. More syntax (when designed well) results is significantly more readable code.
- hazz99 8y ago
  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 8y ago
    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.
- sifoobar 8y ago
  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.
  - fooker 8y ago
    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.
    - sifoobar 8y ago
      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 that description.
      - fooker 8y ago
        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.
        kazinator 8y ago
        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.
        8y ago
- wool_gather 8y ago
  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 be a positive for the language's user. And the divergence will almost certainly make implementation changes more difficult. If we had instead: ifStmt := "if" "(" expression ")" statement ( "else" statement )? | "unless" "(" expression ")" statement This smaller amount of syntax is easily understood, increases expressibility, and `unless` will most likely be implemented as simple sugar, just a negation of the expression in an `if`. There's definitely some sweet spot in the middle, taking scan-ability and symmetry both into account.
  - fooker 8y ago
    Would you same the same thing about loops? 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.
ASipos 8y ago
"an embedded Forth with a Lisp in C" :) Sounds like the opposite of what the post is advocating.
- sifoobar 8y ago
  Yet it's not; Forth and C are too primitive for most tasks, and Common Lisp too magical. Snigl aims to find a middle way. Programming languages will always be compromises, you always trade something in to get what you want. Anyone telling you otherwise is trying to sell you a new religion.

melling 8y ago

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+”)

devxpy 8y ago
or remove any declaration syntax altogether! f = open("/tmp/test.txt", "w+")
singularity2001 8y ago
File test = open /tmp/test.txt for writing
crpatino 8y ago
Personally, I'd go with: Var Test_file = CreateFile("/tmp/test.txt", erase-prev-version, open-as-read-write); ... but of course that smells like Redmond's bait.

nixpulvis 8y ago

lol, the way this ends.

mattnewport 8y ago

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.

deleted 8y ago

[deleted]

dom96 8y ago

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 8y ago
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.

qalmakka 8y ago

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

twtw 8y ago
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 8y ago
  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.
c3534l 8y ago
Don't forget your sense of sarcasm either. The top comments in this thread apparently didn't get the point of the article or stopped reading early.
- wild_preference 8y ago
  And it's pinned to the top because anyone who didn't read the article is basically expecting that sort of "hah, nice try dummy" criticism in the comments. It's like candy.

crazygringo 8y ago

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

justinator 8y ago
I think the OP perhaps wants to look at Apple Script?
- jandrese 8y ago
  The OP wants a modernized COBOL.
  - Vinnl 8y ago
    In fact, that's what they say after clicking the buttons at the bottom - which are actually part of the article.
    - reitanqild 8y ago
      Actually not if one reads carefully.
      - Vinnl 8y ago

bauerd 8y ago

>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 8y ago
>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.

vharuck 8y ago

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.

scarface74 8y ago

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.

Impossible 8y ago

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 8y ago
I don't think you can blame the people for reading all the words and deciding not to vote on the survey.
- detaro 8y ago
  If you read all the words, wasn't it fairly obvious already without clicking to vote from the last few lines?
  - twtw 8y ago
    "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 8y ago
      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.
ACow_Adonis 8y ago
To be fair, half of us thought that the article was finished. Don't blame us for not being told that you have to click on the survey at the bottom, and that when you do so, the next bit would magically appear...

rluble 8y ago

> create file /tmp/test.txt for input and output as test_file Maybe OP should learn COBOL :)

jchw 8y ago

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 8y ago
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".

faragon 8y ago

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

bytematic 8y ago

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

incadenza 8y ago

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

andrewflnr 8y ago
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.

defanor 8y ago

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.

zekrioca 8y ago

> 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 8y ago
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.

reificator 8y ago

> 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/Materials/Editor https://docs.unrealengine.com/en-US/Engine/Rendering/Materia... [1]: http://inform7.com/ http://inform7.com/

piinbinary 8y ago
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

zzo38computer 8y ago

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.

jorams 8y ago

> 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 8y ago
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 8y ago
  Source? I’d love to read more about this
  - AnaniasAnanas 8y ago
    Not car and cdr but close enough https://en.wikipedia.org/wiki/Church_encoding https://en.wikipedia.org/wiki/Church_encoding
    - Someone 8y ago
      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/book/book-Z-H-14.html#%25_sec_2.1.3 https://mitpress.mit.edu/sites/default/files/sicp/full-text/..., exercise 2.4)
      - 8y ago

Lichtso 8y ago

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

tonic-music 8y ago

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 8y ago
The buttons at the bottom are not a survey, the rest of the article is hidden behind them.
- tonic-music 8y ago
  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 8y ago
    That appears to be the gimmick of that entire website, based on the URL.

deleted 8y ago

[deleted]

BerislavLopac 8y ago

> The most exciting thing, we already have the language exactly like this! What do you think it is? Python, of course.

tobyhinloopen 8y ago

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!

seanmcdirmid 8y ago

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

travisgriggs 8y ago

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 8y ago
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.
pacala 8y ago
Scala blocks-as-closures are fairly simple and universal.

JoshuaAshton 8y ago

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.

mixedCase 8y ago

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

magicmouse 8y ago

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 8y ago
And Oberon (also by Niklaus Wirth) has a 20 page description.

deleted 8y ago

[deleted]

crb002 8y ago

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.

dumbfoundded 8y ago

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 8y ago
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 8y ago
  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.

Iv 8y ago

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 8y ago
> 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 8y ago
  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 8y ago
    > 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.

pmarreck 8y ago

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

lispm 8y ago

> 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_ababa.htm http://www.lispworks.com/documentation/HyperSpec/Body/03_aba... ) and the standard includes a standard library - without actually dividing the language into a core and a library.

jancsika 8y ago

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

kensign 8y ago

isn't this more about declarative vs. imperative?

kwhitefoot 8y ago

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

tluyben2 8y ago

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 8y ago
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.

_Nat_ 8y ago

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-trivia https://github.com/dotnet/roslyn/wiki/Roslyn-Overview#syntax...). 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.

viach 8y ago

"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 :)

qznc 8y ago

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.

javajosh 8y ago

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!

talltimtom 8y ago

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

shion 8y ago

You can't ignore this project. https://cloudflare-ipfs.com/ipfs/QmZm1zqUz44xF8fJAJJjUwmsuTbWQCJLQLscpGivviqgHX/ https://cloudflare-ipfs.com/ipfs/QmZm1zqUz44xF8fJAJJjUwmsuTb...

ktpsns 8y ago

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.

iovrthoughtthis 8y ago

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__ 8y ago
Reminisent of language workbenches like MPS in a way https://www.jetbrains.com/mps/ https://www.jetbrains.com/mps/

rurban 8y ago

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

vorg 8y ago

> 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 8y ago
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.

hzhou321 8y ago

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.

mwkaufma 8y ago

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.

oscardz88 8y ago

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