Human-computer interaction and programming

The other week, I was dismissive of an attempt at creating a “non-programming” sort of programming. I’d like to explain myself a bit more.

The trouble, I think, is that many people confuse the problem. Programming is pretty terrible, but I don’t think that’s because we write programs in a programming language. I think it’s because we write poor programs in poor languages, with poor tools, using poor libraries, that are all poor mostly because we’ve built everything on shaky foundations we can’t fix and basically because we still don’t know what we’re doing as an industry. So we’re quite fond of metaphors like “it’s held together with duct tape and bailing wire.”

When people try to create “non-programming” sorts of programming, they generally fix none of those issues. And they remove the successes we do have with languages. And they mistakenly believe that “ordinary” people are incapable of programming. And then they make a truly, horribly fundamental mistake: they try to make things graphical and clicky.

You see, I think there’s three basic levels of communication from humans to computers. There’s the “point and click” level, the expert “real-time” level, and then there’s the language level.

You’re probably familiar with all of these, but let me make sure I’m clear. We browse the web almost entirely at the “point and click” level. It’s essentially how we interact with tablets and smart phones.

For the expert “real-time” (for lack of a better term) level, we can look to the kinds of sound boards that audio engineers use. Or to vim used by programmers, and it’s myriad of commands. Or even to games, like World of Warcraft, once players bind every ability to a key on their keyboard (and aren’t clicking on icons anymore.)

Or even just a keyboard when you need to type a lot of text. Doing that on a phone or tablet is awful!

Already with just these two levels, I think people generally appreciate the difference. I’ve heard many people parrot the comment on how tablets are only good for consuming content, not creating it. And I hope nobody tries to write papers or essays on a tablet without a keyboard.

But once we get to the next level, linguistic communication, I think people seem to forget that lesson, or somehow think it doesn’t apply. Then we get Lab View and Excel, and all manner of other mistakes in trying to program by pointing and clicking. Somewhere along the line, I heard someone joke that you can’t do anything truly useful without language, as a caveman, solely by pointing and grunting. Well, you can (see above: surf the web! “useful”…), but I think when you need language, it is really and truly irreplaceable. When humans need to communicate with humans, we sure haven’t figured out anything better yet.

The trouble, of course, is that these things (like Lab View and Excel) have actually succeeded pretty well, and so I can’t be totally right that these are useless. But the trouble is not that they’re useless, it’s that they inevitably lead to horrible messes as a result. Multi-million dollar businesses relying on incredibly error-prone piles of crap no one wants to touch, and no one understands, is extremely common. We have entire research programs dedicated to trying to figure out how to mitigate this mess. And they have a “horror stories” link on their front page.

So I’m extremely skeptical of this sort of thing.

But let me point out one bright side: Scratch. It’s point and click programming. But there are two amazingly important differences between Scratch and other kinds of point and click programming I’ve seen. One: it’s still quite linguistic. Look at the front-page example. An event hook, a loop, and a series of commands. No you didn’t type all that in letter by letter, but you’re still pretty much writing in a language and kids get it. And two: it’s a stepping stone for learning, not an attempt to “make programming easier” or make programing “not programming.” This makes all the difference in the world. Nobody is going to try to build anything but toys for their own education with Scratch.

So here’s my tl;dr bit of advice for anyone trying to replace Excel, or whatever: you can have a Scratch-like learning mode for using your software, to make it easy to use for non-programmers. But the point of this shouldn’t be to “make programming easier” or wave your hands and claim it’s “not programming”, it’s to teach those users programming. Confront the hard problem straight on, and solve it. One day, they can turn that mode off, and then write their programs.

Oh and also, don’t make up a programming language that ignores everything we’ve learned about programming languages for the past 60 years. It’d certainly help us avoid a big mess if they’re not then writing programs in yet another poorly thought out undesigned language.

Posted in Programming | Tagged , | Leave a comment

The Fermi paradox… isn’t.

