The KitchenSink Language
I’ve started getting into language design more these days, and have several language related projects. While I’m far from a real language creator like this poetic guy, this gawky guy, this dude from Nippon, and this really anal guy who should have stayed a physicist, I do like it as a hobby.
One thing I’ve found royally annoying from beginning to intermediate programmers is they are so focused on the language and believe that the latest greatest “paradigm” will save us all. They point at some obscure language feature they enjoy and claim it’s so great. “Function programming closures…” or “Object polymorphism…” are usually how such rants start. There’s really two problems with this though:
- It’s the platform stupid.
- You claim this is true, but where’s your evidence computer scientist?
What do I mean by “It’s the platform stupid”? Well, I’m being slightly hypocritical here when I give the second statement, but the general idea is that the language doesn’t matter as much as the capabilities of the platform the language sits upon. Take Java as an example: It’s features aren’t really that different from any other language. There’s little bits of syntax and simplified things that C++ apparently did wrong, but in the end, it’s pretty much the same as C++. This is where most programmers say, “Yeah, but with Java I have a cross platform language, dynamic loading, tons of classes in a massive library…” Yes, you are right, but this is the platform not the language.
My general complaint about this is that the platform should be separated from the language and created for any language that wants to use it, but as long as programmers and language designers keep globbing languages and platforms together, we’ll never have this. The general proof of the advantage of separating language from the platform is also in Java as I can write an interpreter for the Java Virtual Machine rather quickly (as was done with Jython and many, many, other languages) and gain all of the advantages of the Java Platform, but without having to use any of the Java language. The nearly crisp division between language and platform resides at the point where you can implement another language on top of an existing language’s capabilities and support infrastructure. So, the JVM, Java Class libraries, java byte code, supporting libraries, and other goodies are easily separated from the Java language which focuses on how a while loop should be structured.
There is of course some interplay between the platform and the language,
otherwise there would be no binding between them. It’s only recently with the introduction of well designed scripting languages and heavily cross platform virtual machines that we’ve seen a true possibility to have an entirely separate platform (or runtime maybe?) from any language. I really think Microsoft has the right idea with the CLI: let any language run on it. I can forgive programmers maybe eight years ago because they didn’t have this really since you either were stuck with C++ and [insert favorite platform here] or you just couldn’t use C++ to do anything very useful. Also it was in a language designer’s interests to tightly couple their language to the runtime since they could more easily attract programmers to the language if the runtime had lots of nice goodies. And attracting followers really what counts in the religion and business of programming language promotion.
Now, this of course is just an argument, and I’m being hypocritical when I give my second complaint: “You claim this is true, but where’s your evidence computer scientist?” This one is really simple: if you are a language designer, and you claim your syntax, semantics, library or fundamental paradigm (especially that) is so fantastic, easy to learn, improved, superior, or other claim, then you should back it up with some empirical evidence. This is actually pretty easy to do, and there’s a huge part of Cognitive Science which is devoted to just studying how programmers use languages. You basically run a series of experiments to test your hypothesis, and publish your results for others to verify and criticize. I’m not being too hypocritical here because there actually is tons of research that shows software development is still too tedious and error prone.
What I usually hear from language designers is a laundry list of minuscule little features which are not really any better than any other language, and are usually just style differences. Many times a new “paradigm” (which is just a fancy way of slapping a “NEW!” sticker on something) is touted as being some fantastic advantage over what everyone else is doing, and then the language creator starts forcing students in some classes to learn it. This is done without any verification of the proposed claims and smacks so much of religious brain washing that it leaves a nasty taste in my mouth. If this is how languages are pushed, then stop calling it a science.
There are a few languages which were designed by testing the features on prospective users, and these languages tend to be really easy to use. Smalltalk and Python both come to mind as languages which meet this criteria. Also, many open source languages are typically put forth as a tool for others to use, and promoted like any other project, so they are basically doing this (although, some rigor would be nice). The people I’m complaining about are professors who tend to teach a language they have created, or which they advocate, but which they have done no usability testing or empirical analysis prior to forcing students to learn the language.
Functional programming advocates are the worst offenders of this. I personally like the idea behind functional programming, but the technique is just one more in my arsenal of problem solving techniques. It’s not the one true way as Schemers or Haskelites would have you think (and remember, it’s up to them to prove that, not me to disprove something which hasn’t been proven yet). Even though functional programming advocates can’t point me to any research into patterns, frameworks, re-usable platforms, or even simple “cook-books” of how to do things in their favorite language, they expect me to abandon my all my available tools and join their religion. Worst of all, they force their students to learn these languages (which are not used in industry very much, limiting the student’s marketability) because they know that programmers (and people) are generally lazy. It’s easier to slam every problem into a functional programming “nail” once you have learned your functional programming “hammer”.
The analogy I like to make about this aspect of computer science education is with a biology professor. Imagine you’re taking an introductory biology course as part of your pre-Med curriculum to become a Medical Doctor. This course is most likely going to be difficult, and intended to prepare you for professional work as a physician. Now, the first day, your professor comes in and announces that she “has discovered the meaning of life and it is ”Rael":http://www.rael.org/". She then insists that, in order to pass her class, you must learn all of Raelian science, write several articles for the local Raelian Gazzette, and participate in all Rael rallies. I bet you would probably complain wouldn’t you? Hell, you’d have her fired on the spot. Who is she to teach something so unscientific as Rael in a biology class!
Yet, you sit there when a computer science professor walks in a class and says, “I have discovered the best way to write software, and it is [insert catch phrase paradigm of the week] programming. You will be required to learn this language to pass my class. You will write several assignments in the language. You will be forced to attend labs in the language…” Why does he have the right to do this? Because there are no scientific standards in computer science. There are no peers yelling, “Hey! That hasn’t been peer reviewed, who the hell are you to teach that?” Nobody is standing up demanding that the latest language feature be tested and peer reviewed before it is forced on paying customers (students). Nope, they just go, “Oh, it’s new and he has a Ph.D., it must be correct then.” What is missing are the concepts of scientific method, empirical validation, experimentation, and peer review.
In other aspects of computer science (algorithm complexity, computational mathematics, cryptography, computational geometry, etc.) this is not the case. These are typically not empirical parts of the discipline (although, I think someone should do empirical validation before claiming an algorithm is faster than another) but rather based on mathematical logic. The fallacy that most computer scientists make is that the logic and rigor of these computational mathematics aspects applies to other parts of computers science where empirical evidence and experimentation are better analysis techniques. Generally, these areas involve anything to do with people: usability, graphics perceptions, interface design, language development, software engineering, process management, and many other human aspects of computer science. What needs to happen is for computer scientists to realize that these aspects are empirical and start following the rest of the scientific world (Biology, Physics, Psychology, Astrophysics, everything%20and%20apply%20statistical%20empirically%0Aexperimentation%20based%20analysis%20methods.%0A%0A%0A%0Ah2.%20If%20One%20Is%20Better,%20Ten%20Must%20Be%20The%20Best)
While that rant may seem overly long, it sets the stage for this language I’m putting together as kind of another INTERCAL. My impression of INTERCAL was that the designers intended to make fun of the ranting fools pushing Structured Programming (again, without any proof that it was superior). They took all the purported features and turned them on their head, creating a language that was nearly impossible to understand and work with.
With KitchenSink, I’m going to attempt to combine all of the features that language purists claim will make programming better. I figure, if one paradigm is better, then why not include them all! This language will be the best language in the world if you go by how language nuts (i.e. people who think the language and platform are married) rate the latest programming languages. I am going to try to make the language as simple as possible, but in the end, I believe it will be hopelessly useless, and only a novelty. Then again, I may hit onto something and actually make the best language in the world! (yeah, alright)
Here’s the short list of the super cool paradigms I’m gonna have in KitchenSink:
* Object-Oriented Programming — Can’t have a language without being a slave to the objects. Even better, my object design will be based on exemplars rather than class structured (another popular academia thingy). That’s where you don’t define your ontology, but rather just say, “this thing is like that thing with these differences”.
* Functional Programming — Functions will be first class objects, will have closures, and you’ll be encouraged to make them like crazy even if they don’t help the design one bit.
* Concatenative Programming — This latest and greatest language feature as promoted in Forth, Onyx, Joy, and PostScript (creates some wonderfully cryptic programs) and you know how conciseness is next to godliness with math junkies. Who cares if nobody can read it without a diagram of a massive complicated stack flow! It’s concise dammit!
* Templates and Aspect-Oriented Programming — Damn, some zealots have proclaimed that “Any language with a pre-processor is broken.” Rather than admit that meta-programming is really useful for creating generic components, we’ll just recast the pre-processor as “an Aspect-Oriented Compiler”, and start calling macros “templates”.
* Structured Programming — How could you possibly have any language that wasn’t also structured!? Heaven forbid you should create a nice interaction based language like Smalltalk. Nope, it has to be a lock step algorithm or it’s not “provable”.
* Logical Proofs and Design By Contract — It doesn’t matter that Design by Contract has been “proven” (through logic though) to be equivalent to Clean Room logical proofs. It doesn’t matter that a logic proof doesn’t prevent bugs during runtime. All that matters is that I make software development so difficult that only a trained math genius could ever write a piece of software. That will keep all those pesky H1-B visa carriers out of the business.
* Full Set Manipulation Operators — Hey, everything in a computer is just a set of some kind. Who needs easy to use indexing that follows what everyone was taught in high school algebra? Let’s do what R, Haskell, and now Python have done by making cryptic indexing possible.
* Tail Recursion — Hey, we’ve got functional programming, but damn making those stacks is really slow. What’s that? Why not just introduce that highly useful concept of “iteration”? Tisk-tisk. That’s not very purist of you. Are you sure you’re a member of the inner circle? I could have sworn that iteration was a forbidden word in the functional religion. We call that “tail recursion” here. Maybe you should go to the end of the line.
* *Lots and Lots of Idiotic Silly Operators (LLISO)* — Programming’s all about problem solving, and nothing is more fun than reading tons of symbols that, when combined, must be carefully taken apart to understand what’s really going on. That really makes the language a wonderful puzzle that needs to be solved (because, as an academic, I don’t really need to be solving puzzles with the language, I want to solve them in the language). Even better is when these symbols are the inverse of what everyone else is familiar with using. The main advantage of this is that I can force the user to adopt symbols and structuring constraints which makes my compiler design so much easier. Who needs expressiveness when you have a massive Perceived I.Q. booster like Lisp Parentheses and wonderful stuff like CADR, CDDR, CADDR, and CDDRDDADR!? Hey, that reminds me, most programmers can’t type, so let’s save keystrokes at every turn and use acronyms and abrvt. kywrds.
* Built-In Finite State Machine Processing — FSMs are these wonderfully mathematically correct little things that can do just about anything a language can do, so why not incorporate them right in the language? Sure there’s a cognitive limit to the complexity of an FSM, and sure they become nearly incomprehensible when combined with other FSMs (and possibly unprovable), but it’s all about mathematics, not usability here. As long as I can do some sort of mathematical proof on the program, even if that proof only works in an unrealistically constrained environment, I can be sure that my program will always work. Let’s just hope nobody installs it on a new computer or uses it for anything it wasn’t intended for originally. Nobody does that right? Things don’t change right?
I think that list of features should keep me busy for a while. When it’s done, it will be the most powerful, most useful, most capable language in the world! Simply using all of these great new paradigms will surely win me some kind of award.