Why Your Programming Language Is “Too Academic”

By Robert Fischer | Published: April 18, 2009

The Groovy/Grails Podcast guys asked me what it was like to have a foot in both the Rails and Grails communities, which has gotten me thinking for a while. One of the thoughts I had was about the “too academic” complaint that I hear bandied about so much: language/feature X is too academic, and therefore shouldn’t be studied/will never be adopted/is too hard for you so don’t bother/eats babies/whatever.

What’s interesting about this complaint is because it’s both totally wrong and completely right.

A lot of people who are fans of a “too academic” language chalk up the “too academic” claim to laziness (that’s “false laziness” for my Perl peeps). They assert that Intuitive Means Familiar, and the “too academic” claim is simply people whining about not putting the hard work in to learn a new language. This is a mistake: a more insidious criticism is at work, and language designers need to pay attention to it.

To see the problem, let’s take a brief foray into web application sites. One of the common things these sites have is a limited-capability free account — see the pricing plans of GitHub, Less Accounting, Remember the Milk (their “Pro” account), and ActionMethod as examples[1]. The thinking behind this “freemium” business model is simple: get people in and using the site, and then start to hit them up for money once they’re already engaged. By offering these free accounts, people can quickly go from being a non-user to a user of the site — potential users don’t have to cross the extra hurdle of deciding whether or not it’s worth money, getting out their credit card, etc.: they can shift from non-user to user by simply filling out the form.

[1] Notably, 37Signals products don’t have this, but that speaks more towards their marketing success than against the general principle.

Amazon, in a genius maneuver, goes one further. If you use a user-only feature of the site, you get prompted with a page like this:

In one fell swoop, just by entering the username/password you’d like, you can shift from non-user to user.

This ability to quickly shift from non-user to user is called gradual adoption, and it’s a key user interface concept. Basically, the idea is that it should be easy for someone to use the most common or useful aspects of your site without having to deal with too much hassle.

Now, let’s get back to programming languages. For even moderately experienced corporate programmers, there is a whole body of functionality which is taken as a “solved problem”. Working with these solutions make up most of the day-to-day work for the programmer-technician[2]. So, when said programmer encounters a new language, they come with the expectation that said things are solved. This is usually false, if simply because of the sheer amount of effort spent on building up technologies in their corporate language of choice. Still, most programmers interested in learning the language will push on, and many will even start to write their own versions — and that’s when their confronted with The Wall.

[2] More on programmer-technicians over at The Programmer is Dead; Long Live the Developer!, a post which has proven itself more and more accurate with the rise of CMSes (including WordPress), Rails, Grails, and other whole-stack solutions.

The Wall (in an entirely non-Pink Floyd sense) is this point in learning some programming languages where you suddenly are required to grok the entire language in order to use any of it. In some languages, it comes shortly after “Hello, World!”. And clever languages where developers slam, full-speed, into The Wall are the ones which are “too academic”. The basic complaint is twofold:

The functionality that I consider a given for day-to-day work doesn’t exist, and
Only the language designers and the most fervent evangelists are skilled enough to write the solution.

Notably, neither of these issues have anything to do with academia: it’s quite possible for a language to come out of industry which had the same qualities — in fact, many DSLs are fair prey for the same criticism. So, in that sense, the criticism is totally bogus. However, the underlying cause for complaint is fair, even if the way it is expressed isn’t.

If we look at languages which have really gotten a strong foot-hold, it’s easy to see that while each language provided profoundly new and impressive features, the language also provided a process of gradual adoption: it was easy for those already familiar in a dominant language to make the step into the next language. So Raganwald is right in saying that a major win for Ruby was Enumerable’s collect, select, detect, and inject methods — but Ruby also provides a plain ol’ shellish for loop. Java may be object-oriented, but it’s very easy to write procedural code in it (believe me, I’ve had to maintain my fair share of it). And so on up the chain.

It’s fitting that while I was writing this blog post, a post entitled “functional newbie, domain entites” was posted to Scala-User, and Brad Buchsbaum made the following astute statement in a follow-up:

Is there a missing chapter 34 in “Programming Scala”: How to port a tangled ball of mutable state — i.e. a reasonably sized java program — to beautiful “object-functional” scala code? Who is writing on this topic?

The usual gurus on this list talk avidly and feverishly about the niceties of the type system or whether “break” should be added to the language but when someone asks a mundane question about mutable objects and how to migrate such things from java to scala the answer is usually “well, there’s this pre-SIP that is going to make all of that a cinch”.

