[prev] [thread] [next] [lurker] [Date index for 2005/04/25]
> My recollection was that the language specification said that the > runtime environment MUST do enough type checking to be sure you couldn't > reinterpret random memory as other random memory, but I could be wrong. That dosn't require any type checking at runtime, if the input language is completely statically typed checked. It does require parameter type checking at link time, but that's an implementation issue... you can statically link the whole shooting match... and has nothing to do with the languages type model. The only thing you need at runtime is bounds checking on arrays, and that's got nothing to do with types. > > 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. > That doesn't gel with the division I heard, which suggests that my > memory is wrong, or different people use this detailed breakdown > differently. Hrm. I don't know which official taxonomy you're talking about, I'm just talking about what the language's model exposes to the programmer. And the difference between compile time and run time isn't something that the language can really tell you about except in terms of its interaction with the host environment where things like dynamic linking are visible to the programmer. > >> 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. > The key feature that Postscript and Forth have, for my learning them, is > the stack based language thing. Oh, yeh, but they're otherwise really pretty different. Postscript's got a vaguely Forth-like syntax, but semanticaly it's really close to Lisp. Forth is semantically pretty much assembly code, it's about as close to the hardware as you can get without talking about actual machine instructions. > > 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. > Last time I dealt with an RPC system it was asynchronous, Perhaps I don't understand what's RPC and what's interface then, but I was under the impression that at the language level an RPC was a rendezvous operation like an ADA message. > It always looked like it was going to be an academic project to me, > though, so I never put too much effort into learning it. Well, Bell Labs was using it in production. > Given that, I don't even know if they used a lot of threads, or not. No threads at all: fork() was it. > >> 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. > In the context of the discussion, true. You can change the ACL without changing the meaning of the file. That kind of metadata is a different kettle of aquatic vertebrates than MIME types. > > 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. > Maybe. I still cling to the idea that type identification can be > useful, since everyone wants to do it, and everyone does it differently > and badly. As far as I'm concerned there's only been one lot that ever did that kind of thing correctly, and ironically they were a videogame company. FORM nnnn 8SVX NAME 000A "Pan Flute" AUTH 0011 "Electronic Arts" ...
Generated at 01:00 on 03 May 2005 by mariachi 0.52