There is a common topic among people who like to think about the future and space travel: the Fermi paradox. Simply put, if you take even tiny-seeming growth rates for any civilization in the galaxy, it should be everywhere in the galaxy within a billion or so years. And there have been 14 billion years, so where are they?

The wiki page suggests quite a lot of possible explanations, many of them nonsense, unfortunately. But it’s worth questioning the very basic assumptions of the argument, rather than resorting to making up extra things to explain the problem away.

The paradox rests on a few foundations:

  1. Civilizations are at least relatively common.
  2. Civilizations survive.
  3. Civilizations expand.

There are several other totally non-essential assumptions that are sometimes made. For example, the whole bit about radio broadcasts in the wiki isn’t really relevant because radio won’t be detectable from background noise at any real distance. But it doesn’t matter, because given a bit more time, you’d expect them to simply be everywhere.

There are already ways to question the first two assumptions. Most of them somewhat implausible. Dystopian sci-fi is all the rage these days (possibly partly fueled by inaction on climate change), so blathering about civilizations destroying themselves is a popular. But I’m not such a pessimist. The sticking point is that even if most civilizations die off, well… the rest ought to be enough.

The trick of the paradox is that even if the numbers are tiny (1 civilization per million stars! 1 in ten thousand survive!), you multiply by a big number (times 300 billion stars = 30 civilizations), and you basically only need to get 2 for the paradox to work. There’s us, and there’s someone else, then given enough time, we ought to be everywhere.

But… I don’t see people question the last assumption enough. Why expand? Usually this is hand-waved away (if the expansion rate is only 0.00000001% per year! Wow so little!) but that’s not good enough. The number really could be indistinguishable from zero.

Here’s the UN population projections to 2100. If anything, I think these are optimistic, and they suggest a leveling off around 11 billion humans. This isn’t due to any sort of resource constraint. It’s entirely due to the birth rate falling off a cliff (in fact, going below replacement and we expect population to decline!) as soon as a population reaches a certain level of economic security and education (particularly for women.)

So, here’s a thought, if we top out at 11 billion humans, just what are we going to fill those 300 billion stars with?

There are of course some counter arguments. For example, what about AI? Or curing aging? But I think these too are dead ends. I’m not worried about AI, but that’s a topic for another post. As for curing aging… I predict it will lead to an even more severe drop-off in the birth rate. (You know the “ticking biological clock?” Yeah, why rush? Without that deadline hanging around…)

One can also object that maybe other species won’t be like humans in this respect, but… why assume otherwise? We don’t really have any reason to. I don’t think this objection is sufficient when we’re calling the problem a paradox. You don’t get paradoxes from unfounded assumptions. Just don’t make that assumption, problem solved.

Ultimately, I don’t think civilizations will expand beyond maybe a handful of nearby stars, and that’s iffy. (Depends on whether there are any real unpredictable existential threats that can hit a whole star system at once.) And the long term expansion rate will be determined only by the rate that stars die (the sun should be useful for another 8 billion years, even if the Earth isn’t. Why move before then?) Which means the growth rate is indistinguishable enough from 0 that the paradox is no more.

Posted in Futuring | Leave a comment

Programming is the new literacy

Chris Granger has a post ironically titled “Coding is not the new literacy.” It’s pretty good. Despite the early part where he attempts to redefine literacy in order to have a catchy title:

This is certainly accurate, but defining literacy as interpreting and making marks on a sheet of paper is grossly inadequate. […snip…] …composition and comprehension. And they are what literacy really is.

So if you ignore that bit, it goes back to, in effect, arguing that programming is the new literacy:

Reading and writing gave us external and distributable storage. Coding gives us external and distributable computation.

I think the probable source of his disconnect is that he’s working on Yet Another “hey, maybe people should program without actually programming, so let’s call it modeling and then make a gui to click on and,” and well, I don’t really need to know more, that’s going nowhere.

