[prev] [thread] [next] [lurker] [Date index for 2005/04/25]
On 25 Apr 2005, Peter da Silva wrote:
>> 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.
[...]
>> 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.
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.
Maybe I should have said Emacs Lisp there, because I *know* that does.
> 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.
> 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.
Still, this makes sense. Besides, Perl doesn't think efficiency is for
wimps, it provides all sorts of kew1 optimizations like $a and $b being
hacked into your sort routines symbol table, but only if you don't look
at the arguments to the function. *Hate*
[...]
>> 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. They are both (as I understand it,
which is to say, not very deeply) based around the same sort of core
execution stack thingy. Well, that or really odd magic, since last time
I really tackled them it felt like that was really the key.
[...]
>> 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.
Yup. Also, it encourages an overly broad interface definition, because
it is "easy" to peek into the internal state of the other parts of the
code.
> 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.
Memory protection isn't something you *need*, but it sure is nice, and
is one of those things that I think represents a real advantage of
modern hardware/software over the older stuff.
If we didn't have it, something akin to the AmigaOS messaging layer
would be even *more* attractive.[1]
[...]
>> 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.
Last time I dealt with an RPC system it was asynchronous, but you are
right: most of them are awful things well deserving of the hate they
get from anyone working closely with them, except Microsoft, who seem
immune.
>> 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?
The same thing I thought when I first heard about it: this will never
fly, but hopefully the good bits will get out to somewhere else.
They seemed to have some great ideas about consistency, and a good grasp
on how to design a good interface to devices, window systems, etc, and
completely awful taste in GUI design.
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.
Given that, I don't even know if they used a lot of threads, or not.
>> 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.
> 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.
I wouldn't mind seeing someone try, just to find out, though.
Daniel
...so long as I don't have to write the standard.
Footnotes:
[1] Not that I ever used it, but it makes sense, and you enthuse enough
about it to make it sound great. ;)
--
Psychology is a rubber stamp pressed upon a slippery, dodging ghost.
-- Maxwell Bodenheim
There's stuff above here
Generated at 01:00 on 03 May 2005 by mariachi 0.52