Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

schwern
  (email not shown publicly)
http://schwern.net/
AOL IM: MichaelSchwern (Add Buddy, Send Message)
Jabber: schwern@gmail.com
Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Friday April 08, 2005
06:04 PM

Early Decisions All Language Designers Will Regret

[ #24082 ]

I recently have to touch Javascript and am horrified at the lack of a require/include function. Now I find out it doesn't have namespaces either.

FOR FUCK'S SAKE PEOPLE! Did these guys all sleep through the last 30 years of language design? If I had to enumerate the most important programming innovations in the last three decades namespaces and include would be near the top of the list. This isn't something "fancy" like OO, these are the basics of MODULAR DESIGN: the thing which separates spagetti code from real code.

Javascript isn't the only one to have made this mistake, not having namespaces. Lua comes to mind as well as earlier versions of Perl and PHP. Perl regretted it. PHP is still regreting it as they struggle with their new namespaces. Every C programmer which writes a header file regrets it. Lua is just now starting to regret it as they hack further and further around the limitation.

So maybe its not so obvious. Maybe we need a list. A list of early decisions which all language designers will eventually regret. And take it from the Perl programmers... we know. Oh god we know.

I'll start with the obvious ones. I'm no cross-language expert so my examples may be out of date or just plain wrong.

  • No namespaces. (C, Lua, Javascript, early PHP, Perl 4)
  • No way to include a file. (Javascript, very early C)
  • No lexical scope. (PHP still screws this up I think)

And throw in some less obvious ones.

  • No anonymous functions. (Java and to a certain extent Python)
  • Everything's an object... except for the built in data types. (Java, Perl 5)
  • Treating IO as unimportant or no IO at all (C, Java, Javascript)

And some controversial ones.

  • Not requiring variable declarations. (Perl 5)

Add your own! Point out more violations! Its fun!


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Early Decisions All Language Designers Will Regret 20 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Here's another controversial one:

        Static typing without type inference

    If you're going to make a new language, please make a type-inferring version of C. kthxbye
    • Could you give an example of a language which avoids this regret?
      • Haskell's static typing does pretty good inferencing.

        $ ghci
        Prelude> let sq x = x * x
        Prelude> :type sq
        sq :: forall a. (Num a) => a -> a

        That is, the function sq is defined for all values a, such that a is an instance of the type class Num. Remember, Haskell is strongly typed, and this function is defined on all kinds of numbers (machine integers, bignums, floats, doubles, complex, etc.). Furthermore, it will be defined on all types you define that are also instances of Num.

        This is a contrive

      • Statically typed type-inferring languages include ML [wikipedia.org] variants (SML [wikipedia.org] and OCaml [wikipedia.org] being the most common), as well as Haskell [wikipedia.org] and Clean [wikipedia.org].

        All of these have entries posted at the shootout [debian.org].

        None of these languages are suitable for low-level programming (kernels, databases, etc.), which is why we need a type-inferring version of something more like C.
  • Perl 4 had packages, which allowed pudge to write the D'oh module. :)
  • You missed three key features:
    • No Closures (Tcl messes this up; I think Python does too...)
    • No eval (C, C++, Java; makes it much harder to do macros and code generation...)
    • No variable interpolation (printf is just soooo lame)

    Now, with interpolation and eval, you can fake closures, but it's a royal PITA. Here's the classic make_adder example in Perl:

    sub make_adder ($) {
         my $i = shift;
         return sub {
             return shift() + $i;
       

    • I think much of that can be summed up as "allow dynamic code generation" and "have code with some data attached". And to be able to do these things easily. Java, for example, limps along using pre-processors (IDEs, AspectJ, ...) for the former and anonymous classes for the latter.
      • Respectfully, no it's not. You really do need closures. Hey, it's 21st century -- get with the program! ;-)

        Reducing this down to "allow dynamic code generation" and "attach data to code" is a false economy in specification. Once you have true closures (which imply lexical scoping), a whole new way to code is opened up for you. Instead of writing ridiculously long classes to, say, find files, you can have small simple classes that are responsible for the algorithmic structure of finding files and nothi

        • I think we're having a violent agreement.

          By changing the wording from "have closures" to "easily attach data to code" (with the implied "at runtime") I was attempting to restate the problem as a problem rather than as a solution. Closures are a solution to the problem and you've layed out the problem quite well. I would rather not assume that closures are the only way to do it. Or eval. Or pluggable functions (*foo = \&bar). Maybe there is a way to do it efficiently and concisely with anonymous cl
          • Hm.

            As you stated the problem above, there are some design decisions that are fundementally wrong in language design today. Like no namespaces, no way to include files, etc.

            "No Closures" is as big a design flaw as "no anonymous functions", "no eval" and "no interpolation". You can find all sorts of ways around that problem, but fundementally, there's no good reason to not have closures. Rephrasing that, there's no defensible reason for asking your users to jump through hoops to achieve the same result

          • Re-reading your comment, this stands out:

            Maybe there is a way to do it efficiently and concisely with anonymous classes, dunno.

            Anonymous classes are a form of closure. It's how Java fakes closures in particular, and it's a cleaner solution for some problems. (You could define anon classes with dynamic scoping rules a la Tcl, but why?)

            The issues are very closely related, but not identical.

            If you say no to closures and yes to anon classes, you're really saying no jam! and more orange marmalade!

  • No user-defined functions -- ColdFusion, until version 5, I think. That's clearly more than enough to disqualify it as a real language,
  • I don't know... when I think about how to use functionality from several different pieces of code in C, I don't think of "include"; I think of a linker. Including another C source file in another strikes me as a bit odd.

    Though perhaps thinking static inclusion is not quite the same - Turbo Pascal had "uses foo, bar baz;" lines which were directives to the "linker" IIRC (though there was no stand-alone linker, I think; it was a compiler-and-linker all in one, so you couldn't link TP code to, say, C code, th
    --

    -- 
    Esli epei eto cumprenan, shris soa Sfaha.
    Aettot ibrec epesecoth, spakhea scrifeteis.

  • Everything's an object... except for the built in data types. (Java, Perl 5)

    Doesn't Perl 6 make this mistake, too? (I'm thinking of the int Type)

    I'm re-reading the Smalltalk 80 book (last time I read it was about 10 years ago). Its really amazing how much they were ahead in 1980 compared to the state of most languages in 2005

    • Doesn't Perl 6 make this mistake, too? (I'm thinking of the int Type)

      Don't think so. I sure hope not. AFAIK Parrot doesn't make that assumption so there's no implementation reason why Perl 6 would.

      I'm re-reading the Smalltalk 80 book (last time I read it was about 10 years ago). Its really amazing how much they were ahead in 1980 compared to the state of most languages in 2005

      Surprise! And people wonder why they should learn Smalltalk. If more folks learned Smalltalk instead of C++ in the early 90s

  • You can do namespaces in Javascript [netalive.org]. And there is no include in the language, because <script src="..."> does that for you. Javascript is actually a pretty nice language. I far prefer writing JS over PHP, even over Python (though not as decidedly).
  • I decided to play a bit with iframes for emulating JavaScript includes and namespaces, as you can see in my journal [perl.org].

  • Anyone who's ever tried to do anything nearly useful with XSLT must have hit the same wall (no pun).

    The very least you'd expect in a language is taking a substring at fixed position, and locating and optionally replacing a substring. But just how many C programs that do some form of string processing do you know that do not link against some regex library? Right.

  • So Michael... Read a lot of your comments today on js, including the thread about 'include'. Are programmers literal-minded or what? I've recently discovered javascript, and I am so charmed by its elegance as a language. I'm an old Lisp fan, but a long-time C/C++ programmer, so... I'm writing a javascript-to-C++ translator. For fun, and as a way to understand javascript. The idea is to use the local C++ compiler as a backend, link to a JS runtime, and be able to get a native .exe (on Windows), so I can
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.