Why your new programming language won't work
colinm.org
colinm.org
Some new things fail because of obvious flaws. Some fail because of non-obvious flaws. A very few things succeed despite both kinds. Nothing succeeds because it's perfect-- and that includes every programming language we use today.
If there's one thing HN drills into our heads, it's that failure is the only path to success. Yes, your new programming language is very unlikely to take off. It might be for reasons that occurred to this one dude, it might not. Either way, failing to make a new programming language is one of the best ways to come to understand the decisions that went into the development of the ones that succeeded.
There are useful criticisms to be made. "Here are some things you probably haven't thought of. Here are some projects you probably aren't aware of." Many people have managed to write such essays quite lucidly, without discouraging people from experimenting with failure on their own.
"You won't succeed because you suck, and I hate you," which (s/snark//g) is all I read here, is completely unhelpful. Cleverly though it may be written out, and apropos as it may be on a programming humor blog somewhere, it's antithetical to everything HN is about.
And anyway, none of this stuff applies to MY language.
I read it as a humorous warning to would-be language designers of the challenges and pitfalls of coming up with a new syntax, compiler, runtime, etc. A quick run-through of the items in the checklist should give you a hint these guys seem to know what they're talking about. Click the bio links above the article and those suspicions will be confirmed.
Sure there's a bit of snark here, but it serves a purpose, as does the humor. They obviously put some thought and time into this, they have some strong and worthwhile opinions about language design and the expertise to back it up.
Now, if it were Zed Shaw or Joe Damato up there, I'd totally agree with you. Kidding!!
Yes it's not pointless the first time you see it. Where it becomes pointless is on Slashdot any time there is ever an article about a new program language and 2 or 3 people fill it out for the comments.
My reaction is always: "okay...you took the time to tear it down but not the time to think through why things were done that way".
It's easy to see flaws, but much harder to suggest alternative (and improved) solutions.
Should HN only reserve a place for the other kind of pointless pandering, the one the article mocks?
People that mock those people should be taken as amateur comedians, and should be on reddit (not here).
No, people trying to improve things should be presented with (sane) "barriers to entry".
While there is no "right" way to improve things, there are tons of certified wrong, dead-end, been-here-done-that ways that should be avoided. Engineering is nothing if we don't learn from our collective mistakes, our history, and from proven theory. Else, you get the equivalent of those countless kooks who claim to have invented "cold fusion", "perpetual motion machines" but the "establishment doesn't believe them".
People trying to improve things is not by itself beneficial. Even if we restrict this to programming, we have fragmentation of effort, and you get like 200 frameworks for the same thing with marginal differentiation. If someone comes along with some radical idea, more power to them.
But we reserve the right to mock those coming up with YET ANOTHER tired cliche of a concept and/or implementation. They don't get free applause just for effort.
maybe that's just my perceptual bias, but perhaps also the greater context of hacker news that you point to in your comment. i tend to believe that things are posted here in support of experimentation.
No language dodges all of these checkboxes - or even 70% of them, really. I mean, just look at the "Unfortunately, your language (has/lacks)" list. A language which correctly had or lacked all of those as appropriate (jeezus - jut determining what the correct combination is would light half the blagoblag on fire...) would obviously be quite sucky.
The point, then, is that no language can make it through this checklist - and no language should have to. If your objection can be found on this checklist, and you don't have anything significant to add, then your feedback isn't really helping, is it?
Your feedback
[ ] Can be expressed as a linear sum of items on this checklist (see "trash can")
[ ] Cannot be expressed as such (see "internet")
And then someone wrote a proposal that checked many of the boxes on that list, but had the odd feature of actually working quite well.
I think that guy quit went on to start a news web site. I guess he was discouraged by the checklist.
The whole point of the checklist was that people kept re-inventing the square wheel (white-lists, trust circles, black-lists, $0.0001 emails, and so on).
In particular, this was win:
[ ] You have reinvented Lisp but worse
[ ] You have reinvented Javascript but worse
[ ] You have reinvented Java but worse
[ ] You have reinvented C++ but worse
[ ] You have reinvented PHP but worse
[ ] You have reinvented PHP better, but that's still no justification
[ ] You have reinvented Brainf*** but non-ironicallyYou may be trying to suggest that the grandparent post adds nothing to the discussion but that is not what you did. You criticised the grandparent for their association with an internet subculture's vernacular. Criticise the comment, not the parlance it is delivered in.
Maybe if we ridicule them enough they'll move on to more clever slang, or at least more obscure slang so that I no longer understand it enough for it to annoy me.
But I was pointing out something I found humorous in a joke checklist.
<--- ducks
This says it all right here.
"[ ] Programming in this language is an adequate punishment for inventing it."
* C - assembly and machine languages are not portable
* PHP - the barriers to entry for server-side web programming are too hugh
* Java - C++ becomes too error-prone with large teams
* Clojure[0] - there's too much complexity in programming that isn't inherent to the problems being solved
* Ruby, Python - Perl is really useful, but a little too messy
[0] Calling Clojure popular may be pushing it, but there seems to be some momentum building behind it.
That is more or less what every language is trying to achieve. It would be more accurate to say "Clojure: All other Lisp implementations are impractical".
[ ] the language name sounds too much like
clojure, closure, clozure, clojurescript or clojureclr [ ] the name is a common word, a single character, or
two characters, one of them not easily pronounceable,
and you are neither a demi-god nor a multi-billion-
dollar company.[ ] Manual memory management is not free.
[ ] It is a new programming language.
[ ] take thoughts on programming languages from
[ ] someone [ ] (s) incompetent at markup.
Its because people like me, the used C for 15 years, Perl for 10, and can't stand Python/Ruby/C#/OtherNewFangledLanguage types... simply do not care about your language.
Yup, its that simple. If you can't hook the guys who've been around the block a few times, what hope does your language have?
Can you not stand them because you tried them and decided that they don't fit you, or because you refuse to acknowledge progress?
I won't commit an appeal to novelty by claiming that new programming languages will always be better, but to stubbornly stick to C, Perl or other good ol' languages for no other reason but waving your cane at the new kids in town is equally as close-minded.
The world of programming is so interesting precisely because there are always new things to explore, recent inventions and innovations to marvel and old concepts to learn, rediscover and improve.
You're right in basically pointing out that if a new language can't communicate quantifiable productivity benefits, then what's the point of taking the time to learn it and switching over?
(Answer: 20 years old; it was first publicly talked about in 1991. Python is as old as Linux!)
You know JWZ's rant about how Java could have made integers first class objects by using the first bit as a flag for whether that machine word contained a primitive type or a pointer to an object, at the cost of only having a range of 2^31 instead of 2^32 (or whatever the word size was)? Python apparently had the same discussion in the early days, and made the same decision as Java (i.e. non-primitive integers, you have to box them to treat them as objects) and the reason was ... that the requisite bit twiddling was slow on DEC Alphas. (In fairness, at the time Guido was working for a government lab full of DEC Alphas.)