> Lesson here:  sometimes the compiler not only gets in your way but also 
> doesn't do its job as supposed.

In other words, "no automated system catches every possible error". :-P 
That doesn't make automated error catching useless.

>>> In Scheme/Python/Ruby, the interpreter just don't care and it's all 
>>> up to you.
>>
>> Exactly. If you make a mistake, it's your fault, and the interpreter 
>> gives you no help at all to fix it.
> 
> It gives you a nice call stack trace. :)
> 
> Seriously though, Common Lisp is king in this respect.  Some of its most 
> well-known implementations' runtime systems allow for a quick debug of 
> what's going on in an app, correcting, compiling and even patching it 
> while the system is still running.  Yes, no need for reboots.

Isn't that precisely what Smalltalk also does? :-P

Of course, much as I like Smalltalk, the lack of static typing makes it 
really hard to use. When you have multiple levels of indirection, it's 
very easy to accidentally miss one out. Static typing would instantly 
detect this mistake and tell you exactly where the problem is. But 
Smalltalk doesn't have it. So you run your code, something of the wrong 
type gets assigned somewhere, and many hundred method calls later, you 
get an exception because some method isn't defined. Oh, sure, you get a 
call stack, but *good luck* figuring out where the _problem_ is. The 
call stack only shows you where the problem get _detected_.

>> Does that mean that automated systems for catching problems are a 
>> waste of time? Again, no.
> 
> Not at all.

You see why I like having automated error-catching systems then? :-P

>> For writing small, simple things on the fly, something vague and 
>> unstructured is probably the best way to go. (This is why scripting 
>> languages exist.)
> 
> Exactly.  Dynamic languages fit the bill whenever specifications are 
> vague and prone to much change.

No, scripting languages fit the bill anywhere the thing to be built is 
small, simple, and it's only going to be used in one specific way.

As soon as you start trying to do anything more sophisticated than that, 
scripting languages become inadaquate.

>> Personally, I don't tend to write that kind of code.
> 
> But it was the kind of which the OP was asking about.

Yeah, I get that. I'm just saying, for writing large complex programs, 
more help = better.

Post a reply to this message