I’m definitely 100% on the side of programming being necessary to have any level of higher communication between human and computer beyond pointing and grunting. Language is the highest form of communication between humans and there’s no reason to believe this isn’t true between humans and computers as well.

The trouble for bringing programming to the masses isn’t that we’ve stubbornly insisted on writing code in a programming language as the way to do it. It’s that our languages, tools, platforms, and so forth are all basically crap. Programming is legit pretty stupid, and we have to put up with a lot of mistakes we can’t seem to actually fix. Mistakes piled on other mistakes, that require us to make still further mistakes.

Granger ends with referring to Alan Kay. Kay is someone I also agree with in the sense that he’s identified the right problem. Unfortunately, Kay is also someone I think proposes solutions (or at least, suggests directions in which to find solutions) that are… also quite incorrect.

Ultimately, I think this is the real issue. We don’t need prophets to tell us what the new One Correct way is. We need to be able to just fix our past mistakes. Just the ability to not be married to designs and ideas we invented 30 years ago, and realized were garbage 25 years ago, but still persist because we’re unable to change anything.

That’d be nice.

Posted in Programming | 1 Comment

More on Abstraction

Almost a year ago (evidently), I wrote briefly about Abstraction, Modularity, and Composition as important principles in designing software. I’ve had a few more thoughts to add about abstraction.

There are two sides to the abstraction “coin”: there’s (for lack of my knowing of any better terminology) pattern abstraction, and then there’s property abstraction. Each of these are simple enough to be illustrated with just the lambda calculus itself as an example.

What prompted me to write today was that I saw a claim that macro assemblers are really all-powerful and all these languages we’ve invented are “really” just macros piled on assemblers. This is, of course, bullocks.

This amounts, essentially, to the claim that the only abstraction that matters is pattern abstraction. Pattern abstraction is pretty much just taking commonly repeated patterns, and creating an abstraction with the varying parts as parameters. So, if we find ourselves iterating over lists of things often enough, we might go write:

apply f (h:t) = f h >> apply f t
apply f [] = return ()

And we’ve now abstracted away this iteration pattern, and we can now just write the function we want to run on each element of the list, and re-use the rest. Identify the pattern, and abstract it out.

Applying this to macro assemblers, and it amounts to the claim that class definitions and such from higher level languages only matter in the assembly code they cause to be emitted. The pattern is the only thing that matters.

But that’s not all there is to it. In particular, with our apply function. we’ve abstracted away an iteration pattern, but when can we use it? For such a tiny little two line thing, maybe this isn’t a big deal, we can just go read the code. But for bigger and bigger abstractions, “just read the code” isn’t good enough anymore. We could go read the documentation, but when we have more and more abstractions, “just read the docs” isn’t really good enough anymore either. Read what docs? Should we know everything about everything before we write any code?

We start to see the beginnings of property abstraction when we look at static types:

apply :: (a -> Action) -> [a] -> Action

(I’ve simplified this a lot, because I don’t want this to be about Haskell. Just read “Action” as a return type like “void” in C, where the point is to have side effects, not actually return something.)

Before, we could look at that pattern in a purely untyped way. We could pass anything into it, and the only way to know what would happen is to run it (or at least, simulate running it in your head.) But now we know some properties about the function, and about its parameters.

Abstractions always have an “outside” and an “inside” and both matter, and both have properties we’re interested in. An “abstraction” is not merely a repeated pattern like “apply”. It’s also something we’re holding abstract about which we know some properties, like “f” within apply. (And in some sense, “apply” for the rest of the program.)

My point of this isn’t that static types are great, or whatever. It’s that properties are great. The more we actually know about the stuff we’re working with, the less horrible programming is.

I think “property abstraction” is the main reason that, for example, Java has succeeded, while Lisp has languished. Everyone likes to make fun of Java, but despite its flaws, I do think it’s a good thing that, in Java, everyone knows it’s just plain not possible for an object to suddenly mutate what class it is. Lisp advocates go on about the “power” of being able to do something like that, but I think they’ve forgotten the “power” of knowing that sort of thing can’t happen to you. (Ditto Python vs CLOS, if you want an example without static types.)

