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.
And throw in some less obvious ones.
And some controversial ones.
Add your own! Point out more violations! Its fun!
Re:static typing
schwern on 2005-04-09T01:22:47
Could you give an example of a language which avoids this regret?Re:static typing
ziggy on 2005-04-09T02:25:47
Haskell's static typing does pretty good inferencing.That is, the function$ ghci
Prelude> let sq x = x * x
Prelude>:type sq
sq:: forall a. (Num a) => a -> a sqis defined for all valuesa, such thatais an instance of the type classNum. 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 ofNum.This is a contrived example, but it does demonstrate type inference. That is, it avoids the Java problem where a function like
sqneeds to be redefined for every numeric type you want to square (primitive numbers and user defined numeric types). All with a single definition.Re:static typing
mary.poppins on 2005-04-09T02:43:41
Statically typed type-inferring languages include ML variants (SML and OCaml being the most common), as well as Haskell and Clean.
All of these have entries posted at the shootout.
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.
Re:Perl 4 had namespaces
schwern on 2005-04-09T01:20:37
Oh yeah. When did "package" get added?
printf is just soooo lame)Here's a simplistic translation in Tcl. Procs aren't first class, but you can create new procs dynamically. This code is broken, because Tcl has lexical variables, but no closures:sub make_adder ($) {
my $i = shift;
return sub {
return shift() + $i;
}
}
$add1 = make_adder (1);
print $add1->(2); ## 3
But you can work around that problem fairly easily with interpolation:proc make_adder {procname value} {
proc $procname {n} {
return [expr {$n + $value}]
}
}
make_adder add1 1
add1 2 ## can't read "value": no such variable
It'd be a lot better if you could make an accumulator (i.e., true closures), but even without, you can still get a decent boost in power with dynamic code generation.proc make_adder {procname value} {
proc $procname {n} "return \[expr {\$n + $value}\]"
}
make_adder add1 1
add1 2
I'm still on the fence whether or not you absolutely need macros. If you can construct classes, methods, and closures at runtime, you can fake it pretty well. And you can even work around the lack of closures if you absolutely must. But without all three of these features, you might as well be programming in C.
(Yeah, [expr is an wart in Tcl, but them's the breaks.)
Re:Dynamic Features
schwern on 2005-04-09T23:06:52
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.
Re:Dynamic Features
ziggy on 2005-04-10T19:36:10
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 nothing else -- selecting symlinks, directories, writable files, whatnot is all your responsibility to handle in a callback.
You can punt with eval if you don't have closures, but that's like using two liters of grain alcohol instead of a shot of novocaine before doing minor dental surgery. Eval and interpolation turn that grain alcohol into something more palatable, like Irish Whiskey, but it's still fundementally the wrong solution.
Limping along with pre-processors and static code generators is still a bad problem. You might as well be programming in C at that point. That strategy recognizes the need for code that writes code, but ignores the fact that you really need to be alble to do that at runtime (like, when you need to construct a callback to File::Find, and maybe something with persistent state to select the first ten results).
Re:Dynamic Features
schwern on 2005-04-10T21:45:05
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 classes, dunno.
Re:Dynamic Features
ziggy on 2005-04-10T23:58:25
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 (like Python's hackish way of using anonymous objects with a __getattr__ method).
I think you're focusing on the impact rather than on the language feature. Yet you started with a list of language features.
From what I've seen elsewhere, wiggling around the problem of closures by making the moral equivalent of a closure available is just as much of a problem. Even Smalltalk has closures, even though they call them "anonymous blocks". Whatever you call them, they're pretty much a requirement today.
Re:Dynamic Features
ziggy on 2005-04-12T18:26:47
Re-reading your comment, this stands out: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?)Maybe there is a way to do it efficiently and concisely with anonymous classes, dunno.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!
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
Re:Perl 6
schwern on 2005-04-09T21:18:23
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.Doesn't Perl 6 make this mistake, too? (I'm thinking of the int Type)Surprise! And people wonder why they should learn Smalltalk. If more folks learned Smalltalk instead of C++ in the early 90s I think object-oriented programming would be a whole lot farther along now. Fortunately, Matz did learn Smalltalk and thus we have Ruby.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
<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).
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.