Programming Language Checklist
famicol.in
famicol.in
It took me a long time (and a lot of banging my head into bad environments) to realize that language matters a lot less when the IDE is well-configured and fluent with what I want to do, the toolchain allows for experimentation without ruining the ability to do large, collaborative work, and both debugging and profiling are possible. And those are things you can't really add to a language environment when the language itself (spec and implementation) is constantly in flux.
Maybe a language will appear one day that renders all those tools obsolete, but we still evaluate and run code on real machines and it's still written by human beings so I sincerely doubt it.
Learn the main language once and you get incredible reach, for every new runtime the core language is practically the same
Common Lisp and Clojure are legendary for their stability. So many times I have experienced it myself - I would pick up a 5-6 year old Clojure project, update a bunch of dependencies, and somehow most things work right off the bat. That trick never worked for me with pretty much any other language - C#, Java, Python, Ruby, Go, Lua, Javascript - you name it.
Why is that? Probably because Lisp dialects essentially have no syntax. Code is data and data is code.
Lisp dialects have a lot of syntax. Every macro implements syntax.
It's not how often you write macros. Just write ten macros -> ten syntax extensions. The Common Lisp implementation I use has around 700 predefined external macros.
> against solving problems with macros (if they can be solved with regular functions).
It's just that macros are for different things and for those are widely used in Lisp.
I'd love to see language design and language development treated as different disciplines.
Just like developers were the first web designers, developers have been the first language designers.
Ideally a language designer would only be tasked with how to express complex ideas in a simple, composable syntax.
Language developers would be tasked with everything else: basically making those ideas work as efficiently and consistently as possible.
Not to say a language designer and developer can't be the same person, but I think there might be some benefit to having a linguist (with some understanding of development) and a developer (with some understanding of linguistics) team up on a new language.
For example, from a theoretical computer science perspective of programming languages handling backwards incompatible change is not a hot topic. Or also compiling ergonomics (as a slight counterexample to my own point, stack, the build system for Haskell has a shebang mode where you can take a Haskell source file and transform it into an executable by prefixing some magic comments)
The only way I could see what you're proposing making sense is if you got the linguist to design a much higher level language that operated on more concrete concepts. Some kind of domain specific language.
Your wish has been granted: Larry Wall, Perl 6.
> When developing a DSL, people from different areas come together:
> - the application developer who just wants to use the DSL,
> - the DSL designer who develops domain-specific abstractions, and
> - the machine expert who knows the target machine very well and how to massage the code in order to achieve good performance.
> AnyDSL allows a separation of these concerns using
> - higher-order functions,
> - partial evaluation and,
> - triggered code generation.
It feels like you're talking about Clojure.
--> [ ] Google has made its own language with a name near to yours and has stolen all the search results from you
It's a cute post but if there were a simple checklist for creating a successful language, every language designer would just do that.
This is particularly obvious in the "Your language has/lacks" section, where whichever choice you make can be argued against for almost every point.
The point is that you there is no such thing as a perfect language and the success of a language rarely depends on the kind of criteria that programmers will judge them on at first glance, and success is a relative thing.
I suppose, scathing criticism in that respect is the highest form of praise.
“I don’t like to talk badly about C++ applications.”
If not strictly true nowadays it was still funny.
Sadly, it seems in a few decades, pretty much that would be the fate of every single PL in TIOBE's Top. All popular PLs of today are morally outdated. Programming languages of future would be striving for:
a) Developer's productivity
b) Execution performance
c) Correctness of the program
And none of the popular languages today are making good progress in any of those directions.
> [ ] You have reinvented PHP but worse
I'm trying to think of languages that would fit that bill. That almost sounds like a challenge.
IMO this is the inherent difficulty with Javascript. I would prefer that you have the "source code" as two separate things: the hard details of the page and the code to manipulate behaviour.
This [1] current HN front page link would illustrate what I mean. You have a colour palette (hard details) and the behaviour (code to plot the colour palette). Of course this is a simplification, but it shows the way of thinking and the way of optimising use of code and space.
It just happens to be a popular architectural pattern at the moment to reimplement the DOM, HTML and CSS all in javascript and have one big mess of code.
ASP.NET MVC uses C#, (C)HTML and CSS for a total of three languages. WPF uses XAML and C# for a total of two. Android uses XML and Java for a total of two. I think Delphi only uses one, I vaguely remember the designer outputting plain Delphi instructions? I might be misremembering.
React is not exactly encouraging separation of concerns, and in some ways this was better in the times of JQuery. But I don't think this is directly related to the number of languages involved.
Separation of concerns doesn't imply separate languages. There might be some merit to the idea of a DSL for each concern? But if the end result of that experiment includes CSS, I would call the experiment a failure.
What are examples of MVC using only one language?
Smalltalk, but Smalltalk MVC is different from what MVC typically means nowadays.
FWIW, WPF uses MVVM, not MVC. The differences are as subtle and pedantic as they are important.
I've been doing web-related development since the late 90's, and I make a living as a UI Architect. Increasingly my clients are looking for my help to unfk their nightmarish, effectively unmaintainable legacy codebases -- which typically have followed this same cargo-cult "wisdom" to their detriment.
It can have both tremendous advantages and be a mess. Both can be, and are, true.
Not that I'm averse to "reinventing" HTML or CSS in the first place, although doing that in JS would be somewhat ironic.
Hint: they're JS APIs.
Of course, one could argue none of these are 'serious' programming languages.
---
[0]: https://en.wikipedia.org/wiki/Whitespace_(programming_langua...
:)
PHP is like Javascript but worse.
Since React, Javascript is like PHP but worse.(But also, just don’t use document.write)
The fact that the meaning of the API is commonly misunderstood is not (necessarily) a fault of the API
Edit to add:
I think calling write on a loaded document should have been an exceptional case and you should have had to explicitly call something to unload, replace or clear it.
Also the "sweet spot" for Lua has some overlap with JavaScript but I don't think the "but worse" complaint is quite fair and I think Lua may actually pre-date JS.
But surely there are a bunch of HTML templating languages that would fit the category of "PHP but worse".
And it does
There were some differences from Netscape's implementation, but they're pretty minor compared to the dialectical differences between competing implementations of pretty much any other language.
When Netscape decided to standardize the language, they went to ECMA. Microsoft didn't have ECMA completely under their thumb, but did have some control.
Netscape wanted to fix some fundamental issues with JS, but MS had just spent a ton of money making their clone, so they insisted all those problematic bits stay right where they were.
So, JScript is to blame for most of the bad parts of Javascript and is therefore worthy of all the hate you could possible heap upon it.
Any language that compiles to JavaScript.
https://flak.tedunangst.com/post/technical-debt-and-tacking-...
> lessons learned:
> Those who don’t learn from history are doomed to repeat it. Any day now, I suspect some fools are going to want to write web apps, but they won’t want to use raw javascript and they’ll create some ridiculous custom language to javascript compiler. I can only hope they have the good sense not to tell anybody about it.
What if I compile javascript... to javascript. So that I can have actually functioning javascript across the majority of fairly modern browsers, while using modern features.
All I'm saying is, honestly. I don't blame people for not writing straight javascript, when even if you do, you still need a build system in between if you want to support all browsers.
Frank Atanassow, "Some words of advice on language design"
Ha!
- everything is an expression
- destructuring
- support for higher order functions
Those seem to be universally loved features that new programming languages are required to have in order to still be appealing.
I would also mention that support for higher order functions, in the sense of functions which take other functions as arguments, is eevn possible in C. I think a much more important feature that is only recently becoming mainstream is support for lambdas. Support for HoF without lambdas is relatively worthless in my opinion.
Edit: well, there's also this: https://news.ycombinator.com/item?id=7836410
Can anybody track down the year this was written?
https://web.archive.org/web/20111103024132/http://colinm.org...
Why so mysterious? ;)
Do you have a pointer to anything that predates the link I provide? From what I gather, that's the website of one of the listed authors. If you have an earlier link to something that looks like an earlier draft, that would be nice to have for us armchair internet historians.
Ironically, most of the languages I've used in the last 5 years (Swift, Rust, Kotlin) post-date that period, so I was wrong in my conclusion.
https://news.ycombinator.com/item?id=3099979
I'm glad it's stood the test of ~8 years time so far.
The editor plugin (in contrast to existing language plugins) also translates the error msgs back to the human-readable code.
Just an idea, but I could not get it to fit in the questionaire :)
>Unison is a language in which programs are not text. That is, the source of truth for a program is not its textual representation as source code, but its structured representation as an abstract syntax tree.
It has some further goals for doing this which are really exciting to me, such as content-addressable code, but the starting point is similar to the one you stated. :)
You can write it in Java, Scala, Kotlin, Clojure, Ceylon, Groovy and many more.
This is exactly the problem. People spend so much effort looking for better syntax that they miss the most important part of programming. It's about design and structure, the syntax doesn't really matter at all. I don't even care if it's dynamically typed or statically typed or functional or not. A bad developer will produce bad code no matter the language is. I've seen this over and over.
It's not so different from human languages. It doesn't matter what the language is; if you know it well enough, you can write a great novel with it... But only if you're a good author to begin with.
A bad author is not going to start learning French because they couldn't write a successful novel in their native English... Instead, they will work on their storytelling because they know that they are at fault, not the language.
I've written code in many languages and I can produce good software with any of them. The language I'm most familiar with is the one which allows me to work faster, but it has basically no effect on quality of the code.
For example, in the past, I've written Golang code after learning it a couple of days before for a job interview and the interviewer (a well known developer and founder of a popular startup at the time) commented that it was one of the best designed/structured samples he has seen. It took me a long time to write it because I had to look up stuff all the time but it seems to have had little effect on the quality of the code.
People have to stop blaming tools and start blaming themselves. It takes over a decade of intense work (nights and weekends too) of constant self-blaming and adjustments to become good at coding. That's if you have natural talent for it. If you're not a natural then you have to be even more patient.
If you write code yourself and view that as the main advantage, type systems matter less.
But when working in a team having statical typing as a written contract between people can help development substantially.
Two problems that tend to occur in practice:
* Untyped languages (e.g. Python, Ruby, JavaScript) typically lack a formal dialect for expressing parameter and result types, and most don’t even provide formal mechanism for annotating interfaces. Without a common language for expressing interface types, it’s nigh impossible to develop the tooling and education that are the necessary prerequisites to popular adoption.
* Typed languages (e.g. C†, Java, Swift) frequently have poor/limited expressivity, creating friction for users, who end up fighting against the type system instead of working with it to describe their precise needs, while failing to provide the promised safety. e.g. Inability to describe numeric bounds means many functions with integer/double parameters will be partial, and passing inappropriate values will trigger runtime errors/aborts/undefined behaviors (e.g. divide-by-zero, bad array index). And that’s just the easy stuff.
Python3 is one exception to the former, in that function interfaces can be formally annotated, though the language itself doesn’t provide the mechanism to enforce those annotations. And Eiffel is something of an exception to the latter in that interfaces are annotated with a mix of compile- and run-time checks. And then, of course, there’s ongoing work on dependent type systems and no doubt other CS research that may someday filter down into the production languages in mainstream use. But it’s tough and slow, and a giant wildly-inconsistent ballache in the meantime, with more really badly reinvented wheels than it’s possible to count.
-- † Inasmuch as C can be said to have a “type system” at all (Really, it’s just got a handful of annotations for allocating memory on stack.)
While it’s true that you could write any program in almost any syntax, that does not mean that syntax isn’t important. Syntax is the UI if a programming languages and as with any UI, UX matters. (You can accomplish tasks with bad UI’s too but that doesn’t mean it’s pleasant or efficient) Syntax shapes how you think in a language and how you view or use the semantics. We have many languages which are semantically essentially the same and only differ in syntax and people prefer one over the other often for different purposes. Ergonomics are important.
Hell, many people won’t even give languages whose syntax they don’t like a chance... (don’t like lisp parentheses? Python significant whitespace? Forth’s stack shenanigans? J/k/apl/Perl’s keyboard-mash-symbols? Etc)
Somehow it does though: I find even j/k/apl easier to parse in my head than Ruby; somehow the ruby syntax gives me a headache. Not sure why that is, as I wrote a lot of code in it, but I find Python, C#, F#, Haskell or Kotlin far nicer to read and write. And, even though I understand the semantics and can write code in Ruby, if I have a choice, I would never touch it again. And that's only syntax/idioms. I find JS also quite rancid syntactically, but not as repulsive as Ruby.
And I know other people have this with different (or the same) languages as well; like someone else said, most people (even on HN) won't even try languages with a 'weird' syntax, even if they are proven to be more productive in some cases relevant to them. I know quite a lot of Lisp-y coders (most of them do Clojure these days) and they don't understand how/why you would ever use anything else. Most people here (maybe including you) have the inverse of that. As there are blazingly fast Lisp/Schemes on every platform, why are you using Go or another syntax than the basic AST? And yet you are and most of us are. If syntax does not matter, why have any syntax at all?
Assembly is the only language that works on every machine, no matter how small or big. But that doesn't mean that we all have to write assembly. Or Javascript (if we're targeting Web). Purescript, Elm, ReasonML, Clojurescript - they all exist for good reasons, not some made-up bullshit points.
1. Other things matter more. How a language scales to 100 programmers working on 10 million lines over 20 years, say, matters more (in some environments) than the syntax does. Syntax contributes to that. But syntax contributes to that precisely by being pretty vanilla, uninteresting syntax. More, sexier syntax makes a language worse for that environment. (I'm talking about go here. But I could make a similar argument for other languages in other environments.) Syntax matters as a means to an end; the end matters. Syntax where the end is syntax doesn't matter so much.
2. I suspect (and assert without proof) that peoples' brains work in different ways, and that a person finds languages easier or harder as those languages conform or conflict with the way the person thinks. Ruby syntax gives you a headache? And the problem isn't that you just need to learn Ruby better. But for every you, there's (at least one) someone who has the same issue with J/K/APL. And that's fine. People whose way of thinking matches APL should program in APL, and those whose way of thinking matches Ruby should program in Ruby. We don't need one language to rule them all. They each have their target niche and their target audience.
Because Lisps emphasize data more than the syntax. The following quote is from Rich Hickey's famous: "Simple Made easy" talk:
Syntax, interestingly, complects meaning and order often in a very unidirectional way. Professor Sussman made the great point about data versus syntax, and it's super true. I don't care how many you really love the syntax of your favorite language. It's inferior to data in every way.
Do not learn Rust if you think you might need to code C++ or C ever again.
Rust probably should have used "." in place of ";". Or anything, really.
Syntax matters because it's part of the interface, and so it has the ability to clarify or confound. Destructuring assignment; async/await instead of CPS (technically not exactly equivalent due to variable scope, but close enough in actual usage); pipe operators/macros instead of (third-function (second-function (first-function the-data))). None of these make the language more powerful but they do aid clarity and concision, as well as just making the language nicer to use.
I would say a good developer can make the code clear, I can make my ES5 code clearer then some bad ES7 code, most of the time clear code depends on how you name and split your code in logical and intuitive steps.
I had been working on that project for 3 years but migrating it to async/await only took me about 2 months of casual after hours work. The reason it was so easy to migrate and that I didn't have to write the project again from scratch is precisely because the architecture was correct to begin with.
When you think about code quality in terms of how much (or rather, how little) time it takes to maintain it to adapt to industry trends, architecture is by far the most important factor. Because even if everything changes from underneath you, a good architecture will survive the test of time. Any other metric to measure code quality is arbitrary and meaningless IMO.
It's mind boggling that my previous comment received downvotes. I guess it reinforces the point that the author of the article is making. The average developer is incapable of understanding what is important. If people can't articulate what their goal is and they don't know what is important in order to achieve this goal, then there is zero chance that they will be able to make the right tradeoffs. Because there is no free lunch, every decision is a tradeoff. If, like for the vast majority of projects, there is a good chance that the requirements will change significantly in a year or two, then you need to know what really counts and architecture is one of those things that can stick if done correctly.
Sometimes there is a real advantage to writing real world applications in some particular language. Maybe you are writing something that needs to be performant, safe, and low level, so Rust is an attractive option. Maybe you are writing web front-ends and you see the benefit of a type system like what's available in Typescript. There are lots of reasons not to just write everything in C or Java. Don't be sour because we aren't all using the same language for 50 years; we've made advancements in computer science and that's reflected in our tools.
This is satire of HN, not an actual checklist
It's a framework to evaluate other people languages (or your own)
Don't make fun of people for making languages.
Also Obligatory:
http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...
Some day, that may become true. But the safe-money bet is on "no" for the vast majority of languages one will encounter in academia and industry. Most will fail to catch on, a few might be remembered, and the ones that succeed will do so because of forces unrelated to the zen of their design as much as the new ideas (or old ideas done right) they bring to the table.
(They share that in common with startup companies ;) ).
dear python3, unfortunately you lack: print statement, fast/any type checking, concurrency, speed
dear java/golang/javascript et al., unfortunately you lack: named parameters, default parameters, predictable performance
dear nearly everyone except ada/oberon/et al., unfortunately you lack: sensible numeric types/subtypes and ranges
This is funny for general purpose languages, but doesn't seem relevant for specialised languages. I wish the checklist clearly stated that it targets general purpose languages.
Why don’t you like it? I’ve not read any anti-Blazor opinions.
The component libraries themselves are relatively poor quality and have some weird JS integrations. There's no good open-source component libraries. Even a good library that utilizes bootstrap or material-design scripts would be nice.
Once these issues are generally resolved, I'd be more inclined to suggest it, but I do not want to be the first mover on this one. I've seen way too many X to browser libraries come and go without gaining any real traction only to die on the vine so to speak, then you're stuck rewriting or patching an application that looks and feels ancient.
Even then, one of the larger arguments in favor of Blazor is really, "I can reuse my C# skills." Even there, you need a lot of Browser application context knowledge in practice, and you've just created disconnects and more work where you do need it. That doesn't even get into the mirrored trees directory structure of .Net MVC that is repeated with Blazor.
If I were to explore something similar, I'd probably favor Yew (rust) which seems to be around 220k for the todo mvc app.
In summary:
* Bulky payload or laggy response
* Lighter alternatives
* No network effect
* Dirty abstractions
* Messy structure by default
* Verbose
* React (favoring hooks)
* Redux / GraphQL
* Material-UI (jss/css-in-js themes)
* Fetch API
* connected-react-router
B: (tick the checklist and sent it back)
It's a joke. You don't "use" it except to diss a language you don't like.
The guy never heard of Lisp so I wouldn't pay much attention to this anyway.
If you think about it, lisp is really just the smallest amount of higher-level PL primordial soup you can give to a programmer.
Of course, these days procedural is taken for granted and drops off the radar as a notable paradigm.
The dual of imperative is declarative. It is quite possible to have a functional imperative language as Guy Steel points out in his Lambda: the ultimate imperative paper.
I am not sure how you can count imperative and OOP as two paradigms. OOP is an extension of imperative paradigm. I would like to see what language you consider to be OOP but not imperative and not functional.
(That said, if you read real Erlang code, despite being immutable and nominally functional, the code often is in practice simply imperative code where the code author has manually done the SSA rewrite. This is one of my major criticisms with the language. If you really try to program it functionally, it's quite a pain compared to Haskell.)
Considering most language paradigms are mutually contradictory, this only serves to increase the LOLs.