Anyone who thinks languages are just macro assemblers is making the same mistakes. They’re looking only at the patterns, and not the properties.

Posted in Uncategorized | Leave a comment

Mere thoughts on a biological programming language

I occasionally get ideas that I don’t have the time or opportunity to pursue, so I thought I’d organize and write about one of them. Synthetic biology is an extremely interesting area, which might have caused me to take a different career path, if I’d been born a little later, or knew more about it when I was younger. A few years back, some clever people managed to create the first 100% synthetic genome (as in “we turned bits and nucleotides into DNA”), and inserted it into a cell and it thrived.

It’s interesting to think about what the end-game of this technology is. There are multitudes of problems solvable by designing novel organisms in a computer and synthesizing them, even with a relatively crude understanding of biochemistry. So there’s a question closer to my area: what would a programming language for organisms look like?

There are a few things we can answer with relative certainty. We can look at the question from three approaches: top-down, bottom-up, and black-box. What, about programming languages in general, can we say with reasonable certainty will apply to even a biological programming language? And how far can we go from what the result must be (DNA) backwards to what the language must be like? And regardless of what the programming language looks like, what properties must be true about it?

The language will be grounded in type theory. This might (to someone not familiar with PL theory) sound a bit unreasonable, since we still live in a world where most computer programming languages aren’t grounded in type theory, yet. But type theory is the fundamental theory of programming languages (and they’re hard at work extending that to logical and all of mathematics), so it’s not too controversial from that perspective. The only real reason our current language aren’t grounded in type theory is our current languages are a mess of historical accidents.

If this seems hard to imagine, the next probable property might help: the ambient monad for a biological language will be totally different from computer programming languages. (That is, different from languages for Von Neumann/Turing machines.) Most of our programming languages pervasively allow things like state, mutation, and IO. Even Haskell, with its reputation for being “pure,” pervasively permits non-termination of computations. A biological language will likely share none of these “ambient monads”, though I can make no guesses at the moment as to what ones we might find convenient to use. (I suppose there will be a sort of ambient state for the cell, but it will be different from how we typically think of state in current languages.)

If that’s still hard to believe, let me try it a different way: a type theory that permits no effects is really just another way of writing down data structures. Once you start wanting to describe a complicated enough data structure, you start wanting more and more abstraction, modularity, and composition features until you end up with a programming language. And that should (darn it) be grounded in type theory.

So next, bottom-up: the language must compile down to DNA. Of course. But we can also draw a nice line in the sand between regulatory genes and (I don’t know of a word for “non-regulatory gene” so I’ll call them) IO genes. I don’t know enough biology to know if “real” (i.e. evolved) organisms obey anything even remotely like a nice separation rule between these two kinds of genes (and evolution suggests it almost certainly does not), but it doesn’t matter. Just as a C compiler cannot generate all possible assembly programs, we can live with our bio language only generating genomes that are “well-behaved” in this way.

But this means that IO genes are the “foreign functions” of the language, and 100% of the purpose of our “program” is to generate the regulatory genes. We’ll almost certainly never write a program that somehow compiles down to the genes for constructing “chlorophyll a”. That’s too complicated. Too much chemistry, and the algorithms involved in figuring out a chemical structure like that are complex. (In the “complexity theory” sense.) You don’t want a compiler solving a problem like that, you want to solve it once and for all, study it carefully, and these re-use the result. Happily, this means evolution gives us tons of building blocks right from the start.

The regulatory side is perfectly reasonable, though. We can decide how we’re going to go about promoting and suppressing expression of IO genes, and then generate a set of regulatory genes that does this exactly according to the program. Again, we’re taking advantage of the fact that we don’t need to be able to reproduce all the different kinds of regulation that have evolved. We only need enough that we can regulate gene expression at all.

