Paul Graham on great hackers

There are some efforts ongoing to try and fix the tcl/tk problem. Take a
look at http://tktable.sourceforge.net/tile/ and see if you like that
better. It ought to breath some life into tcl/tk as a toolkit.

We use tcl/tk at BitMover (and we're actively looking for more developers
who are local to the SF Bay Area, hint, hint) and we're looking at ways of
evolving the tcl language to make it more approachable to the average
programmer. We're looking at adding per object (command) anonymous
arrays (i.e., every object has an $widget array get foo and we'd like to
add a -> operator so you can do $widget->foo to mean $widget array get foo).
Other ideas include C style scoping rules so you can do

scope {
proc I_am_a_global proc {
}

private proc I_am_visiable_only_in_this_scope {
}
}

perl style regular expression so you can do

if ($var =~ /*.o$/) {
}

$var =~ s/junk/JUNK/

and we're wrestling with some sort of reasonable string/list indexing
that is shorter than

set elem [list index $list 5]

If we can fix the parser to support this I'd love to be able to do

set elem $list[5]

(we've toyed with $list<5> which would be easier to implement but looks
pretty weird).

Anyway, tcl/tk isn't dead and we're working hard on making sure that it isn't. If you are interested in this sort of thing send me mail, I'm lm <at> bitmover.com.

One of Microsoft's insights was that since software has no marginal reproduction cost, if you can charge a per-unit price you can make a lot of money. One of Open source's insights is that since the marginal cost is zero, a free market tends to drive the price down to zero, and it's good to look for other models than charging per copy.

Microsoft absolutely and definitely came to their fortune by luck. Granted, it wasn't *just* luck--they've proven time and again that they know how to take great advantage of just about any situation--but nonetheless the fact that certain opportunities were even available at all is nothing short of mind-boggling.

Read http://www.vcnet.com/bms/features/serendipities.html for info about just how lucky they were. (Note that I don't see the last five points in that web page as being as big as they make them out to be, even though they still are important. But point one all by itself is enough to understand that Microsoft effectively won perhaps the largest lottery in history.)

Until someone like Gates shows up and shows people how to do it again. Say, for example, Google...

Billy boy created a BASIC implementation that ran on CP/M, along with M80/L80 assembler/linker, and F80 FORTRAN.

None of these were any better than their latest products wrt bugs and "features". I was able to replace M80/L80 with a product from SLR Systems that was an order of magnitude faster, and did virtual linking to get a program that would fill 62 of the 64K memory space.

You have generic coming with Java 5.0 (aka 1.5).

so you have to cast a lot and even though there are static type checks you still end up with lots of ClassCastExceptions during runtime - not much of an improvement over Python or Perl.

You can dynamically check the type of your class before casting (instanceof).

Those problems are developer errors anyway, and you can always use wrapper objects to enforce use of certain types if you need.

I hardly have ClassCastExceptions during development, because I make sure to adapt my coding to the limitations of the language.

Really? It takes ages to start the Java VM and it starts with occupying 60MB of RAM - and the program hasn't done anything yet.

It depends of the program and its uses. On my machine i start tomcat in less than 5 seconds. I don't consider that to be a problem. Especially as I don't start it often.

I don't mean to preach Java. There are things I don't like with it. It's far from perfect. It's history has been strange: targeted to program appliances (e.g. washing machines, ...) then born on the web (applets), made a (unsuccesful) approach with desktop programs, with now a focus on server side. It's "Learn once, Fit everywhere" is too monopolistic, and it's lack of support with external techno is s*cking big time (COM integration anyone?), and deployment problems (ClassLoader issues) are a pain.

But it's a nice tool, and it solves some problems very well...

There is an `Emacs trap' in exactly the same way (except that it's free software, so you could add an FFI to it if you wanted to: the Emacs trap's sides are not greased).