freenode/#clim - IRC Chatlog
Search
3:29:01
nyef
Theory: Common Lisp and CLIM are mid-to-late-1990s era "export versions" of artifacts from a software design philosophy that dates back to the 1960s... But that philosophy may have been killed off in the late 1990s.
3:35:19
beach
The answer to my question might determine whether it is worth our while to revive that philosophy, or drop it for some philosophy that killed it off.
3:36:14
nyef
That's an interesting implicit dichotomy, and it ignores the possibility of synthesizing a new philosophy that partakes of both the old and the new.
3:37:37
beach
True. But, given our available manpower, often the best we can hope for is to copy the best existing designs we can get our hands on.
3:38:43
beach
I do try to come up with better things, but it is hard work, and there is no guarantee that it will actually BE better.
3:38:50
nyef
But at the same time, a philosophy shows *which* designs to steal, and which attempt to improve upon.
3:40:19
nyef
I believe that we have some fundamental difference in underlying philosophy, somewhere, but that the artifacts that we produce may tend to be compatible in practice.
3:43:31
nyef
Neither have I, really. The only way in which I see them as showstoppers is that I don't expect that our *overall systems* to be considered usable by the other.
3:43:38
beach
But I can't do research by accepting that what we have is already the best. I have to explore extreme alternatives. That's what research is about.
3:44:28
beach
Luckily, there are many philosophy-independent byproducts that can be independently useful.
3:46:47
nyef
I sortof came to the conclusion this evening that if I were to sink about three months of full-time work into producing a LispOS, I'd end up with a very good start.
3:47:38
nyef
At the same time, I don't think that it'd be something that I'd want to use on a day-to-day basis.
3:48:08
beach
I totally agree about the three months. You are very knowledgeable, and it is not as hard as some people might think.
3:48:36
beach
And, I don't know for sure that it would be something I myself would want to use. But I don't know that yet.
3:50:58
beach
Anyway, people tend to be awed by "bare metal" Common Lisp implementations, but, seriously, that aspect is neither very hard nor very important.
3:51:27
nyef
Mmm. We have at least two existence-proofs of x86oid "bare metal" CL implementations now.
3:52:10
nyef
The philosophy that I see behind Common Lisp and CLIM is not yet well-defined as far as I'm concerned, but includes some aspect of trust in the user-as-programmer, or possibly programmer-as-user.
3:54:00
beach
However, these days, there is not only the user/programmer, but an OS has to have some protection against malware.
3:55:37
beach
That's a different aspect, yes. I am trying to push shared-memory, multi-core as much as possible, because then I can keep the Lisp philosophy without going into a territory that I have no idea how to work with.
3:56:41
nyef
Yeah, that's the thing. I don't believe in shared-memory multi-core. It *breaks* once you get past a certain point, and that point isn't very far off single-core.
3:57:19
nyef
The further you can push it, the better, absolutely. But hitting double digits is *hard*.
4:00:35
beach
What I am saying is that very few people need massive parallelism, and even those who do don't need it most of the time. So there is still room for shared-memory multi-core software.
4:05:39
nyef
I don't disagree about there being *room* for shared-memory multi-core software. But I'm being absolutely hammered at work with something that is, fundamentally, a stream-processing system that only needs parallelism in order to increase throughput. None of the processes needs to talk to another directly, but they get hammered on the GC, or on other "process limits".
4:07:21
nyef
One comment I saw was that bouncing a "border router" (the gateway from your lan to the internet at large) can cause a noticable lag on the order of seconds on a modern machine, even for applications that don't talk to the internet in the first place.
4:09:20
beach
I recently read a very interesting article in CACM about non-volatile memory technology that is significantly faster than disk. Such technology exists, but the performance is completely wasted because of the slowness of the drivers (created for slow disks) used to access that memory.
4:10:37
beach
And I firmly believe that there are significant performance problems with context switches, buffer copying, etc.
4:12:08
nyef
beach: Context switches amount to dumping your L0 cache, at the very least. Buffer copies are exactly that, burning memory accesses.
4:16:58
beach
It depends on the kind of OS you want to write. For the one I am planning, there is no need for a file system.
4:18:55
nyef
If you're implementing Common Lisp, there's need for a file system, even if it's "just" a backing store against the whole streams-and-filenames thing.
4:21:13
nyef
At the same time, I Do Not consider Filenames, CLOS, the compiler, and whatnot to necessarily be part of Lisp.
4:24:21
nyef
I'm not sure where to draw the line when it comes to some Common Lisp concepts, though.
4:25:05
nyef
FUNCALL, FUNCTION, VALUES, MULTIPLE-VALUE-BIND, MULTIPLE-VALUE-CALL, and so on are clearly language.
4:26:13
nyef
In fact, ED is an egregious example of why I consider CL to be an "export version" of an artifact of a design philosophy.
4:26:59
nyef
Because there's really no justification for it other than as part of an integrated environment, which isn't otherwise called for in the CL spec.
4:31:00
beach
One thing I would like to see is a driver architecture in the form of CLOS protocols, inspired by I/O Kit.
4:31:22
beach
Except that we can do better, because I/O Kit is restricted by the fact that it is written in C++.
4:32:57
nyef
Mmm. Actually, we can probably do a decent job in terms of "driver architecture in the form of CLOS protocols" alone, nevermind I/O Kit.
4:34:17
nyef
The main thing for a "driver architecture" is finding the devices in the first place and matching them to drivers.
4:34:57
beach
We need a collection of classes (protocol or instantiable) and a collection of generic functions.
4:35:23
nyef
From there, we find the resources associated with the devices and make them accessible to the drivers. And that amounts to the "bus" concept in Linux.