Foreign “IO” genes are what the name suggests: both inputs and outputs of the program. That is, some of these will be pure sensing: they detect something about the environment of the cell and cause a change in gene expression. Meanwhile, others will be pure output: they will cause something physical to happen only when they are expressed, but will cause no (direct) effects on gene expression. Others may be both. But this is not the only sensing that can go on: many functional parts of the cell (for example, stoma) will “sense” but purely within their own chemistry, and not directly controlled by gene expression.

The regulatory genes generated by the compiler will be intra-cell only. Probably. It’s possible to rely on “foreign IO” genes to accomplish communication with the environment, including other cells. And this is likely a good idea, because there are a lot of different ways cell can communicate, so it might be unwise to try to fix a few in stone and bake them into the language.

Metadata will be associated with all foreign genes. We’ll want to be able to simulate our programs in the machine, in order to debug and test them. To do that, we need to be able to abstract far away from the actual chemical machinery of the cell, because otherwise it is totally computationally infeasible. Even if inter-cell communication is part of the core of the language and thus does not need to be part of the metadata for foreign genes, we’ll still want to be able to run statistics on things like oxygen exchange, to make sure no cells will be starved and things like that. Since these are the result of the physical effects of expressed genes (i.e. the IO of the cell), we’ll need information on what those effects will be to simulate them without having to resort to simulating the chemistry.


So, finally, if it’s not obvious, I should note that I’m no biologist. This is just interesting. So with these few ideas in mind, the next question is: what’s the first step? If we designed a prototype language of this sort, we’d probably want to follow the work on synthetic genomes. Take the first synthetic genome, separate it into regulatory and “IO” genes as best we can, and then rewrite all the regulatory parts within the language, operating on the IO genes as “foreign functions”. Or at least, do so for a small part of it at first. (After all, a “trivial” program exactly reproducing the organism would consist of all the current genes as IO genes, and no program code at all. So we can start with parts and grow to the whole.)

Next, compile it, put it into a cell, and see if the new-but-not-really-different organism manages to survive. And behaves the same. This also happens to be basic science: you’d be verifying your understanding of the regulatory network’s behavior by creating a totally synthetic gene regulatory network.

And then, as the technology to synthesize genomes becomes easier, and the loop between “design genome -> test organism -> measure results” becomes tighter, the scientific opportunities start to explode.

Posted in Uncategorized | Tagged , | Leave a comment

Programmers as glue factories

Chris Granger has a wonderful post up “Toward a better programming” based on his Strange Loop talk. I’m in general agreement with most of it, and probably with anyone making serious attempts at trying to understand why programming is terrible.

Of course, there’s something about it I want to comment on:

Not once did I hear that programming is “solving problems.” Instead, I found out that it’s just clumping things together with half-dried glue and praying that it holds water long enough to replace it with a new clump of things. I heard over and over again that we’re plumbers and glue factories…


I mean, this is almost a success story, right? Ignore the metaphors that are framing this as a really bad thing for a moment. Wouldn’t we like it if most programming were about composing together small components to solve our larger problems? Would this not essentially be nirvana for programmers? If, for almost all the smaller problems we encountered, we could just use an existing solution, probably better designed, and fully debugged already? Would this not make us wizards?

It is, of course, not a success story, but I think that’s because:

  1. All our programming languages are terrible.
  2. All our standard libraries, libraries, and frameworks are terrible.
  3. All our tools are terrible.

And yet, despite all that, we’re actually sort of close. We have all those severe problems, and yet we’re still able to build systems by trying to compose together parts. It’s just painful and fragile (“teacups stacked on top of teacups”) instead of wonderful, and well… no wonder. Look at that list again.

If you haven’t clicked the link to read that post, please do. There are lots of good ideas there. But for the rest of this post, instead of talking about those, I want to elaborate a little more constructively about *why* I think all our languages (etc) are terrible.

Abstraction, Modularity, Composition

