[prev] [thread] [next] [lurker] [Date index for 2005/04/25]
> A language can have static or dynamic type information. This is about > what is checked at compile time, and when. Perl is dynamic, C is > static. Smalltalk is dynamically typed but the Smalltalk compiler can derive enough information about types to do compile time type checking. All static typing does is force the programmer to make assertions about types. A dynamically typed language allows you to defer those assertions to runtime when you can't make them at compile time. Or make the assertions and... hey... now the compiler has all the same type info that it did in the static case. The thing is, about the only time you REALLY can't derive the type information in a dynamically typed language, it's because you REALLY can't derive the types at compile time, so you have to re-implement a run-time type system in your statically typed langauge. And because you're implementing it yourself the compiler doesn't know about it so it can't include that in its code generation, so it can't optimise it away when a dynamically typed language would have. > A language can have weak or strong type information. This is about what > is checked at runtime. C is weak, Java is strong. Again, a good compiler can do this at compile time. And in fact, Java doesn't do it at run time all that often. The compiler does it at compile time. What the runtime does is prove that the compiler didn't screw up... that's an implementation detail. You can compile Java to machine code and that runtime step goes away... but the language is the same. The difference between strong and weak typing has nothing to do with compile time versus runtime. It has to do with whether the language provides a low level escape from the type system so you can more efficiently implement the dynamic typing that you don't get for free with a statically typed language. C lets you completely bypass the type system so you can efficiently implement things like qsort(). Java lets you create a whole bunch of extra methods and wrappers to get to kind of the same place. Lisp lets you define a macro and then gets out of the way so the optimizer can drag it for type information. Perl thinks efficiency is for wimps. > Actually, I think that is what I miss the most: the Common Lisp people > decided that a sufficiently smart compiler was a good goal, so things > like type inference were built in to it. ... oh, I'm preaching to the choir. Nevermind. > One of these days I will learn Postscript or Forth for the very same > reason, because they are the third completely different style of > language, so far as I can tell.[3] Smalltalk and Icon are also pretty nice. > Maybe. Maybe BeOS had only attracted great programmers, or they did > something really clever about concurrency. BeOS big advantage in this kind of discussion is that they didn't last long enough or get big enough to attract any but the most highly motivated developers. And even so, they really screwed up networking. > No memory protection, really and truly, is awful. Shared file tables, > memory allocators, system state[4], current directory[5], shared library > state and related fun are also awful. The lack of memory protection is painful, because when you screw up you scribble on another thread so when you crash you have no idea what went wrong. But you can deal with that. Sharing other operating system state is a lot harder to deal with. AmigaOS had no memory protection, but processes and tasks were dealt with as completely separate units by the OS so you didn't have one thread interrupt another in the middle of a call to some library code that forgot to do enough locking around shared state. > Build your code more than one *process*, and communicate through an > internal protocol over file descriptors, Unix domain sockets and/or > shared memory. AmigaOS message queues were pretty nice too, and DragonFlyBSD is following the same kind of model but building it in a little at a time. > If you really love your life, do this by adopting some sort of message > passing library (even if you call it an Object Oriented calling > interface, or RPC, or whatever) where someone *else* did the hard work > of making the above work. The problem with RPC is it puts you in lockstep with the idiot over on the other side, so even if you're not sharing state with him you're sharing execution context with him by proxy. It's better than just shoving your arm up the concurrency-beast's rear without so much as a rubber glove, but it's still unpleasant. > To stay on topic, I hate the way that software has to use threads to be > cool, and multiple processes is a sign that the design was poor. *Hate* I share your hate. What did you think about Plan 9? > Well, *most* of it isn't part of the system. Some bits, like the MIME > type and the ACL, *are* metatdata that belongs in the filesystem. The ACL, yes, that's not really metadata about the file, it's metadata about who's allowed to touch it. Putting te MIME type in the file system, though, is a great way to end up with all the problems that Mac OS Finder Info can cause when it goes just the slightest bit wrong.There's stuff above here
Generated at 01:00 on 03 May 2005 by mariachi 0.52