POV-Ray : Newsgroups : povray.off-topic : More Haskell fanning : Re: More Haskell fanning Server Time
30 Jul 2024 06:30:02 EDT (-0400)
  Re: More Haskell fanning  
From: Darren New
Date: 18 May 2011 11:11:02
Message: <4dd3e186$1@news.povray.org>
On 5/18/2011 1:32, Invisible wrote:
> It amuses me that there were operating systems 20 years ago that could do
> this better than Linux.

Yep. Annoyed me no end, when I had to use UNIX instead of a "real" operating 
system.

> It also amuses me that there exists something that
> Windows can actually do better than Linux.

There's actually quite a bit that Windows now does better than Linux, and 
quite a bit that Linux today does better than Linux five years ago. For 
example, I read that the clock is now *finally* a file handle, like the 
Amiga figured out 20 years ago and which everyone seemed to conveniently 
ignore for the past 40 years when arguing "Everything's a file in UNIX!"

> (I gather it's a similar story for figuring out when a file changed...)

Yes. The IPC stuff in Linux honestly still hasn't caught up to Windows. 
There's no kernel transactions, the file locking is still a mess especially 
over the network, the privilege and authentication system (at the kernel 
level) is still comparatively weak, performance monitoring and error logging 
is not unified, etc.

> be unique." Well, uh, they do if you want to use names to identify threads.

No. You might want to kill all database worker threads and not all web 
server worker threads.  I.e., the same thing you were talking about in 
Haskell code upgrades, where you want to kill all the threads running *this* 
code but not *that* code.

"Identify" doesn't necessarily imply "identity" except in math. :-)

> Testing for equity will still work. I think the only time ordering
> comparisons happen is if you store thread IDs in a BST - and then the
> ordering is arbitrary, it just needs to be total.

Exactly.

> Now, if some library somewhere is trying to use thread IDs to infer which
> order threads were created in, *that* will break nicely.

Exactly.

> I was thinking more about two versions of the same program. Presumably
> they'll connect, but malfunction.

It depends if one is upward compatible with the other. If the new program 
can handle new data and old data both, then they won't malfunction.

> Neither can you do this with Haskell. But the definition of "list" can refer
> to "list" itself.

Oh. No, you can't do that in Erlang, since "list" doesn't exist until you've 
assigned it.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.