Dirk brings up the example of a complex graph of objects, where buried somewhere at the bottom of the hierarchy is a Point instance. What happens when Point.x changes? I’d like to add, what happens when Point.x changes and x is bound to a “spinner” GUI component that the user can view and manipulate? Indeed, often the entire object graph is mirrored at the UI level and this achieved by sprinkling listeners all over the place and monitoring for mutations. What is the scala-way to solve this basic problem?

This issue has come up in other ways on the Scala mailing lists: two very good conversations on this topic are at Scala: Great potential, but not ready for production and Scala, Scala you got me worried — the latter thread includes my particular criticism of Scala, which Martin Odersky addresses fairly directly, albeit insufficiently (IMHO).

In contrast, consider Groovy: the key sales pitch of Groovy is “quite literally Java, but without the pain”. Its superset-of-Java nature means that you can start with a Java file, change its suffix to “.groovy”, and build it with groovyc. This is an obvious win via gradual adoption. Gant is another good example — even ignoring ant2gant, its basic functionality mirrors Ant, right down to providing a transparent way to reference Ant Tasks.

The lesson for language designers and maintainers is simple: provide a gradual adoption route for people who know another programming language. Key among this is allowing a way to mimic functionality of popular languages, and providing an API which is accessible.

This entry was posted in Classic, Programming Language Punditry. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

http://jsmag.com/latest Michael Kimsal

Perhaps “too obscure” or “too narrow” rather than “too academic” might be a more apt phrase. Whether a language is “too narrow” would still be up for debate, but would take the notion of academia out of the equation. I looked in to erlang last year, and couldn’t really find a compelling use for it outside of some (what I considered to be) rather contrived and/or artificial examples. Nothing jumped out at me as being useful for my day to day work, and my somewhat limited imagination wasn’t able to make a connection to bridge the gap. I wouldn’t have said erlang was “too academic” though, just too weird for my every day use. :)
http://www.smokejumperit.com Robert Fischer

Remember that Erlang was invented to program an entire network of telecommunications nodes all at once. When you keep that in mind, it’s suddenly a lot more sensical.

Concurrency in the future won’t be actor-based: actors are a different and slightly less sucky way to do concurrency, but they’re still manually managing concurrency. Concurrency in the future will have to be automatic.
http://jsmag.com/latest Michael Kimsal

I was aware, and was going to bring it up. I couldn’t really shake that initial ‘phone system’ application out of my head, and therefore only ever thought of ‘phonish’ type apps whenever I was messing about with erlang. Initial impressions are hard to shake – some people still confuse Java and JavaScript (amazingly) in 2009, or associate Java with browser applets only (again, amazing for 2009).
DavidLG

Scala is the perfect example of a language that allows gradual adoption; that comes with all the constructs you need, plus some of the ones you might covet, depending on your proclivities; that is a superset of Java in every way. So some of its biggest advocates are Haskell-type people, so what?

Little of my Scala code is at all free of side effects, mutable state, and imperative constructs — ridding code of those things feels extremely forced in practice. But first-class functions, higher-order functions, and the multitude of niceties Scala provides over Java are a joy to use every day.
Martin Odersky

I fully agree with the need to enable gradual adoption. But I think you are choosing the wrong target with Scala. While Scala is certainly cutting edge, we took great pains to make gradual adoption easy.

Your example is a bit besides the point: How to move a big tangled mess of stateful objects to functional programming? Well, if it’s too hard, you probably should not do it. No reason not to use Scala, it deals perfectly well with such objects.

Your “too academic” claim is already proved wrong by the facts. Scala is in active use at companies like Twitter, Ebay, Sony, Xerox, SAP, LinkedIn, OfficeDepot, EDF, Siemens, and many others more. Several of these companies base business critical core components or even entire infrastructure layers on Scala.

The discussions you linked to are also becoming outdated. Yes, the Eclipse 2.7.3 IDE was a bit immature, but it has made important improvements since, which are consolidated in the 2.7.4 version. We are not done yet, but we are working hard on it. There are also the IntelliJ and Netbeans IDE’s which are pretty robust.

My observation is that a lot of the “too academic” perception is cultural, not technical. If your language is cutting edge, there will be some users who relish in being on that edge. They will mail or blog about their super-clever solutions, which then tends to scare newcomers away. The only way to avoid this phenomenon is to dumb down your language so that it is no longer interesting for this class of power users. Speaking personally, that’s not something I want to do.
Jason Dusek

