Rob Nagler <[EMAIL PROTECTED]> writes: > Gunther wrote: > > If you do not have a strongly typed system, then when you break > > apart and rebuild another part of the system, Perl may very well not > > complain when a subtle bug comes up because of the fact that it is > > not strongly typed. Whereas Java will complain quite often and > > usually early with compile time checking. > > I don't think there's an "objective" view about this. I also think > the "it compiles, so it works" attitude is dangerous. You don't know > it works until your unit and acceptance tests pass. I've been in too > many shops where the "nightly build" was the extent of the quality > assurance program.
Exactly- the statically typed languages I am familiar with have a casting mechanism to utterly subvert compile-time type checks. While static typing allows better compile-time optimization, it's value as a debugging mechanism is near the bottom of the list of advantages for engineering a large project. If interface guarantees are important between Perl objects, I'd have a look at Class::Contract. > > Compile time checking can definitely be a friend of yours especially > > when dealing with large systems. But it's also a friend that's > > judgemental (strongly typed) so he's a pain to drag along to a party.... > > To me, strongly vs weakly typed is less descriptive than statically vs > dynamically typed. To me, it is utterly nondescriptive in a PHB buzzwordy way, whereas static vs. dynamic typing is meaningful (and what I think most people really mean by the former). [...] > Here's a strong statement: Threads have no place in information > systems. The NYSE is run on Tandem boxes. Tandem's OS does not have > threads. The NYSE can process over a billion stock transactions a > day. The EJB spec says you can't fire off threads in a bean. I think > there's a reason for the way these systems have been architected. > > Threads are a false economy for systems which have to scale. As some > people have joked, Java is Sun's way of moving E10K servers. SMP > doesn't scale. As soon as you outgrow your box, you are hosed. A > shared memory cache doesn't work well over the wire. In my > experience, the only way to build large scale systems is with > stateless, single-threaded servers. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Could you say some more about what you mean by this? Do you mean something like "use a functional language (like Haskell or Scheme), rather than an imperative language (like C, Java, Perl ...)", or are you talking more about the application's platform and design (e.g. http://www.kegel.com/c10k.html )? -- Joe Schaefer