I think the history of programming languages, in the broadest possible terms, is the discovery of these three things as hugely important parts of programming. In fact, I believe we’ve discovered them in this order, over decades.

Abstraction goes back to the beginning of programming. The essential observation of the lambda calculus (and lisp, schemes, etc) was that abstraction was actually the bare minimum, sufficient to write any program.

Great abstractions are ones that hide away details that really don’t matter. Your task really does get easier using them. Good ones hide away details that usually don’t matter, but you aren’t tied to them in any way. If the details start mattering, just use a different abstraction, no problem. Poor abstractions hide details we care about, tie us down in using them, and give us no good way of dealing with it.

(For example, most of the historical arguments about garbage collection have been between people whose particular problem domains disagree on whether garbage collection is a great or poor abstraction. For most problem domains, it’s great. For some, it’s poor.)

Modularity as a principle wasn’t really developed or understood until the 80s. The basic idea is designing interfaces to isolate components of your program. This isn’t really about the module system of a programming language, instead it’s generally down at the level of types.  In object-oriented languages, that’s interfaces or classes, and involves principles like encapsulation.

By and large, the adoption of modularity as an important principle in software design coincided with the object-oriented movement. Unfortunately, this has meant that most languages in use today were based on the ad-hoc dogmas of that movement, and not the underlying principles. Many of them do not support modular development of programs very well at all, despite being considered “object-oriented.”

Composition is only just recently coming to be understood as an important principle. I’m not sure if there has ever been a good manifesto on this, or if instead it’s just sort of slowly congealing in the community’s collective minds. It’s making its way through to practice via mantras like “favor composition over inheritance” or the SOLID principles.

The lack of support for composition in languages like Java is the reason for the existence of things like Dependency Injection frameworks. These frameworks are little more than an elaborate song-and-dance routine that tries to enable composition by reducing it to a modularity problem. (And the frameworks I’ve seen only handle some parts of the problem, partially.)

The major advantage of composition is that it’s almost a cheat code for turning poor abstractions into good ones. If an abstraction hides a detail you care about, and that abstraction is composed together from smaller ones, then you can just break it apart, replace the part that doesn’t work for you, and re-compose it back together again and have a new great abstraction to use. (The state of the art for this, besides dependency injection, is inheritance, which is anti-modular and anti-composable. Elaborating on this might make a good post, later…)


I could go on, but I think this is sufficient to get my point across. Our programs are fragile glued together horrors because they’re built on poor abstractions. Abstractions that have to be poor because our languages lack support for modularity and especially composition, and often foist just plain no-excuses poor abstractions on us besides. (e.g. String in Haskell.)

If and when we start working in a world with languages that properly support these principles, and libraries that take advantage of them, will the woes of the world’s glue factories be solved? I don’t know for certain. For all I know, next decade we’ll have discovered all-important principle #4.

But I am very skeptical of any proposal to radically remake how programming is done. I think we have a very clear set of principles for building good software that our programming languages do not enable, our libraries do not follow, and our tools to not support. I’m not convinced the problem with programming is anything truly deeper than “well, let’s just do that already. Sheesh.”

Posted in Design laws | Tagged , , , , | 1 Comment

Advice on writing a programming language

Walter Bright, the guy behind the D language, wrote an article about writing your own programming language. If you’re interested in such things, I suggest reading it. It’s pretty good.

I want to disagree about one thing, though. And add a couple of points that I think are important.

Parsing is actually pretty important

There are a few things I (perhaps surprisingly) suggest should not be considerations… Easy parsing. It isn’t hard to write parsers with arbitrary lookahead. The looks of the language shouldn’t be compromised to save a few lines of code in the parser. Remember, you’ll spend a lot of time staring at the code. That comes first.

…Somewhat more controversial, I wouldn’t bother wasting time with lexer or parser generators… They’re a waste of time. Writing a lexer and parser is a tiny percentage of the job of writing a compiler.

