Programming Language Checklist(colinm.org)
colinm.org
Programming Language Checklist
http://colinm.org/language_checklist.html
24 comments
For me, in an incognito window (so Google is less likely to tweak search results for my preferences), the Wikipedia page for the game Go is the first result, and five out of the top 10 are also about the game. The other results are Disney's "go.com" domain, golang.org, and the movie Go on IMDB.
Doesn't really suggest unfair weighting to me.
Doesn't really suggest unfair weighting to me.
This is what I see in an incognito window: http://i.imgur.com/BI4zvXB.png
Given that incognito doesn't obscure your IP address (not to mention the myriad other ways your identity could be leaked to Google), I wonder if incognito's enough to get a "clean" page of Google results. On this search, I get different results from you but ones similar to djur: http://imgur.com/7KTqZFV (on Firefox in private mode: http://imgur.com/Jn400wX). For reference, I probably would only visit a page on Go if it were linked to on a blog; I don't use it or (normally) search for it.
If I search for 'go' then I'll get http://golang.org as the second result after the Wikipedia article for the game, however I find that if I'm searching for almost anything to do with Go I'll have to type 'golang' instead, because otherwise Google seems to interpret it as a verb.
The "Dallas Area Rapid Transport" is the only counter-example I could find.
It's surprising to me that people view this as primarily negative. I think it's (a) funny, and (b) actually serves - as does the best humor - to make people think about things more deeply: by enumerating all the knee-jerk reactions in one place, discussion can focus on more interesting aspects.
People want to be offended, it makes them feel superior.
It is clearly a joke, anyone taking it seriously shouldn't really have any attention paid to them.
It is clearly a joke, anyone taking it seriously shouldn't really have any attention paid to them.
This is such a bummer of a file that incorrectly assumes that the only valid goal of a new language is to achieve widespread adoption.
I know its en vogue to turn up our noses at "X at Y lines of Javascript", but programming is actually a pretty fun and neat thing to do, and its okay to create something even if its not particularly groundbreaking or commercially viable.
This is a bad language, and you should feel bad for inventing it.
I can't help but imagine the person who penned this sentence also routinely tells children that their macaroni artwork could use more symmetry.
I know its en vogue to turn up our noses at "X at Y lines of Javascript", but programming is actually a pretty fun and neat thing to do, and its okay to create something even if its not particularly groundbreaking or commercially viable.
This is a bad language, and you should feel bad for inventing it.
I can't help but imagine the person who penned this sentence also routinely tells children that their macaroni artwork could use more symmetry.
I think you might be missing the tone here. The checklist is intentionally overcritical and self-contradictory. The idea here--in my reading at least--is to poke fun at people who bash new programming languages by reducing their criticisms to a thoughtless checklist.
I think you're taking it too seriously..."X is bad and you should feel bad" is a popular meme that originated in Futurama:
http://knowyourmeme.com/memes/your-musics-bad-and-you-should...
http://knowyourmeme.com/memes/your-musics-bad-and-you-should...
I'm aware that it's a meme, but that doesn't change the connotation of the phrase.
It's like you willingly got trolled...the post is a joke, and you knew it, but you still got bummed and made ominous assumptions about the person who penned a silly meme regurgitation. I don't understand.
c'est l'Internet.
I don't understand.
I think I finally do. For a long time I would see posts like GP's on 4chan and wonder if someone is really making them with a straight face unironically, or if it's part of some master troll orchestrated by a grand ruseman. For a while the grand ruseman theory seemed more believable, but seeing a normal person make such a comment on HN makes me think that perhaps most such posts are really made by normal people which, perhaps paradoxically, actually restores a bit of my faith in humanity. I mean, compared to the idea of people with nothing better to do than orchestrate stupid posts on 4chan of all places.
I think I finally do. For a long time I would see posts like GP's on 4chan and wonder if someone is really making them with a straight face unironically, or if it's part of some master troll orchestrated by a grand ruseman. For a while the grand ruseman theory seemed more believable, but seeing a normal person make such a comment on HN makes me think that perhaps most such posts are really made by normal people which, perhaps paradoxically, actually restores a bit of my faith in humanity. I mean, compared to the idea of people with nothing better to do than orchestrate stupid posts on 4chan of all places.
Sure it does. It suggests the person who penned it had a sense of humor rather than suggesting they are as much of a macaroni art critic as you imagine.
I cannot agree more, especially reading the history of T by P. Graham, a language I have never heard of before or written a line in, but whose history I find extremely interesting from a developers perspective.
The whole "X at Y lines" argument is the same as saying "I created an OS in language X in two lines of code" by writing:
The whole "X at Y lines" argument is the same as saying "I created an OS in language X in two lines of code" by writing:
Import OS.*;
OS.Run();Paul Graham is not the author of the piece you mention, it's Olin Shivers.
I was mistaken at first but then I read a fragment which said "and then I went to write scsh" which made it obvious who was the author. I wonder how people can still be mistaken after seeing this (do they assume PG wrote scsh?).
I was mistaken at first but then I read a fragment which said "and then I went to write scsh" which made it obvious who was the author. I wonder how people can still be mistaken after seeing this (do they assume PG wrote scsh?).
This is like lowbrow-dismissal bingo. Someone (cough) should turn this into actual bingo cards.
> You have reinvented PHP better, but that's still no justification
Preach.
Preach.
With a little cleanup, this could have been the original government procurement checklist for Ada.
As the developer of Myrddin (http://eigenstate.org/myrddin.html), I felt the need to fill it in for my pet language:
You appear to be advocating a new:
[ ] functional [ ] imperative [ ] object-oriented [x] procedural
[ ] stack-based [x] "multi-paradigm" [ ] lazy [x] eager
[x] statically-typed [ ] dynamically-typed [ ] pure [x] impure
[ ] non-hygienic [ ] visual [ ] beginner-friendly
[ ] non-programmer-friendly [ ] completely incomprehensible
programming language. Your language will not work. Here is why it
will not work.
You appear to believe that:
[ ] Syntax is what makes programming difficult
[ ] Garbage collection is free
[ ] Computers have infinite memory
[x] Nobody really needs:
[x] concurrency [x] a REPL [x] debugger support [x] IDE support [ ] I/O
[x] to interact with code not written in your language
[ ] The entire world speaks 7-bit ASCII
[x] Scaling up to large software projects will be easy
[x] Convincing programmers to adopt a new language will be easy
[ ] Convincing programmers to adopt a language-specific IDE
will be easy
[ ] Programmers love writing lots of boilerplate
[ ] Specifying behaviors as "undefined" means that programmers
won't rely on them
[ ] "Spooky action at a distance" makes programming more fun
Unfortunately, your language (has/lacks): [Lacks => L, Has => H]
[L] comprehensible syntax [L] semicolons
[L] significant whitespace [L] macros
[L] implicit type conversion [H] explicit casting
[H] type inference [H] goto [ ] exceptions [x] closures
[L] tail recursion [L] coroutines [L(planned)] reflection
[L] subtyping [L] multiple inheritance
[L(planned)] operator overloading [H] algebraic datatypes
[H] recursive types [L] polymorphic types [L] covariant array typing
[L] monads [L] dependent types [H] infix operators
[H] nested comments [L] multi-line strings [library] regexes
[H] call-by-value [L] call-by-name [L] call-by-reference
[L] call-cc
The following philosophical objections apply:
[ ] Programmers should not need to understand category theory
to write "Hello, World!"
[ ] Programmers should not develop RSI from writing "Hello, World!"
[ ] The most significant program written in your language is
its own compiler
[X] The most significant program written in your language isn't
even its own compiler
[ ] No language spec
[X] Incomplete language spec
[ ] "The implementation is the spec"
[ ] The implementation is closed-source
[ ] covered by patents
[ ] not owned by you
[X] Your type system is unsound
[ ] Your language cannot be unambiguously parsed
[ ] a proof of same is attached
[ ] invoking this proof crashes the compiler
[ ] The name of your language makes it impossible to find on Google
[ ] Interpreted languages will never be as fast as C
[X] Compiled languages will never be "extensible"
[ ] Writing a compiler that understands English is AI-complete
[ ] Your language relies on an optimization which has
never been shown possible
[ ] There are less than 100 programmers on Earth smart
enough to use your language
[ ] ____________________________ takes exponential time
[ ] ____________________________ is known to be undecidable
Your implementation has the following flaws:
[ ] CPUs do not work that way
[ ] RAM does not work that way
[ ] VMs do not work that way
[ ] Compilers do not work that way
[ ] Compilers cannot work that way
[ ] Shift-reduce conflicts in parsing seem to be resolved using rand()
[ ] You require the compiler to be present at runtime
[ ] You require the language runtime to be present at compile-time
[X] Your compiler errors are completely inscrutable
[ ] Dangerous behavior is only a warning
[X] The compiler crashes if you look at it funny
[ ] The VM crashes if you look at it funny
[X] You don't seem to understand basic optimization techniques
[ ] You don't seem to understand basic systems programming
[ ] You don't seem to understand pointers
[ ] You don't seem to understand functions
Additionally, your marketing has the following problems:
[X] Unsupported claims of increased productivity
[X] Unsupported claims of greater "ease of use"
[ ] Obviously rigged benchmarks (Benchmarks? What are those)
[ ] Graphics, simulation, or crypto benchmarks where your code just calls
handwritten assembly through your FFI
[ ] String-processing benchmarks where you just call PCRE
[ ] Matrix-math benchmarks where you just call BLAS
[X] Noone really believes that your language is faster than:
[x] assembly [x] C [x] FORTRAN [x] Java [ ] Ruby [ ] Prolog
[x] Rejection of orthodox programming-language theory without
justification
[x] Rejection of orthodox systems programming without
justification
[ ] Rejection of orthodox algorithmic theory without
justification
[ ] Rejection of basic computer science without
justification
Taking the wider ecosystem into account, I would like to note that:
[x] Your complex sample code would be one line in: _______________________
[x] We already have an unsafe imperative language
[ ] We already have a safe imperative OO language
[ ] We already have a safe statically-typed eager functional language
[ ] You have reinvented Lisp but worse
[ ] You have reinvented Javascript but worse
[ ] You have reinvented Java but worse
[x] 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 Brainfuck but non-ironically
In conclusion, this is what I think of you:
[x] You have some interesting ideas, but this won't fly.
[x] This is a bad language, and you should feel bad for inventing it.
[x] Programming in this language is an adequate punishment for inventing it.
Can it output me a list of programming languages based on what I check?
As the author of Kitten (http://github.com/evincarofautumn/kitten):
You appear to be advocating a new functional, imperative, procedural, stack-based, eager, statically typed, pure programming language. Your language will not work. Here is why it will not work. Unfortunately, your language has comprehensible syntax, significant whitespace, type inference, closures, tail recursion, algebraic datatypes, polymorphic types, nested comments, multi-line strings, and call-by-value. (It lacks almost everything else.) The most significant program written in your language isn’t even its own compiler. There is no language spec; the implementation is the spec. Compiled languages will never be “extensible”. Your compiler errors are completely inscrutable. No one really believes that your language is faster than assembly, C, or FORTRAN. We already have a safe statically typed eager functional language. You have reinvented Forth but non-ironically. In conclusion, you have some interesting ideas, but this won’t fly.
And the runtime isn’t even done yet. :P
You appear to be advocating a new functional, imperative, procedural, stack-based, eager, statically typed, pure programming language. Your language will not work. Here is why it will not work. Unfortunately, your language has comprehensible syntax, significant whitespace, type inference, closures, tail recursion, algebraic datatypes, polymorphic types, nested comments, multi-line strings, and call-by-value. (It lacks almost everything else.) The most significant program written in your language isn’t even its own compiler. There is no language spec; the implementation is the spec. Compiled languages will never be “extensible”. Your compiler errors are completely inscrutable. No one really believes that your language is faster than assembly, C, or FORTRAN. We already have a safe statically typed eager functional language. You have reinvented Forth but non-ironically. In conclusion, you have some interesting ideas, but this won’t fly.
And the runtime isn’t even done yet. :P
This checklist discourages people from writing their own programming languages. Why not rewrite the checklist as positive, constructive advice around common pitfalls, instead of complaints like "You don't seem to understand X"? There are new programming languages waiting to be invented -- providing a template for knee-jerk negative reactions does not seem like a productive endeavour.
> This checklist discourages people from writing their own programming languages.
Rather, this checklists mocks common discussion-board dismissals that discourage people from writing their own programming languages.
Rather, this checklists mocks common discussion-board dismissals that discourage people from writing their own programming languages.
Okay, you lack a sense of humor, but you're right: I'd definitely have gained from reading a brief, beginner-friendly document like that.
It's a J O K E
Perfect.
To me it looks like a few new languages are introduced every week and I just cannot understand why. I can understand that a programmer who reaches a certain level wants to build his own language, but do they really think that the world is waiting for yet another programming language? It is just not getting easier with a new language.
This article is a must read for everyone who considers writing a new language. If all the arguments do not apply for your language, then the world is probably really waiting for your new language. :)
To me it looks like a few new languages are introduced every week and I just cannot understand why. I can understand that a programmer who reaches a certain level wants to build his own language, but do they really think that the world is waiting for yet another programming language? It is just not getting easier with a new language.
This article is a must read for everyone who considers writing a new language. If all the arguments do not apply for your language, then the world is probably really waiting for your new language. :)
I believe that it is good for any programmer to at some point in their development create a simple language and write an interpreter for it. First, you learn parsing, then you learn what actually makes a language tick. Then you learn what goes into the design process, when you realize you've designed yourself into a corner. Then you start reading up on language design, stumble across sites like Lambda-the-Ultimate.org, and find out that there is a lot more than imperative / OO programming. Then you start getting into the Lisp literature, and reach a zen-like state. Then you snap back to reality, and become a slightly better programmer, who is a bit more humble.
Yes, but there is a difference between writing a lisp interpreter, and expecting that the world will use your lisp interpreter for actual projects. :)
I would also recommend writing a game to any developer. This includes graphics, UI, performance optimization, maybe graph algorithms and more, but like with languages, the result will in most cases not be able to compete with professional games that are already out there.
I would also recommend writing a game to any developer. This includes graphics, UI, performance optimization, maybe graph algorithms and more, but like with languages, the result will in most cases not be able to compete with professional games that are already out there.
First, you learn parsing, then you learn what actually makes a language tick. Then you learn what goes into the design process, when you realize you've designed yourself into a corner. Then you start reading up on language design, stumble across sites like Lambda-the-Ultimate.org, and find out that there is a lot more than imperative / OO programming. Then you start getting into the Lisp literature, and reach a zen-like state. Then you snap back to reality, and become a slightly better programmer, who is a bit more humble.
Or (more likely, in my experience) you throw together a parser and then expand into a rudimentary interpreter/compiler and continue along your merry way having essentially reinvented some language you already knew with a few superficial differences.
Or (more likely, in my experience) you throw together a parser and then expand into a rudimentary interpreter/compiler and continue along your merry way having essentially reinvented some language you already knew with a few superficial differences.
> I can understand that a programmer who reaches a certain level wants to build his own language, but do they really think that the world is waiting for yet another programming language?
Lots of people build model trains. They aren't trying to compete with Amtrak.
Lots of people build model trains. They aren't trying to compete with Amtrak.
I myself am waiting for a new programming language. The right languages can definitely make the world easier. Denying that would be equal to declaring one of the existing languages is optimal/perfect.
I don't expect that there ever will be a perfect or optimal programming language. There is also no perfect natural language.
I would rather say, that the language is just a vehicle and especially beginners identify themselves too much with their preferred language, while more advanced programmer think more in terms of concepts.
You can solve most of the problems with any of the existing languages. Every language has its strengths and weaknesses, but I would say this pretty much balances out, the more different problems you try to solve with a language.
I would rather say, that the language is just a vehicle and especially beginners identify themselves too much with their preferred language, while more advanced programmer think more in terms of concepts.
You can solve most of the problems with any of the existing languages. Every language has its strengths and weaknesses, but I would say this pretty much balances out, the more different problems you try to solve with a language.
> I don't expect that there ever will be a perfect or optimal programming language.
I agree for the present, because of (among other things) the degree to which modern programming languages contain explicit references to particular hardware limitations and problems. The fact that resources are drawn from stack, heap and mechanical storage device, and the existence of rules for choosing which is appropriate, only tells us how primitive modern languages are.
Mathematics might stand as a counterexample (of a universal language) if it were easier to use for programming -- but that problem is being addressed, and computer languages become more like mathematics as time passes.
I agree for the present, because of (among other things) the degree to which modern programming languages contain explicit references to particular hardware limitations and problems. The fact that resources are drawn from stack, heap and mechanical storage device, and the existence of rules for choosing which is appropriate, only tells us how primitive modern languages are.
Mathematics might stand as a counterexample (of a universal language) if it were easier to use for programming -- but that problem is being addressed, and computer languages become more like mathematics as time passes.
I disagree that mathematics is a universal language. Yes, "everyone" understands that 1 + 1 = 2 (most of the time, anyway), but that's not all there is to mathematics. There are vast numbers of different branches of mathematics, often compatible but also often incompatible (in both notation and semantics). There is a fairly common core of mathematical syntax, but beyond that different branches will use their own syntax. Perhaps that's like Lisps: the same fundamental meta-syntax but significantly different and often incompatible semantics and syntax on top of that.
I wasn't arguing that mathematics is a universal language, only that it approaches the ideal more closely than the present generation of computer programming languages.
> There is a fairly common core of mathematical syntax, but beyond that different branches will use their own syntax.
The fact that mathematics has many divisions isn't a counterargument unless mathematicians use different notations to refer to the same things. Apart from notoriously overused Greek letters, notations are unique and independent.
Spoken languages have many distinct vocabularies to serve the needs of specialists, but this doesn't undermine the usefulness of the language as a general tool. Same with mathematics.
> There is a fairly common core of mathematical syntax, but beyond that different branches will use their own syntax.
The fact that mathematics has many divisions isn't a counterargument unless mathematicians use different notations to refer to the same things. Apart from notoriously overused Greek letters, notations are unique and independent.
Spoken languages have many distinct vocabularies to serve the needs of specialists, but this doesn't undermine the usefulness of the language as a general tool. Same with mathematics.
I think the world is waiting for a new programming language. It is about that time historically and we are going into a situation where cores have replace GHz. Its not clear what the model will be. I think a lot of the new languages are models for how the language designer is thinking (or not) about these new realities. At the same time, the hop from PC to Post-PC like the hop from Mini to PC, brings new constraints (dammit, where'd all my memory go) and a new environment to the programming (what do you mean the computer moves while my program is running).
> You appear to believe that:
> [ ] Syntax is what makes programming difficult
Lol I went from RoR to Java (IBM Websphere stuff) & all my Python dev friends started trying to explain to me how its a career killer because Java's syntax is archaic.
Turns out the company I'm at is using very advanced builder tools and then just integrate a bit with linked Java objects. Pretty neat! And has given me time to shift study toward Play framework / Node / Dart / Clojure.
> [ ] Syntax is what makes programming difficult
Lol I went from RoR to Java (IBM Websphere stuff) & all my Python dev friends started trying to explain to me how its a career killer because Java's syntax is archaic.
Turns out the company I'm at is using very advanced builder tools and then just integrate a bit with linked Java objects. Pretty neat! And has given me time to shift study toward Play framework / Node / Dart / Clojure.
I believe programmers should rather focus their attention to understanding the internals of existing languages, this will do wonders to the way they program.
Re: "[ ] The most significant program written in your language isn't even its own compiler"
There's a great quote by someone which Googling can't find, that goes along the lines of: "a language whose own compiler isn't written in itself is beneath contempt."
There's a great quote by someone which Googling can't find, that goes along the lines of: "a language whose own compiler isn't written in itself is beneath contempt."
As a non-expert in programming languages I find this list a good starting point for learning: reading about each bullet point in Wikipedia might already be useful. And arguing on HN is not the single application of this knowledge.
As a researcher working on experimental PLs [1]...why not
[1] http://research.microsoft.com/en-us/people/smcdirm/liveprogr...
[1] http://research.microsoft.com/en-us/people/smcdirm/liveprogr...
You appear to be advocating a new:
[ ] functional [X] imperative [X] object-oriented [X] procedural [ ] stack-based
[ ] "multi-paradigm" [ ] lazy [ ] eager [X] statically-typed [ ] dynamically-typed
[ ] pure [X] impure [ ] non-hygienic [ ] visual [ ] beginner-friendly
You appear to believe that:
[X] Garbage collection is free [X] Computers have infinite memory
[ ] Nobody really needs:
[ ] concurrency [X] a REPL [ ] debugger support [ ] IDE support [ ] I/O
[ ] to interact with code not written in your language
[X] Convincing programmers to adopt a new language will be easy
[X] Convincing programmers to adopt a language-specific IDE will be easy
[X] "Spooky action at a distance" makes programming more fun
Unfortunately, your language (H -> has/ L -> lacks) :
[H] comprehensible syntax [L] semicolons [H] significant whitespace [L] macros
[L] implicit type conversion [L] explicit casting [H] type inference
[L] goto [L] exceptions [L] closures [L] tail recursion [L] coroutines
[L] reflection [H] subtyping [H] multiple inheritance [L] operator overloading
[L] algebraic datatypes [L] recursive types [H] polymorphic types
[H] covariant array typing [L] monads [L] dependent types
[H] infix operators [L] nested comments [L] multi-line strings [L] regexes
[H] call-by-value [L] call-by-name [L] call-by-reference [L] call-cc
The following philosophical objections apply:
[X] The most significant program written in your language isn't even its own compiler
[X] No language spec
[X] "The implementation is the spec"
[X] The implementation is closed-source [X] covered by patents [X] not owned by you
[?] Your type system is unsound
[X] ____________________________ takes exponential time
[X] ____________________________ is known to be undecidable
Your implementation has the following flaws:
[X] CPUs do not work that way
[X] RAM does not work that way
[X] VMs do not work that way
[X] Compilers do not work that way
[X] Compilers cannot work that way
[X] You require the compiler to be present at runtime
[X] You require the language runtime to be present at compile-time
[X] Dangerous behavior is only a warning
[X] You don't seem to understand basic optimization techniques
[X] You don't seem to understand basic systems programming
Additionally, your marketing has the following problems:
[X] Unsupported claims of increased productivity
[X] Unsupported claims of greater "ease of use"
[ ] Noone really believes that your language is faster than:
[X] assembly [X] C [X] FORTRAN [X] Java [X] Ruby [ ] Prolog
[X] Rejection of orthodox programming-language theory without justification
[X] Rejection of orthodox systems programming without justification
[ ] Rejection of orthodox algorithmic theory without justification
[X] Rejection of basic computer science without justification
Taking the wider ecosystem into account, I would like to note that:
[X] We already have an unsafe imperative language
[X] We already have a safe imperative OO language
In conclusion, this is what I think of you:
[ ] You have some interesting ideas, but this won't fly.
[ ] This is a bad language, and you should feel bad for inventing it.
[ ] Programming in this language is an adequate punishment for inventing it.I only upvoted this because McMillen wrote it.
Hilariously, C checks a lot of these boxes.
I once built a stupid language for fun. Think a bastard child of FORTH and brainfuck, but in two dimensions. To give an idea of how stupid it was, I will fill this in.
You appear to be advocating a new:
[ ] functional [X] imperative [ ] object-oriented [X] procedural [X] stack-based
[ ] "multi-paradigm" [ ] lazy [X] eager [ ] statically-typed [X] dynamically-typed
[ ] pure [ ] impure [ ] non-hygienic [X] visual [ ] beginner-friendly
[X] non-programmer-friendly [X] completely incomprehensible
programming language. Your language will not work. Here is why it will not work.
You appear to believe that:
[ ] Syntax is what makes programming difficult
[ ] Garbage collection is free [ ] Computers have infinite memory
[ ] Nobody really needs:
[X] concurrency [X] a REPL [X] debugger support [X] IDE support [ ] I/O
[X] to interact with code not written in your language
[ ] The entire world speaks 7-bit ASCII
[ ] Scaling up to large software projects will be easy
[ ] Convincing programmers to adopt a new language will be easy
[ ] Convincing programmers to adopt a language-specific IDE will be easy
[ ] Programmers love writing lots of boilerplate
[ ] Specifying behaviors as "undefined" means that programmers won't rely on them
[X] "Spooky action at a distance" makes programming more fun
Unfortunately, your language (has/lacks):
[-] comprehensible syntax [-] semicolons [+] significant whitespace [-] macros
[+] implicit type conversion [-] explicit casting [-] type inference
[+] goto [-] exceptions [-] closures [-] tail recursion [-] coroutines
[-] reflection [-] subtyping [-] multiple inheritance [-] operator overloading
[-] algebraic datatypes [-] recursive types [-] polymorphic types
[-] covariant array typing [-] monads [-] dependent types
[-] infix operators [+] nested comments [+] multi-line strings [-] regexes
[-] call-by-value [-] call-by-name [+] call-by-reference [-] call-cc
The following philosophical objections apply:
[ ] Programmers should not need to understand category theory to write "Hello, World!"
[ ] Programmers should not develop RSI from writing "Hello, World!"
[ ] The most significant program written in your language is its own compiler
[X] The most significant program written in your language isn't even its own compiler
[ ] No language spec
[ ] "The implementation is the spec"
[ ] The implementation is closed-source [ ] covered by patents [ ] not owned by you
[ ] Your type system is unsound [ ] Your language cannot be unambiguously parsed
[ ] a proof of same is attached
[ ] invoking this proof crashes the compiler
[X] The name of your language makes it impossible to find on Google
[X] Interpreted languages will never be as fast as C
[ ] Compiled languages will never be "extensible"
[ ] Writing a compiler that understands English is AI-complete
[ ] Your language relies on an optimization which has never been shown possible
[ ] There are less than 100 programmers on Earth smart enough to use your language
[ ] ____________________________ takes exponential time
[ ] ____________________________ is known to be undecidable
Your implementation has the following flaws:
[ ] CPUs do not work that way
[ ] RAM does not work that way
[ ] VMs do not work that way
[ ] Compilers do not work that way
[ ] Compilers cannot work that way
[ ] Shift-reduce conflicts in parsing seem to be resolved using rand()
[X] You require the compiler to be present at runtime
[ ] You require the language runtime to be present at compile-time
[X] Your compiler errors are completely inscrutable
[X] Dangerous behavior is only a warning
[X] The compiler crashes if you look at it funny
[X] The VM crashes if you look at it funny
[X] You don't seem to understand basic optimization techniques
[ ] You don't seem to understand basic systems programming
[ ] You don't seem to understand pointers
[ ] You don't seem to understand functions
Additionally, your marketing has the following problems:
[ ] Unsupported claims of increased productivity
[ ] Unsupported claims of greater "ease of use"
[ ] Obviously rigged benchmarks
[ ] Graphics, simulation, or crypto benchmarks where your code just calls
handwritten assembly through your FFI
[ ] String-processing benchmarks where you just call PCRE
[ ] Matrix-math benchmarks where you just call BLAS
[X] Noone really believes that your language is faster than:
[X] assembly [X] C [X] FORTRAN [X] Java [X] Ruby [X] Prolog
[X] Rejection of orthodox programming-language theory without justification
[ ] Rejection of orthodox systems programming without justification
[ ] Rejection of orthodox algorithmic theory without justification
[ ] Rejection of basic computer science without justification
Taking the wider ecosystem into account, I would like to note that:
[X] Your complex sample code would be one line in: almost anything, actually
[ ] We already have an unsafe imperative language
[ ] We already have a safe imperative OO language
[ ] We already have a safe statically-typed eager functional language
[ ] 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 Brainfuck but non-ironically
In conclusion, this is what I think of you:
[ ] You have some interesting ideas, but this won't fly.
[X] This is a bad language, and you should feel bad for inventing it.
[X] Programming in this language is an adequate punishment for inventing it.
Now you have to tell us what it is.
Totally agree. GP, please post a link. We won't make fun of you.
On thy own heads be it. Here is the code, as written when I was 16. You'll need Tcl 8.5 to run it (8.3 is probably fine, but you'll have to change the line at the beginning), because all the cool kids implement interpreted languages in other interpreted languages. (Actually, wasn't Arc implemented that way originally?)
https://www.dropbox.com/s/zqahavw2yoeca5p/stringsh.zip
https://www.dropbox.com/s/zqahavw2yoeca5p/stringsh.zip
That's pretty awesome.
I'm working on a little object-oriented scripting language:
You appear to be advocating a new:
[X] functional [X] imperative [X] object-oriented [ ] procedural [ ] stack-based
[ ] "multi-paradigm" [ ] lazy [X] eager [ ] statically-typed [X] dynamically-typed
[ ] pure [X] impure [ ] non-hygienic [ ] visual [ ] beginner-friendly
[ ] non-programmer-friendly [ ] completely incomprehensible
programming language. Your language will not work. Here is why it will not work.
You appear to believe that:
[ ] Syntax is what makes programming difficult
[X] Garbage collection is free [X] Computers have infinite memory
[ ] Nobody really needs:
[ ] concurrency [ ] a REPL [X] debugger support [X] IDE support [ ] I/O
[ ] to interact with code not written in your language
[ ] The entire world speaks 7-bit ASCII
[X] Scaling up to large software projects will be easy
[ ] Convincing programmers to adopt a new language will be easy
[ ] Convincing programmers to adopt a language-specific IDE will be easy
[ ] Programmers love writing lots of boilerplate
[ ] Specifying behaviors as "undefined" means that programmers won't rely on them
[ ] "Spooky action at a distance" makes programming more fun
Unfortunately, your language (has/lacks):
[+] comprehensible syntax [-] semicolons [-] significant whitespace [-] macros
[-] implicit type conversion [+] explicit casting [-] type inference
[-] goto [-] exceptions [+] closures [ ] tail recursion [+] coroutines
[+] reflection [+] subtyping [-] multiple inheritance [+] operator overloading
[ ] algebraic datatypes [ ] recursive types [ ] polymorphic types
[ ] covariant array typing [ ] monads [ ] dependent types
[+] infix operators [+] nested comments [ ] multi-line strings [ ] regexes
[ ] call-by-value [ ] call-by-name [+] call-by-reference [ ] call-cc
The following philosophical objections apply:
[ ] Programmers should not need to understand category theory to write "Hello, World!"
[ ] Programmers should not develop RSI from writing "Hello, World!"
[ ] The most significant program written in your language is its own compiler
[X] The most significant program written in your language isn't even its own compiler
[X] No language spec
[X] "The implementation is the spec"
[ ] The implementation is closed-source [ ] covered by patents [ ] not owned by you
[ ] Your type system is unsound [ ] Your language cannot be unambiguously parsed
[ ] a proof of same is attached
[ ] invoking this proof crashes the compiler
[ ] The name of your language makes it impossible to find on Google
[X] Interpreted languages will never be as fast as C
[X] Compiled languages will never be "extensible"
[ ] Writing a compiler that understands English is AI-complete
[ ] Your language relies on an optimization which has never been shown possible
[ ] There are less than 100 programmers on Earth smart enough to use your language
[ ] ____________________________ takes exponential time
[ ] ____________________________ is known to be undecidable
Your implementation has the following flaws:
[ ] CPUs do not work that way
[ ] RAM does not work that way
[ ] VMs do not work that way
[ ] Compilers do not work that way
[ ] Compilers cannot work that way
[ ] Shift-reduce conflicts in parsing seem to be resolved using rand()
[X] You require the compiler to be present at runtime
[ ] You require the language runtime to be present at compile-time
[ ] Your compiler errors are completely inscrutable
[ ] Dangerous behavior is only a warning
[ ] The compiler crashes if you look at it funny
[ ] The VM crashes if you look at it funny
[X] You don't seem to understand basic optimization techniques
[ ] You don't seem to understand basic systems programming
[ ] You don't seem to understand pointers
[ ] You don't seem to understand functions
Additionally, your marketing has the following problems:
[ ] Unsupported claims of increased productivity
[ ] Unsupported claims of greater "ease of use"
[ ] Obviously rigged benchmarks
[ ] Graphics, simulation, or crypto benchmarks where your code just calls
handwritten assembly through your FFI
[ ] String-processing benchmarks where you just call PCRE
[ ] Matrix-math benchmarks where you just call BLAS
[ ] Noone really believes that your language is faster than:
[X] assembly [X] C [X] FORTRAN [X] Java [ ] Ruby [ ] Prolog
[ ] Rejection of orthodox programming-language theory without justification
[ ] Rejection of orthodox systems programming without justification
[ ] Rejection of orthodox algorithmic theory without justification
[ ] Rejection of basic computer science without justification
Taking the wider ecosystem into account, I would like to note that:
[ ] Your complex sample code would be one line in: _______________________
[ ] We already have an unsafe imperative language
[X] We already have a safe imperative OO language
[ ] We already have a safe statically-typed eager functional language
[ ] 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 Brainfuck but non-ironically
In conclusion, this is what I think of you:
[ ] You have some interesting ideas, but this won't fly.
[X] This is a bad language, and you should feel bad for inventing it.
[ ] Programming in this language is an adequate punishment for inventing it.Here is the checklist for my programming language, foil -- demo available (requires Java plugin) at http://picomancer.com/blog/foil-compiler-tech-preview/
You appear to be advocating a new:
[ ] functional [x] imperative [x] object-oriented [ ] procedural [ ] stack-based
[ ] "multi-paradigm" [ ] lazy [ ] eager [x] statically-typed [x] dynamically-typed
[ ] pure [ ] impure [ ] non-hygienic [ ] visual [x] beginner-friendly
[ ] non-programmer-friendly [ ] completely incomprehensible
programming language. Your language will not work. Here is why it will not work.
You appear to believe that:
[x] Syntax is what makes programming difficult
[ ] Garbage collection is free [ ] Computers have infinite memory
[ ] Nobody really needs:
[ ] concurrency [ ] a REPL [ ] debugger support [ ] IDE support [ ] I/O
[ ] to interact with code not written in your language
[x] The entire world speaks 7-bit ASCII
[ ] Scaling up to large software projects will be easy
[x] Convincing programmers to adopt a new language will be easy
[ ] Convincing programmers to adopt a language-specific IDE will be easy
[ ] Programmers love writing lots of boilerplate
[x] Specifying behaviors as "undefined" means that programmers won't rely on them
[ ] "Spooky action at a distance" makes programming more fun
Unfortunately, your language (has/lacks):
[Y] comprehensible syntax [N] semicolons [Y] significant whitespace [N] macros
[N] implicit type conversion [N] explicit casting [Y] type inference
[Y] goto [Y] exceptions [Y] closures [N] tail recursion [Y] coroutines
[N] reflection [Y] subtyping [ ] multiple inheritance [Y] operator overloading
[ ] algebraic datatypes [ ] recursive types [ ] polymorphic types
[ ] covariant array typing [ ] monads [ ] dependent types
[ ] infix operators [ ] nested comments [Y] multi-line strings [ ] regexes
[Y] call-by-value [ ] call-by-name [Y] call-by-reference [ ] call-cc
The following philosophical objections apply:
[ ] Programmers should not need to understand category theory to write "Hello, World!"
[ ] Programmers should not develop RSI from writing "Hello, World!"
[ ] The most significant program written in your language is its own compiler
[x] The most significant program written in your language isn't even its own compiler
[x] No language spec
[x] "The implementation is the spec"
[ ] The implementation is closed-source [ ] covered by patents [ ] not owned by you
[ ] Your type system is unsound [ ] Your language cannot be unambiguously parsed
[ ] a proof of same is attached
[ ] invoking this proof crashes the compiler
[ ] The name of your language makes it impossible to find on Google
[ ] Interpreted languages will never be as fast as C
[ ] Compiled languages will never be "extensible"
[ ] Writing a compiler that understands English is AI-complete
[ ] Your language relies on an optimization which has never been shown possible
[ ] There are less than 100 programmers on Earth smart enough to use your language
[ ] ____________________________ takes exponential time
[ ] ____________________________ is known to be undecidable
Your implementation has the following flaws:
[ ] CPUs do not work that way
[ ] RAM does not work that way
[ ] VMs do not work that way
[ ] Compilers do not work that way
[ ] Compilers cannot work that way
[ ] Shift-reduce conflicts in parsing seem to be resolved using rand()
[ ] You require the compiler to be present at runtime
[ ] You require the language runtime to be present at compile-time
[x] Your compiler errors are completely inscrutable
[x] Dangerous behavior is only a warning
[ ] The compiler crashes if you look at it funny
[ ] The VM crashes if you look at it funny
[ ] You don't seem to understand basic optimization techniques
[ ] You don't seem to understand basic systems programming
[ ] You don't seem to understand pointers
[ ] You don't seem to understand functions
Additionally, your marketing has the following problems:
[ ] Unsupported claims of increased productivity
[ ] Unsupported claims of greater "ease of use"
[ ] Obviously rigged benchmarks
[ ] Graphics, simulation, or crypto benchmarks where your code just calls
handwritten assembly through your FFI
[ ] String-processing benchmarks where you just call PCRE
[ ] Matrix-math benchmarks where you just call BLAS
[ ] Noone really believes that your language is faster than:
[ ] assembly [ ] C [ ] FORTRAN [ ] Java [ ] Ruby [ ] Prolog
[ ] Rejection of orthodox programming-language theory without justification
[ ] Rejection of orthodox systems programming without justification
[ ] Rejection of orthodox algorithmic theory without justification
[ ] Rejection of basic computer science without justification
Taking the wider ecosystem into account, I would like to note that:
[ ] Your complex sample code would be one line in: _______________________
[ ] We already have an unsafe imperative language
[ ] We already have a safe imperative OO language
[ ] We already have a safe statically-typed eager functional language
[ ] 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 Brainfuck but non-ironically
In conclusion, this is what I think of you:
[ ] You have some interesting ideas, but this won't fly.
[ ] This is a bad language, and you should feel bad for inventing it.
[ ] Programming in this language is an adequate punishment for inventing it.[x] Code can be shared without compromising security
This is made possible with...
* compile-time memory protection
* automatic memory management
* compile-time data access restrictions (mark struct members as read-only)
* divide programs into small, mutually-distrusting components
* add features by adding components, not by changing existing components
The last two points are things the programmer has to do, but keep in mind that programming languages today don't even give you the opportunity to design this way. The last paradigm that did was C / Unix, and that was back when it was reasonable to send program state over a pipe.
Java tried to do this in the 90s, but a quick web search for "Java security" will turn up the historical record. In my opinion, VMs are inherently insecure, so I think the flaw in Java's approach was the decision to make Java run on a VM. VMs are inherently monolithic, and thus violate the "network of mutually-distrusting components" point above.
For more semi-coherent rambling on this topic, see my latest blog post... http://dbpokorny.blogspot.com/2013/11/prisoner-of-paradigm.h...
This is made possible with...
* compile-time memory protection
* automatic memory management
* compile-time data access restrictions (mark struct members as read-only)
* divide programs into small, mutually-distrusting components
* add features by adding components, not by changing existing components
The last two points are things the programmer has to do, but keep in mind that programming languages today don't even give you the opportunity to design this way. The last paradigm that did was C / Unix, and that was back when it was reasonable to send program state over a pipe.
Java tried to do this in the 90s, but a quick web search for "Java security" will turn up the historical record. In my opinion, VMs are inherently insecure, so I think the flaw in Java's approach was the decision to make Java run on a VM. VMs are inherently monolithic, and thus violate the "network of mutually-distrusting components" point above.
For more semi-coherent rambling on this topic, see my latest blog post... http://dbpokorny.blogspot.com/2013/11/prisoner-of-paradigm.h...
...and brendan eich checked all the boxes
Unless you work for Google, in which case your language's name (maybe shared with a common verb or a popular board game) will quickly become the top search result!