I think Martin Odersky’s email highlights an unfairness in your criticism. He says: “I do realize that it takes a lot of effort to wrap your head around variance, polymorphism, and so on…”

If a language is fundamentally different, it’s pretty tough to hide that. Was C++ successful in making OO approachable for C programmers? Sort of. Was it a good long-term solution vis-a-vis Java? No.

To really enjoy the benefits of OO in C++, you have to learn OO. If you’re not going to get the special sauce, why go out of your way at all? Just use C. The same thing goes for advanced types in languages like Scala. Scala has gone way, way out of it’s way to be accommodating to Java folks — it’s syntactically far closer to C than to ISWIM. You can even use Java with it — there’s your bridge. How expensive do we want to make it for language designers to bring us the good stuff? How little are we willing to pay to enjoy new functionality?
http://www.smokejumperit.com Robert Fischer

@Jason

People adopt languages for reasons other than the ability to use the language’s most advanced feature. (See my response to Martin below.)

@Martin

I think Scala’s success has more to do with FP’s inevitable dominance of the market, and Scala’s unique position as the most accessible FP language for the Java developer. The “too academic” claim is still a valid one — it’s just being overcome by fiat in those companies, probably driven by some initial champion. At the point when their boss mandates Scala, people will learn the language thoroughly, at which point they’re on the other side of the wall.

As far as cutting-edge inevitably bringing the “too academic” claim — that’s demonstrably false. Perl and Ruby both have profoundly innovative capabilities relative to their predecessors (Perl’s anonymous subroutines, Ruby’s meta-programming capabilities), and they have all kinds of esoteric experts-only cleverness, but nobody’s slapped the “too academic” claim on them.
Martin Odersky

Your reponse made me laugh.

That’s news to me that Scala is mandated by bosses against the wills of their programmers. Maybe it would be kind of convenient if it were, but that would take a miracle.

Then you say nobody slaps the “too adademic” claim on Perl or Ruby. Well, it’s interesting to note who slaps this claim on Scala. Your blog is just one in a long list of attacks of stakeholders of dynamically typed languages. Makes you wonder why they all pick on Scala, and not some other statically typed language like Haskell, OCaml, C#…
Isaac Gouy

@Robert Fischer