This isn’t entirely bad advice, but I’m going to go with “mostly.” The lexer and parser generators we have are all pretty dismal, it’s true. We know how to do better, but no one’s just gone and done it. Probably partly because it’s an entirely thankless job. (“Here’s the perfect parser generator!” “great, now I’m not going to bother switching to it, see…”)

But this sentiment that parsing difficulty is unimportant and parsing formalisms should be tossed aside is entirely misplaced. As far as I can tell, it’s based on the belief that you just end up writing one parser.

But more than just your compiler needs to parse code. Just a smattering of tools that would want to parse the code for your language include:

  • IDE and text editor tooling
  • Documentation generators
  • REPLs
  • Code reformatters
  • Debuggers and profiling tools
  • Refactoring tools
  • Code highlighters, renderers for Latex and HTML
  • Lint tools
  • Static analysis tools
  • Alternative compiler implementations
  • Web toys wanting a Javascript parser, or apps that prefer a Java native parser, rather than a C library (or vice versa)
  • Even build and packaging tools

And more. Pretty much everything that might work with your code will benefit from being able to parse it. All of these tools will sprout up like weeds for a language that’s easy to parse and popular. (So, Java: Sure. C++: Nnnnope!) Anyone who has an idea can plop a grammar into a parser generator and hack together something that works well to do whatever, and gets improved from there.

If the language is hard to parse, then many of those people eager to contribute either get stuck trying and failing to build a parser or trying and failing to learn to use the daunting internals of your compiler. (Oh, and you did build your compiler as a library with a stable API, right?)

What’s strange is he seems to get it:

[They should have] Context-free grammars. What this really means is the code should be parsable without having to look things up in a symbol table. C++ is famously not a context-free grammar. A context-free grammar, besides making things a lot simpler, means that IDEs can do syntax highlighting without integrating most of a compiler front end. As a result, third-party tools become much more likely to exist.

I mean, right there, that’s what I’m saying. C++ needs an almost full-stack compiler just to parse the language, and if you go look at Clang, you’ll discover it’s got a ton of stuff integrated. Documentation generator, refactoring support, code completion support, and code formatter all integrated directly into the same repo as the full-stack compiler.

I’m not sure where the disconnect is here. C++ is especially bad in what’s necessary just to parse it, but from a tool builders perspective it’s not any worse. All the hardship is in having to link against a probably unstable and poorly documented API just to parse the language. What abominable things happen under the hood to accomplish this doesn’t make it better or worse as far as the library user is concerned.

And so, I disagree. Use an LR parser generator. It’ll keep your language parsable, and make it easier to change early on. When your language becomes popular enough that you have the problem of parsing errors not being friendly enough for your users, celebrate that fact and hand-roll only then.

And then reap the benefit of all the tooling an easily parsed language gets, since you know you kept it LR(1).

On language adoption

You’ll be doing what every nascent rock band does — play shopping malls, high school dances, dive bars, and so on, slowly building up an audience.

I think the trick to language adoption is simpler. Pick an initial application area, and focus on libraries.

People picked up Ruby because of Rails. People picked up PHP because it was designed to work with a webserver from the beginning and directly integrated things like mysql support. People are picking up Go because it has all the libraries you need to write back-end web services. People picked up Javascript because it was the only damned option that did what it did.

If you’re creating a language you think is great for webapps, build your rails equivalent. If you think it’s great for game development, make sure it’s got the right libraries like SDL, GL, or whatever libraries are used with phones these days.

And don’t just crappily expose these libraries and expect people to bite. This should be the selling point. You created this language presumably because you think it’s better. Show how. “Look at how you use SDL and GL in MySystemsAndGamesLang! Isn’t this so much better than what you’re used to?”

On marketing

One last parting shot that I couldn’t resist. When it does come time to promote this awesome language you’ve created, sell it on its own merits. Don’t disparage the competition.

If the first bits of marketing to reach most potential users is “attention C++ users: your language sucks,” … this might not work very well, even if true.

Posted in Uncategorized | Tagged , , | 4 Comments