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.
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.
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.
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.
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.
> I'd bet that that C, C++, Java or even Python has a numbers advantage by one or two orders of magnitude.
That's a numeric argument, not a qualitative. Common Lisp is not popular in the mass market, but not because one can't easily write large applications. Something like Common Lisp actually was designed for the development of large and complex applications.
If you develop a large C application, you could shrink by porting it to Lisp. Lisp's code density in larger applications is much higher than C and large C applications tend to reimplement half of what Common Lisp brings out of the box (objects, code loading, runtime scripting, automatic memory management, error handling, ...) - see Java.
There are systems written in Common Lisp which are much larger than 1MLoc. Some applications like Macsyma easily reached already >100kloc in the 80s - vor example the commercial version with the GUI UI. Lisp Machine operating systems had around 1.5MLOC in the end 80s.
I use a web server, which has a few 10kloc code. My development environment I use is a few 100kloc Lisp code. There are a a dozen Lisp implementations/compilers maintained, which have all >10 kloc, some have several 100kloc (especially the larger commercial ones).
Historically there have been a bunch of databases, cad systems, etc. written in Lisp, which all had/have >100kloc, PTC sells a CAD system largely written in Lisp with >7MLOC Lisp code.
Ok, given all that, why do you think "Common Lisp is not popular in the mass market"?
Remember, I'm not arguing that Lisp is a bad language or that you can not write large applications with it. My point it just that a large Lisp codebase is significantly more difficult to understand and modify compared to ..say.. C++ or Java.
Your density argument is unhelpful here, because you typically don't want dense code full of user defined abstractions if you want to maintain it for a long time.
> Ok, given all that, why do you think "Common Lisp is not popular in the mass market"?
I think this question leads to nowhere, and even so if you make up a reason. You would have first to understand the target market of Lisp and the players interested in such a market. Lisp was originally designed for symbolic AI stuff (planners/schedulers, maths programs, theorem provers, natural language systems, knowledge representation and reasoning, knowledge-based engineering, ...) - that has been its core market and this is not a mass market. It's a market of applied research&development. Over time the language has been applied to related domains and a bunch of technology has been transferred: some of the underpinnings from Smalltalk and Java were largely influenced by Lisp - even the first garbage collector for Microsoft's .net was developed in Lisp and then transpiled to C++. One can also say that Javascript is a distant Lisp dialect (eval, symbols, data syntax, closures, object system, ...) - what it basically lacks is the whole s-expression infrastructure.
Is Porsche successful in the mass-market? Probably not - they are a small company compared to most others - they are not even in the top 20. But they are a very profitable car company. Should they give up because their market share is so small? They have world-wide sales of just 250000 cars/year. Toyota has ten million.
Is a Porsche 'difficult to maintain', because it is not a mass market car?
Just as in software, there are other more important factors. Porsche's target market are people who want to own and can afford a high-quality luxury sports car. But that's not the larger mass market.
> My point it just that a large Lisp codebase is significantly more difficult to understand and modify compared to ..say.. C++ or Java.
That's your claim. Have you ever worked with a Lisp program beyond 100kloc and extended it? It's not that difficult. It just looks different from what you have seen. In Java you work with the dead code in a text editor. In Lisp often you extend the running program - thus maintenance is done while you interact with it (similar how you write scripts for Excel, write code in Smalltalk, ...). For example for my Lisp IDE I never got a new version during the last two decades, beyond the usual new releases. All I got was patches which are loaded into the application - maintenance gets easy.
But where is the factual evidence - all I heard so far were guesses based on your popularity claims? I think you would need to look beyond that. There are technical reasons why Lisp is not popular like C: like Lisp is usually not a systems language, thus it can't compete with C in that area - which was designed for that -> this leads to the fact that most infrastructures are C-friendly and low-level. Apple writes their base OS in C and C dialects. On the iOS store the majority of applications are written in Objective-C - since that's what Apple supports (plus a bit of Javascript and Swift). Other large corporate players have invested zillions into their own infrastructure (SUN/Oracle -> Java). Now your language can be as great as possible, it will always be second tier or it needs to find a specific niche (Javascript -> webbrowser, PHP -> web sites, ...). The specific case for which Lisp was developed doesn't have a corporate sponsor (in the 80s it was DARPA for Lisp) and the niche markets for it are relatively small.
> Your density argument is unhelpful here, because you typically don't want dense code full of user defined abstractions if you want to maintain it for a long time.
That's another assumption. But domain-level maintenance is best done in a domain-level language. Much of the value of a software is at the domain-level.
The user defined abstractions are in any software. It's just how they look like to the user. Typically one prefers domain level user interfaces in maintenance, instead of having to deal with the machinery. Tha...
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:
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:
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.
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.
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.
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.
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.
Thanks for pointing this out. There really isn't any way to tell that the rando survey at the bottom is not actually a survey. I read what I thought was the whole article, but demurred from participating in the "survey."
The problem with English is that it's so ambiguous. The author wanted it to be obvious that you should click that button to see his conclusion but ambiguous English seems to have led many readers to misunderstand his intent. If only we had languages that could express things with less ambiguity, perhaps by incorporating symbols and stricter grammar.
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.
> 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.
As far as I can tell, the OP wants people to stop inventing languages and "just write good code". They're deliberately describing COBOL as exciting, new and modern to make their point.
AppleScript is (relatively) easy for non-programmers to read and understand, because it is built on natural language.
Unfortunately AppleScript is a huge pain to write, because as a programming language it is still quite strict about what type of syntax it will accept. It also is fairly limited, because speccing a natural language programming vocabulary/grammar gets increasingly difficult as you start adding features.
As a result even the best AppleScript programs are not concise at all, with limited use of abstraction. Most AppleScript programs are cobbled together by copy/pasting code found on the internet, and are full of bugs.
In my experience, the problem people have with learning programming is not syntax or abstraction - it's thinking like the abstract machine. Or in other words, understanding that having an array and a loop in your code isn't enough to make the computer understand and do what you want.
Basically, the thing that the PB&J exact instructions challenge teaches.
I agree somewhat, but I think it's important to consider that the ease of reading c-style syntax you experience is probably greatly helped by the wide adoption it's seen of at least some of its features and the repeated exposure you've had to this point, as most of us have.
There is a choice to be made as to whether amateur learning should be optimized (not that their example would be the result), or or a greater tie-in with the existing programming ecosystem should be. Both have their trade-offs, similar to the question of whether we optimize ease of learning or ease of use for experienced programmers (think BASIC vs APL).
`create file /tmp/test.txt for input and output as test_file`
To me, this does not explain what's happening here with any clarity. I'm left feeling overwhelmed with uncertainty and ambiguity.
Is there an iterable being acted on? Is this blocking? Is it creating a variable? Two variables? What type is /tmp/test.txt when it has no quotation marks, and how does it handle spaces or concatenation/methods?
Those questions are just the tip of the iceberg. It goes on and on.
Not only that, but you're actually saving time by utilizing symbols rather than words. There's so much decoding that goes into reading a whole entire word/sentence rather than just flowing and gliding along symbols and keywords. There's a reason why mathematics in general typically uses symbols rather than these huge verbose chunks that are open to interpretation.
>Is there an iterable being acted on? Is this blocking? Is it creating a variable? Two variables? What type is /tmp/test.txt when it has no quotation marks, and how does it handle spaces or concatenation/methods?
Well, if you knew the language, you'd have answer to all of those questions.
Plus, if you didn't know C, you'd be baffled by the other example as well...
For any reasonably complex example its not at all clear that this is so. Being more english like is actually a hardship not a benefit because naturally language is famously ambiguous and difficult to decode.
Either your language is incredibly complex or it understands a very stilted subset of actual normal language that only happens to look like natural language and you have to remember to use that stilted subset in which case what is the benefit of this vs foo = bar.
Regarding complex language we seem remarkably bad at simple things.
> Being more english like is actually a hardship not a benefit because naturally language is famously ambiguous and difficult to decode
The rules are not any worse to express the exact same operations and relationships. English would need to be augmented to necessarily express the same things. The syntax would change, but thats the point. It doesnt solve anything. Making programs more verbose and approachable is a common theme in scripting languages already. How far is too far?
While this is a valid criticism that I agree with, I feel as if it misses the forest for the trees. The problem is entirely that the time is spent arguing over minor differences in syntax and style, while spending comparatively little time on the bigger questions of testing, security, updates, and ease-of-use of the end product. No user of software particularly cares if it's written in C or COBOL, they care whether it reboots at midnight to apply security updates, losing their work, or spends an extra three minutes a day because it has to contact a webservice.
Very much agree. Programming notation, like math, is supposed to be easy to convey exact meaning, unlike human language.
Every attempt there has been to make code look like English hasn't worked out well. SQL, for example, is incredibly verbose, with complex syntax. This obscures what is otherwise very good semantics. I think this is why a lot of people hate writing queries.
And yet after 30+ years no one had adequately managed to replace it. God help us if it's one of those json based abominations. My main complaint with sql is that it can be somewhat difficult top make DRY.
Even if duplicate expressions are optimized by the engine, they hurt the readability and maintainability of the query, especially if they are big and complex.
> SQL, for example, is incredibly verbose, with complex syntax. This obscures what is otherwise very good semantics.
I disagree; I think SQL syntax is one of the things that make it very clear and easy to use; it's got a couple of warts, especially related to automated tooling (the biggest being fixed order of clauses with SELECT before FROM), but it's exceptionally well fit for it's purpose.
> I think this is why a lot of people hate writing queries.
I've known more people comfortable with SQL and thrown by typical programming languages than the reverse.
>I've known more people comfortable with SQL and thrown by typical programming languages than the reverse.
Non-programmers often find SQL queries easier, and simple SQL queries are intuitive. Programmers, who are likely to do more complicated ones, usually don't like it. At least in my experience.
The issue is that it is hard to quickly visually parse complicated queries, like big CTEs. Having it in a less English-like notation would go a long way to fix this.
I'm a programmer who has had to do plenty of complicated SQL queries; the difficulty I've had with those has been about 10% quirks in the design of SQL, and 90% bad database design that I'm not in a position to fix.
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.
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.
All those symbols are necessary for readable math though. For millenia people did math as you describe, and it worked very poorly compared to modern math notation.
For example, how would you write something like a tensor H_i^{kl} (pretend those are rendered sub and superscripts)?
Looking at that symbol, I immediately understand that H is a tensor with one lower index and two upper. Now, it precise words, it would probably be something like:
"Let H be a tensor with lower index i and upper indices kl."
Oh wait, we've already had to define all the variables anyway (since we don't want to specialize it to an individual tensor, because that would be useless). Why not just use a bit more notation and write it as H_i^{kl}?
If we ran out of letters, we'd have to use Greek ones. Now we are back to where we started.
I'm not a Ruby programmer but have over the course of my career had numerous occasions where I had to look at "incredibly readable" Ruby code.
No, no it isn't. Sure, you can infer some meaning in the various "DSLs" without knowing any Ruby but you're left facing exactly the problems of ambiguity the GP pointed out.
You know what the words mean because they're just English words but you don't know their exact definitions in that specific context. And even if two "DSLs" use some of the same vocabulary that doesn't mean the words will mean exactly the same thing.
It's just hiding the arbitrary implementation behind a very ambiguous API that might read as two completely different things to two different readers. Let alone trying to manipulate the program (at which point you realise that even though it's supposedly a "DSL for laypeople" you still need to understand Ruby idiosyncrasies to be able to work with it).
Ruby is not incredibly readable. Ruby is however capable of letting you create APIs that make code look a lot like plain English language. That doesn't mean the code "reads" like plain English language because unlike plain English language it's just a bunch of whimsical function and variable names with arbitrary implementations.
SQL is like the only language I like. It's so easy and unambiguous. What I read is what happens.
Whenever I work on a -nix box I grit my teeth with frustration at how OLD and UNFRIENDLY it feels. I'm shocked that people can still accept any of these archaic texts, whether is be for elitism/gatekeeping ("you aren't really into computers, otherwise you'd get it"), or for tradition ("it's the way it's always been, why bother changing what I know, despiteot being an inconvenience for everyone else who isn't in our group").
Why not just write your language to have three or four syntaxes (as a suggestion: compressed, C-style, shorthand, and verbose, with plugins for adding new syntaxes or spoken languages, dual screen for pair programming accessibility) and with the press of a button be able to swap between them? This way anyone can read your code in whichever way they please.
Maximize accessibility to all. It's not that hard.
> The second example is all words without punctuation, which requires me to read the entire thing word-for-word to figure out what it's doing.
Do you think that's also a problem with natural languages (e.g. English)? Should we switch to a more readable natural language with a syntax inspired by programming languages (or even visual programming languages)?
Natural languages don't usually convey precise set of instructions to be executed, or target a system that has no common sense, situation awareness, and other human traits.
The purposes of natural and computer languages are quite different, so it doesn't make much sense to model one after another. There were attempts to make more precise languages (Lojban, for example), but they never took off. Maybe because it's too tiring to precisely describe meaning, which can be inferred from a context with sufficient probability or clarified by asking questions.
First, you have to understand the implications of it being a pointer, which includes the little warning light in your head about ownership and allocation/deallocation. Then you have to remember that "w+" translates to "write in append mode". The fact that it's a string means you know it by memorization. But also there are warning lights in your head about text encoding... just standard things you're trained to be vigilant about. Where you can avoid triggering those reactions, I think it's worth trying.
These days we have the help of IDE's as memory aids, so for things like "w+" I prefer enums so that a tap of the auto-complete button shows you "write mode" and "append mode" options.
I suppose if I were to have any marginally controversial opinion on this topic, it's that I believe we should be embracing IDE's as "portable stack overflows" and designing languages with IDE assistance in mind.
>First, you have to understand the implications of it being a pointer, which includes the little warning light in your head about ownership and allocation/deallocation
Thats a semantic issue, not a syntax/style one. If your language has pointer semantics, you’d need to a way to access it with either proposed styles, and the same warning light should appear regardless.
The w+ example is much more relevant, as it could be expressed more clearly and well-defined (eg enum with full name). But all you could do with the pointer syntax is say FILE POINTER test_file, and gain nothing, because the “*” syntax isn’t at fault here
Completely agree. A balance is needed between the tenseness of Perl and the verbosity of AppleScript. Too compact, and the language becomes a pain to read — although I am sure the author feels clever at having accomplished so much in so little code. On the other side, too verbose and it is a pain to write and read. I absolutely hate reading through or writing pages upon pages of code to accomplish a trivial task.
Perhaps that is the reason languages like Python have been so successful. They seem to strike a good balance. I am not suggesting they are perfect by any means — they have their own fair share of compromises, but they do the job well enough. And I certainly don’t want to be writing COBOL in 21st century. :-)
Which of these forms you use does not matter all that much. They both have the same semantics where a file is opened, and it is up to the programmer to remember to close it. What actually is a an improvement is Common Lisp's with-open-file or similarly, python's with:
with open("somefile.dat", "wb") as f:
f.write(somevar)
which automatically closes the file when it leaves the scope.
I disagree. The only reason why the first example might be "easier to scan" is because the reader happens to already have experience with that language. COBOL got a bad rap for being "too verbose", but that kind of verbosity paired with a language that actually supports modern techniques for code organization and modularity would be a godsend in this new era of blurring lines between designing software and designing businesses. The need for programs that can be understood by anyone without a full-blown programming background hasn't gone away.
It's worth noting that what the author seeks is already possible with a language like Tcl, or even with a shell language like Bourne or one of its descendants. Sure, most programs don't do that (probably because there aren't very many getopts-like libraries do parse that sort of argument list), but it's possible nonetheless.
>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.
>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.
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.
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.
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.
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".
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.
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.
> 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? :)
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.
> 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.
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
> Do you know how many times I've taken someone's keyboard to type a tiny snippet and then explained it in English with the code as reference? Why do you think I don't just explain it in English first? Because English is verbose and ambiguous and not suited to describing logic. That's what programming languages are for.
Exactly this — and it is true about any human language. They were built for humans who are capable of interpreting things given the context. Try covering every single case in English and you have a lengthy legal document which no one wants to read — and it still has some ambiguity left.
If you want an example of what English would look like if used for programming, take a legal document and multiply it by 100.
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.
> 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.
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.
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.
But those full-blown Lisps have to have that full-blowness documented. It can't just be "here is the documentation for the ten primitives we used; to understand everything else, read the source".
It would be a bad doc if for every feature, it rambled on the details about how that feature is constructed out of the ten primitives, rather that specifying the relevant requirements for that feature.
Over less than a decade, I, one person, made a smallish Lisp dialect and documented it with a terse reference manual that doesn't repeat itself or pontificate all that much. It's formatted as one giant man page. If we render it to PDF, it's around 650 pages, with no table of contents or index. I am not a committee; I have no historic baggage from multiple base dialects. Shit that just popped into my head over a small span of time adds up to 650 pages already.
It's also surprisingly incorrect about C++ given that he goes on to say "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."
The 1338 pages of the C++11 standard is more than 2/3rds about the standard library. Only around the first 400 are about the core language.
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.
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.
183 comments
[ 2.9 ms ] story [ 210 ms ] threadI 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
Syntax for the sake of syntax is pointless, imo. Obviously there's a balance here - APL and Applescript both suffer from either extreme.
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.
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.
How so if all they speak is JS and Python.
You can have someone totally new to the project fixing bugs in a few days.
Also, how many of these codebases attract new contributors regularly? That's a pretty direct metric for readability of a codebase.
That's a numeric argument, not a qualitative. Common Lisp is not popular in the mass market, but not because one can't easily write large applications. Something like Common Lisp actually was designed for the development of large and complex applications.
If you develop a large C application, you could shrink by porting it to Lisp. Lisp's code density in larger applications is much higher than C and large C applications tend to reimplement half of what Common Lisp brings out of the box (objects, code loading, runtime scripting, automatic memory management, error handling, ...) - see Java.
There are systems written in Common Lisp which are much larger than 1MLoc. Some applications like Macsyma easily reached already >100kloc in the 80s - vor example the commercial version with the GUI UI. Lisp Machine operating systems had around 1.5MLOC in the end 80s.
I use a web server, which has a few 10kloc code. My development environment I use is a few 100kloc Lisp code. There are a a dozen Lisp implementations/compilers maintained, which have all >10 kloc, some have several 100kloc (especially the larger commercial ones).
Historically there have been a bunch of databases, cad systems, etc. written in Lisp, which all had/have >100kloc, PTC sells a CAD system largely written in Lisp with >7MLOC Lisp code.
Take for example the theorem prover ACL2:
https://github.com/acl2/acl2
Roughly 4MLOC Lisp code. Maintained over almost three decades. Used in a bunch companies for verification of chip designs.
Remember, I'm not arguing that Lisp is a bad language or that you can not write large applications with it. My point it just that a large Lisp codebase is significantly more difficult to understand and modify compared to ..say.. C++ or Java.
Your density argument is unhelpful here, because you typically don't want dense code full of user defined abstractions if you want to maintain it for a long time.
I think this question leads to nowhere, and even so if you make up a reason. You would have first to understand the target market of Lisp and the players interested in such a market. Lisp was originally designed for symbolic AI stuff (planners/schedulers, maths programs, theorem provers, natural language systems, knowledge representation and reasoning, knowledge-based engineering, ...) - that has been its core market and this is not a mass market. It's a market of applied research&development. Over time the language has been applied to related domains and a bunch of technology has been transferred: some of the underpinnings from Smalltalk and Java were largely influenced by Lisp - even the first garbage collector for Microsoft's .net was developed in Lisp and then transpiled to C++. One can also say that Javascript is a distant Lisp dialect (eval, symbols, data syntax, closures, object system, ...) - what it basically lacks is the whole s-expression infrastructure.
Is Porsche successful in the mass-market? Probably not - they are a small company compared to most others - they are not even in the top 20. But they are a very profitable car company. Should they give up because their market share is so small? They have world-wide sales of just 250000 cars/year. Toyota has ten million.
Is a Porsche 'difficult to maintain', because it is not a mass market car?
Just as in software, there are other more important factors. Porsche's target market are people who want to own and can afford a high-quality luxury sports car. But that's not the larger mass market.
> My point it just that a large Lisp codebase is significantly more difficult to understand and modify compared to ..say.. C++ or Java.
That's your claim. Have you ever worked with a Lisp program beyond 100kloc and extended it? It's not that difficult. It just looks different from what you have seen. In Java you work with the dead code in a text editor. In Lisp often you extend the running program - thus maintenance is done while you interact with it (similar how you write scripts for Excel, write code in Smalltalk, ...). For example for my Lisp IDE I never got a new version during the last two decades, beyond the usual new releases. All I got was patches which are loaded into the application - maintenance gets easy.
But where is the factual evidence - all I heard so far were guesses based on your popularity claims? I think you would need to look beyond that. There are technical reasons why Lisp is not popular like C: like Lisp is usually not a systems language, thus it can't compete with C in that area - which was designed for that -> this leads to the fact that most infrastructures are C-friendly and low-level. Apple writes their base OS in C and C dialects. On the iOS store the majority of applications are written in Objective-C - since that's what Apple supports (plus a bit of Javascript and Swift). Other large corporate players have invested zillions into their own infrastructure (SUN/Oracle -> Java). Now your language can be as great as possible, it will always be second tier or it needs to find a specific niche (Javascript -> webbrowser, PHP -> web sites, ...). The specific case for which Lisp was developed doesn't have a corporate sponsor (in the 80s it was DARPA for Lisp) and the niche markets for it are relatively small.
> Your density argument is unhelpful here, because you typically don't want dense code full of user defined abstractions if you want to maintain it for a long time.
That's another assumption. But domain-level maintenance is best done in a domain-level language. Much of the value of a software is at the domain-level.
The user defined abstractions are in any software. It's just how they look like to the user. Typically one prefers domain level user interfaces in maintenance, instead of having to deal with the machinery. Tha...
There's definitely some sweet spot in the middle, taking scan-ability and symmetry both into account.
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.
Sounds like the opposite of what the post is advocating.
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.
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+”)
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.
> 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.
But my point was primarily that people probably missed that they had to click the buttons to read that.
AppleScript is (relatively) easy for non-programmers to read and understand, because it is built on natural language.
Unfortunately AppleScript is a huge pain to write, because as a programming language it is still quite strict about what type of syntax it will accept. It also is fairly limited, because speccing a natural language programming vocabulary/grammar gets increasingly difficult as you start adding features.
As a result even the best AppleScript programs are not concise at all, with limited use of abstraction. Most AppleScript programs are cobbled together by copy/pasting code found on the internet, and are full of bugs.
Basically, the thing that the PB&J exact instructions challenge teaches.
no need to think about loops: array.each {|x| puts x}
need think about loops: for i in 0...array.length do puts array[i] end
There is a choice to be made as to whether amateur learning should be optimized (not that their example would be the result), or or a greater tie-in with the existing programming ecosystem should be. Both have their trade-offs, similar to the question of whether we optimize ease of learning or ease of use for experienced programmers (think BASIC vs APL).
And the caps hint is the same as syntax highlighting... its not even that useful if you have highlighting, but boy is it useful when you don’t
`create file /tmp/test.txt for input and output as test_file`
To me, this does not explain what's happening here with any clarity. I'm left feeling overwhelmed with uncertainty and ambiguity.
Is there an iterable being acted on? Is this blocking? Is it creating a variable? Two variables? What type is /tmp/test.txt when it has no quotation marks, and how does it handle spaces or concatenation/methods?
Those questions are just the tip of the iceberg. It goes on and on.
Not only that, but you're actually saving time by utilizing symbols rather than words. There's so much decoding that goes into reading a whole entire word/sentence rather than just flowing and gliding along symbols and keywords. There's a reason why mathematics in general typically uses symbols rather than these huge verbose chunks that are open to interpretation.
Well, if you knew the language, you'd have answer to all of those questions.
Plus, if you didn't know C, you'd be baffled by the other example as well...
Either your language is incredibly complex or it understands a very stilted subset of actual normal language that only happens to look like natural language and you have to remember to use that stilted subset in which case what is the benefit of this vs foo = bar.
Regarding complex language we seem remarkably bad at simple things.
The rules are not any worse to express the exact same operations and relationships. English would need to be augmented to necessarily express the same things. The syntax would change, but thats the point. It doesnt solve anything. Making programs more verbose and approachable is a common theme in scripting languages already. How far is too far?
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.
I disagree; I think SQL syntax is one of the things that make it very clear and easy to use; it's got a couple of warts, especially related to automated tooling (the biggest being fixed order of clauses with SELECT before FROM), but it's exceptionally well fit for it's purpose.
> I think this is why a lot of people hate writing queries.
I've known more people comfortable with SQL and thrown by typical programming languages than the reverse.
Non-programmers often find SQL queries easier, and simple SQL queries are intuitive. Programmers, who are likely to do more complicated ones, usually don't like it. At least in my experience.
The issue is that it is hard to quickly visually parse complicated queries, like big CTEs. Having it in a less English-like notation would go a long way to fix this.
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.
For example, how would you write something like a tensor H_i^{kl} (pretend those are rendered sub and superscripts)?
Looking at that symbol, I immediately understand that H is a tensor with one lower index and two upper. Now, it precise words, it would probably be something like:
"Let H be a tensor with lower index i and upper indices kl."
Oh wait, we've already had to define all the variables anyway (since we don't want to specialize it to an individual tensor, because that would be useless). Why not just use a bit more notation and write it as H_i^{kl}?
If we ran out of letters, we'd have to use Greek ones. Now we are back to where we started.
Not true. Ruby is incredibly readable
No, no it isn't. Sure, you can infer some meaning in the various "DSLs" without knowing any Ruby but you're left facing exactly the problems of ambiguity the GP pointed out.
You know what the words mean because they're just English words but you don't know their exact definitions in that specific context. And even if two "DSLs" use some of the same vocabulary that doesn't mean the words will mean exactly the same thing.
It's just hiding the arbitrary implementation behind a very ambiguous API that might read as two completely different things to two different readers. Let alone trying to manipulate the program (at which point you realise that even though it's supposedly a "DSL for laypeople" you still need to understand Ruby idiosyncrasies to be able to work with it).
Ruby is not incredibly readable. Ruby is however capable of letting you create APIs that make code look a lot like plain English language. That doesn't mean the code "reads" like plain English language because unlike plain English language it's just a bunch of whimsical function and variable names with arbitrary implementations.
Whenever I work on a -nix box I grit my teeth with frustration at how OLD and UNFRIENDLY it feels. I'm shocked that people can still accept any of these archaic texts, whether is be for elitism/gatekeeping ("you aren't really into computers, otherwise you'd get it"), or for tradition ("it's the way it's always been, why bother changing what I know, despiteot being an inconvenience for everyone else who isn't in our group").
Why not just write your language to have three or four syntaxes (as a suggestion: compressed, C-style, shorthand, and verbose, with plugins for adding new syntaxes or spoken languages, dual screen for pair programming accessibility) and with the press of a button be able to swap between them? This way anyone can read your code in whichever way they please.
Maximize accessibility to all. It's not that hard.
Do you think that's also a problem with natural languages (e.g. English)? Should we switch to a more readable natural language with a syntax inspired by programming languages (or even visual programming languages)?
The purposes of natural and computer languages are quite different, so it doesn't make much sense to model one after another. There were attempts to make more precise languages (Lojban, for example), but they never took off. Maybe because it's too tiring to precisely describe meaning, which can be inferred from a context with sufficient probability or clarified by asking questions.
I dislike the C style for several reasons:
> FILE * test_file = fopen(“/tmp/test.txt”, “w+”);
First, you have to understand the implications of it being a pointer, which includes the little warning light in your head about ownership and allocation/deallocation. Then you have to remember that "w+" translates to "write in append mode". The fact that it's a string means you know it by memorization. But also there are warning lights in your head about text encoding... just standard things you're trained to be vigilant about. Where you can avoid triggering those reactions, I think it's worth trying.
These days we have the help of IDE's as memory aids, so for things like "w+" I prefer enums so that a tap of the auto-complete button shows you "write mode" and "append mode" options.
I suppose if I were to have any marginally controversial opinion on this topic, it's that I believe we should be embracing IDE's as "portable stack overflows" and designing languages with IDE assistance in mind.
Thats a semantic issue, not a syntax/style one. If your language has pointer semantics, you’d need to a way to access it with either proposed styles, and the same warning light should appear regardless.
The w+ example is much more relevant, as it could be expressed more clearly and well-defined (eg enum with full name). But all you could do with the pointer syntax is say FILE POINTER test_file, and gain nothing, because the “*” syntax isn’t at fault here
Creating a file named "test" has the same syntax as creating a file with name from the variable "test".
Perhaps that is the reason languages like Python have been so successful. They seem to strike a good balance. I am not suggesting they are perfect by any means — they have their own fair share of compromises, but they do the job well enough. And I certainly don’t want to be writing COBOL in 21st century. :-)
It's worth noting that what the author seeks is already possible with a language like Tcl, or even with a shell language like Bourne or one of its descendants. Sure, most programs don't do that (probably because there aren't very many getopts-like libraries do parse that sort of argument list), but it's possible nonetheless.
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.
It falls into a sort of uncanny valley. Apple tried that sort of successfully with Hypertalk but really badly with AppleScript.
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.
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...
Maybe OP should learn COBOL :)
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.
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".
https://www.youtube.com/watch?v=Sg4U4r_AgJU
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.
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? :)
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.
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...
[1]: http://inform7.com/
- 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
- 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
Slightly discussed here : https://news.ycombinator.com/item?id=18105644
Exactly this — and it is true about any human language. They were built for humans who are capable of interpreting things given the context. Try covering every single case in English and you have a lengthy legal document which no one wants to read — and it still has some ambiguity left.
If you want an example of what English would look like if used for programming, take a legal document and multiply it by 100.
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.
typecase is going to be fun to develop and optimize, with everything being a lambda.
It would be a bad doc if for every feature, it rambled on the details about how that feature is constructed out of the ten primitives, rather that specifying the relevant requirements for that feature.
The 1338 pages of the C++11 standard is more than 2/3rds about the standard library. Only around the first 400 are about the core language.
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.
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.