“both have profoundly innovative capabilities relative to their predecessors (Perl’s anonymous subroutines, Ruby’s meta-programming capabilities”

Perhaps it depends what you mean by “their predecessors”

Seems like Tcl (Smalltalk, Lisp, …) has anonymous functions

http://tmml.sourceforge.net/doc/tcl/apply.html

Are Ruby’s meta-programming capabilities innovative compared to Smalltalk or Lisp or …?
Brian

As anyone who has watched House, or any other medical-procedural, knows the complaint the person has and the real problem the person has might not be all that closely related. when the patient, er, programmer says “Your language is too academic”, I think what they really mean is that “your language is too hard to learn”.

They’re right and they’re wrong. Learning a language in a new paradigm is much, much harder than learning a new language in a familiar paradigm, because you’re learning not only a new language, but also a new way of thinking about problems. This is my definition of a paradigm. But I’ve ranted on this subject more than once before.

I will comment that adoption of new paradigms does seem to happen in stages. Back when we switched from procedural to OO, there was a whole host of “intermediate” or “dual-paradigm” languages- not just C++, but Objective C, Object Pascal, and a host of others. These languages were the epitome of “gradual adoption” languages, generally containing a popular procedural language as a major or even proper subset. “Pure OO” languages, like Small Talk, were derided as “too academic” or “too hard” or “not relevant to my day to day programming”. Of course, Object Pascal and C++ gradually gave way to Java, which was much more “proper OO” (including such concepts as garbage collection and virtual machine execution), but which kept the look and feel of C++ as a fig leaf of “gradual adoption”. And now Java is starting to give way to languages like Ruby and Python, which don’t even look like C anymore.

Note that polyglot programming is also a common feature of the early adoption stages of a new paradigm. One of the big advantages of C++ was the ability to use older C and FORTRAN libraries, and that you could drop back to C or FORTRAN (especially C) to “get work done”.

When adopting a new language, I tend to think about it in terms of where that language falls on the “adoption curve”. This isn’t to say that falling in some places is better or worse than others- for a paradigm to be adopted, pretty much every point in the adoption curve needs to be filled by some language. So the languages like F# and Scala and Cornerstone are definitely early adoption curve languages. This isn’t bad, in fact this is absolutely necessary. Also, Haskell is definitely the Smalltalk of procedural languages- probably not destined to ever have large-scale adoption itself, but it’ll be the source of much of the “culture”.
Brian

Martin: I don’t think Scala is being forced on the programmers, yet… I could easily see it happening in 3-5 years, much like managers started enforcing the use of C++ instead of C.

DavidLG: I strongly recommend picking up a copy of Chris Okasaki’s “Purely Functional Data Structures”. Strongly, strongly recommend. One of the problems functional languages have is that a lot of “classic” data structures, like mutable doubly linked lists and hash tables, don’t translate well at all. It’s much more natural to use other data structures.
http://www.smokejumperit.com Robert Fischer

@Martin

I didn’t say it was “against the will of the programmers”: that’s a straw man. My point is simply that there was an impetus to get over the wall which overcame the “too academic” issue — someone with enough clout decided this piece of infrastructure was going to be Scala, and so the business adopted it, and so the programmers have additional drive to learn it.

(Interestingly, while peeking around for Haskell corporate adoption, I bumped into http://sequence.complete.org/node/127” rel=”nofollow”>this post with an interesting quote:

The impression of Haskell will not change with another book with practical examples. It will only change when Haskell has huge corporate-ready libraries for every huge corporate issue: when Haskell has a CPAN locked and loaded and ready to go.

Now, the author’s name is “metaperl”, so that commentary should be taken with a grain of salt, but there you go.)

I’m not saying Scala won’t have adoption. I’m not saying the wall is insurmountable. I’m just trying to help people understand what I’ve discovered in digging into the “too academic” complaint.

@Brian

Yeah, I think Haskell is the Velvet Underground of languages.
Sean

@Robert Fischer and Martin:

Can you name a dynamically typed language that is “too academic”? I can’t. That’s why I think you’re missing the key here: static typing is hard to understand. By “hard” I mean it requires a significant learning event and some effort to fully internalize. Having learned it, static type reasoning is not terribly difficult to apply, but learning it is a significant barrier to adoption. For those with no background or experience in formal logic (e.g. if A -> B and B -> C then A -> C), it might be especially difficult. We forget sometimes that this sort of thing doesn’t come naturally to everyone, including professional programmers (most of whom have learned it intuitively through experience, but not all).

The reason dynamic languages don’t get this label is that humans naturally understand “duck typing” because it is what we do with real, physical objects every day. When we get a type error in Python, we understand it (almost) immediately, and we blame ourselves. When we get a 30-line error from Haskell which is thoroughly confusing, we dismiss the language as “too academic”, and find all sorts of other problems with the language or implementation to blame for its inferiority. Admitting to ourselves that the language is powerful makes us feel stupid when we don’t “get it”, and faced with that, most of us will do anything to avoid it.

I believe a solution exists that allows for gradual mental adoption of a statically typed language, but I have never seen a real attempt made by any language implementation. I look forward to some language implementer solving this problem well enough that we can have a mainstream statically typed language.
http://www.smokejumperit.com Robert Fischer
@Sean

Clojure. Dynamically typed lisps in general. Cecil.

Although I agree with what you’re getting at: it’s the upshot of my criticism on the Scala mailing list that I cited above. These type signatures — all from standard, familiar places in the Scala API — are just not very accessible:
def reduceLeft[B >: A](op : (B, A) => B) : B def orElse[A1 <: A, B1 >: B](that : PartialFunction[A1, B1]) : PartialFunction[A1, B1] def acceptSeq[ES](es : ES)(implicit view$2 : (ES) => Iterable[Elem]) : Parser[List[Elem]] case class ~[+a, +b](val _1 : a, val _2 : b) extends Product
http://www.smokejumperit.com Robert Fischer

@Sean

BTW, note that duck typing and static typing can get along just fine. I’ve got an example of OCaml’s duck typing over at 7 Actually Useful Things You Didn’t Know Static Typing Could Do: An Introduction for the Dynamic Language Enthusiast.
Brian

I’d include Smalltalk in the set of dynamically typed languages that are “too academic”, or at least they were in their time. I’d toss in scheme as well, except that qualifies as a “dynamically typed lisp”. Also probably prolog qualifies as well.

On the other hand, coming at it from an Ocaml/Haskell background, I’m not having a real hard time picking up Lisp/Clojure. The “way you think about problems” is very similar. It’s not the static typing that’s the problem, it’s that you need to think about problems differently.
Brian

Robert: you’re treading close to the logic that languages only become popular after they become popular. When will language X become popular? When it has the large, corporate-ready libraries written. When will the large, corporate-ready libraries be written? After the language becomes popular! You’re not there yet, granted, but this is where that line of reasoning leads.

One of the reasons polyglot programming/hybrid languages have an advantage, at least early on in the adoption trend, is two fold- one, because they can use the already-established, corporate-ready libraries written for the previous generation of languages, and two, because you can limit the use of the new language to those parts of the code base that get a lot of “bang for the buck”. So, for example, if today you were doing a mixed Java/Scala project that needed fifty programmers, you wouldn’t need all 50 to know Scala. Limit the Scala portion to just that part which is most advantageous to being in Scala, and you might only need 2-3 Scala programmers, and everyone else can be pure Java.

Of course, as knowledge of and comfort with the new paradigm grows, the cost of maintaining the legacy interfaces grows, as does the advantage of rewriting things in a pure instance of the new paradigm.
http://www.smokejumperit.com Robert Fischer
@Brian

There’s a difference between a language being able to mimic a previous language, and a language being a previous language. There’s also a difference between a language being “too academic” and “not popular” — although popularity tends to solve the “missing libraries” problem, which solves the underlying complaint.

Consider the following OCaml code, for instance:
let x = 1 in let y = x + 2 in print_int y;;
That’s certainly mimicking the imperative approach, but that doesn’t mean OCaml is an imperative language. The ocurl library (which I contributed to) is a profoundly OO structure, but that doesn’t make OCaml a rehash of Java.

The argument I’m making is that language designers should consider how steep they’re making the on-ramp for new developers, and that when they hear “too academic”, it’s really people complaining about the steepness of that on-ramp. Chalking that complaint up to laziness is not helpful for anyone.
http://www.smokejumperit.com Robert Fischer

@Sean

Oh, and Factor.
Tracy

Robert, I suspect I still don’t see the point you’re trying to make. It looks like you’re advising language designers to make ease-of-learning a high priority. Only rarely is this important to the problems the designer has in mind. (Basic and Logo are examples.) Often this priority would conflict with the main goals. Maybe it would help if I knew who your target audience is.

http://www.smokejumperit.com Robert Fischer
@Tracy

My point was only to explore what it meant when someone said something was “too academic”, and what might be learned from that criticism. My target audience was programming language designers/maintainers (primarily) and people who complain about languages being “too academic” (secondarily). The secondary target audience is mainly so that people stop using the phrase “too academic”, although I don’t have anything quite as succinct to offer in its place (hence the quotes).

Based on your comment, here are a few points I think you’ve missed. Let me know how I might clarify them.
1. It’s a fair and legitimate choice for a programming language designer to intentionally design a “too academic” language — such maneuvers are how the boundaries of programming languages grow. But such languages tend to not really be surprised/phased by the “too academic” complaint.
2. The point is not that a language should be easy to pick up for the completely uninitiated — that’s the purpose of Logo and Basic. The point is that languages need to be sensitive to the point when gradual adoption from stops for their target audience — how far into the language can you get before you need to learn the intricacies and details of the language in order to continue being productive?

http://jsmag.com/latest Michael Kimsal

If you do unit testing in Logo, do you get to use a mock turtle?
Tracy

> The secondary target audience is mainly so that people stop using
> the phrase “too academic”, although I don’t have anything quite as
> succinct to offer in its place (hence the quotes).

There are several succinct equivalents. “Too weird.” “Too difficult.” “Too powerful.”
http://www.angelfire.com/tx4/cus Chris Rathman

@Sean

Can you name a dynamically typed language that is “too academic”? I can’t.

Too too easy – Oz – which happens to be my favorite programming language.
http://www.smokejumperit.com Robert Fischer

@Tracy

Re-read my post. As I describe there, at least difficulty and power aren’t related to the “too academic” claim, except insofar as those features mandate the elimination of more accessible features.
Brian
@Robert: I don’t think I said “Programmers are lazy”, at least not in this post. And that wasn’t what I meant. If you learn to swim in the shallow end of the pool, instead of the ocean, does that mean you’re lazy? Or is that just common sense?

Frankly, I have immense respect for those people who go directly from Java to Haskell and make it. I don’t think I could have made that on-ramp.

And by the way, Ocaml does support a lot of the imperative programming techniques, for example:
let sum = ref 0 in for i = 1 to 100 do sum <- !sum + 1 done; Printf.printf "Sum is %d\n" !sum
This is exactly my point. Even I traveled that curve in multiple steps- starting with using Ocaml in a very imperative/procedural way, and then moving to a more functional style as I became familiar with the style and comfortable with the idioms, and even then only really grokking Haskell with the advent of Real world Haskell. I think RWH is a great book, but moving directly from Java to Haskell is going to suck no matter how many books you read. Spend some time in Scala or F# or Ocaml first.

The main advantage F# and Scala have over Ocaml is access to the C# and Java (respectively) code bases. Other than this, Ocaml is a classic intermediate language.

But note, another term for “accessible features” is “training wheels”. The fact that Ocaml has imperative aspects, especially for I/O and mutation, means it doesn’t push the field forward. If you already know F# or Scala, there’s less advantage to learning Ocaml- but there is still a great advantage to learning Haskell. Because of laziness and purity, Haskell forced it’s programmers to solve the basic problems, and push the state of the art forward. If you want to know the language we’ll be using in 3-5 years, learn F# or Scala. If you want to know what language we’ll be using in 15-20, learn Haskell.

http://allele.tk/ Chris Wong

Yes, OCaml is an excellent language just to get your feet wet. Has anyone written a beginner-level OCaml tutorial yet?

hugh wish

Programmers tend to all look at this problem from the same point of view.

Any investment in a language unless your task is building a language is a distraction from the task at hand. I call it a UI drag coefficient.
Think of your programming environment as a big word processor.
Just the same way a word processor that forces you to use up all your time fighting with the features of the word processor is a distraction from what you are trying to write, programming environments all distract from the task at hand.
What’s more important a writer turning out a great novel or a well crafted word processing document? Programmers are concentrating on the well crafted document which is the wrong problem. As long as you ask the wrong question the answer is always wrong.

Smalltalk was an attempt to start to cut through all this but is only a first step and was abandoned.

The most damning indictment of programming environments is that fact that with all the tools available the most used software design tool is still a pencil and a piece of paper.

That’s why all programming environments are doomed and why I for one won’t miss them.
Tracy

Robert,

I’ve re-read your post a couple times. It’s interesting to hear that Groovy has been more successful than Scala at being adopted, and I hear you to account for the difference by saying that Groovy has facilitated a more gradual adoption route.

Yes, I’m partial to the “Intuitive Means Familiar” idea. It’s not that I think people who fend off so-called “academic” languages are lazy, though. I think each person works from their own cost-benefit analysis, and (like Brian) I think that the estimates of high difficulty tend to be what put people off.

I agree that it would be better if “academic” were not the term used as shorthand. It’s inaccurate and counterproductive.

I also agree that when a language “pushes the envelope” it should not be a surprise when it does not sweep the industry as the new big thing.

What I remain dubious about is the ability to “be sensitive” about the limits to gradual adoption. Are you talking about actual changes to languages, or are you talking about improvements to identifying and communicating ways to help build skill in the (unaltered) languages?
http://www.smokejumperit.com Robert Fischer

@Tracy

In saying we should be sensitive to the limits of gradual adoption, I’m talking about building hand-holding into language infrastructure based on the assumption that someone knows a mainstream language but is learning yours. Useful compiler/runtime error messages, an accessible API, and, yes, even some language features to mimic dominant paradigms[1] are all ways to do that.

[1] See Brian’s OCaml example above — I couldn’t remember the for loop syntax when I wrote my comment.
Pingback: Helltime for April 20 « I Built His Cage
Pingback: Hydrocon Session Log, 1241655767 « I Built His Cage
Graeme Defty

I was interested that the idea of “too academic” seemed hard to pin down. Intuitively I feel I know what it means (to me anyway) but would also have a tough time describing it. “too wierd” doesn’t really help. “too hard” is part of it, but it feels more like a symptom than a cause. “too powerful” certainly doesn’t do it.

Is it just that the language is too far in language-space from what you are familiar with? That there are too many new paradigms involved for comfort? That may be why the ability to “write COBOL” in your new language is such a soother. It lets you play in the language and learn the new idioms as you do so.

I still don’t have a decent replacement for “too academic” though :-(

One other thought (which could help prove or disprove the above) is that it would be interesting to hear from someone who learned programming with a functional language about their experiences moving to Java for the first time (“What do you mean, I have to tell it what to do?!”) I suspect that the dificulty would be vastly reduced because that form of imperative instruction is how we tend to deal with each other. Instructions stating how to make a cup of tea are much more likely to look like C than Haskell (well, maybe not C, but you get the point ;-) )

Search
Categories
RSS Links
- All posts
- All comments

Why Your Programming Language Is “Too Academic”

Authors

Recent Posts

All-Time Popular Posts

Search

Categories

RSS Links