bell-labs.com · Domains · Slashdot Mirror

I use R (GNU S-plus clone) by mbg · 2000-08-29 21:41 · Score: 2 · on Evaluations of Free Scientific Plotting Software?

I've been using GNU R for all my scientific plotting and data analysis work the last year or two. While there is supposedly some kind of GUI interface in the works, I do it all from the command line. That way you can automate, script, make things consistent, etc. New, fancy plots are a Simple Matter of Programming.

R is a clone of the statistics programming language/environment S-plus, which was invented at Bell Labs a number of years ago. It's a very nice, interpreted language with elegant support for vectors, functional programming, and even some basic object-orientation.

Grab the source from your nearest CRAN mirror or the Debian package.

Re:Assorted thoughts... by jsmaby · 2000-08-29 07:55 · Score: 1 · on KEO Time Capsule To Remain In Orbit 'Til 52001 AD

What about non text data? ... line drawings...

Use a simple vector format like metapost which should be fairly easy to decypher. A gif would probably be dificult to figure out, and a jpg nearly impossable. For bitmaps, pnm is rather simple (asci art would probably be meaningless because they wouldn't know what a 00100101 would look like).

Re:I agree - good documentation is important but.. by qbasicprogrammer · 2000-08-28 05:06 · Score: 2 · on Commenting and Documentation in Free Code?

A few hints can be found in various code style guides, but the only way to learn to write good code and comments is to read good and bad examples of other people's code, and to practice.

One such guide, Rob Pike's Notes on Programming in C, includes examples of good and bad styles.

I say Tomato, you say 蕃茄 Fan Qie by Frog · 2000-08-27 20:55 · Score: 1 · on You Say Tomato, I say Fan Jia Qie?

As far as I know... can look up (I'm not a speaker) the correct mandarin for tomato is fan1qie2 or .

You should be able to read the Chinese characters in this post if you're using IE or Mozilla and have a Unicode font with Chinese.

Otherwise you can look it up in .gif at this cool Chinese character site and hear it pronounced here (when it's back up?).

Let's do it! (Form a team, that is) by kuritzky · 2000-08-26 08:59 · Score: 1 · on 3rd Annual ICFP Programming Contest Announced

I don't know if anybody is still reading the comments here; I'm going to make a similar post on a usenet group or two.

Anyway, I'd like to form a team and do it! Yeah, I know that I should have put a team together before the contest, but I thought I might be able to do the whole thing myself. Fortunately, the task divides neatly into two or three (mostly) independent parts, so that teammates won't need to be in close contact with each other.

This paragraph won't make a lot of sense unless you've read the task description, so do that now if you haven't already. My plan is to write (in Perl, because it's the rapid-prototyping language I'm most familiar with) a program to translate GML into C. This code will be compiled and linked with the actual rendering code, which will be written by someone else on the team. I'm assuming that the procedural texturing precludes the use of canned open-source code. A third teammate should write GML code to thoroughly test both the translator and the renderer. Of course, there may be more than one person on each task. Please contact me if you're interested in joining my team, or if you have any useful suggestions.

Note: I will probably not be able to answer my mail until after midnight tonight. I probably won't have time to post this to usenet, so feel free to post a copy of this (together with an explanation of what the contest is all about) to all appropriate newsgroups.

--Eric Kuritzky
"Insert shiny happy .sig here"

Plan 9 / Inferno does it... by porttikivi · 2000-08-19 15:32 · Score: 1 · on Pipes In GUI's

In Plan 9 and Inferno all objects communicate through network transparent text or binary channels. The Plan 9 main user interface framework ACME is built on such set of files. The concept of "plumbing" allows run time combining of different application into systems with channels.

See acme command acme "methods" plumb command plumb "methods"

Plan 9 / Inferno does it... by porttikivi · 2000-08-19 15:32 · Score: 1 · on Pipes In GUI's

In Plan 9 and Inferno all objects communicate through network transparent text or binary channels. The Plan 9 main user interface framework ACME is built on such set of files. The concept of "plumbing" allows run time combining of different application into systems with channels.

See acme command acme "methods" plumb command plumb "methods"

Plan 9 / Inferno does it... by porttikivi · 2000-08-19 15:32 · Score: 1 · on Pipes In GUI's

In Plan 9 and Inferno all objects communicate through network transparent text or binary channels. The Plan 9 main user interface framework ACME is built on such set of files. The concept of "plumbing" allows run time combining of different application into systems with channels.

See acme command acme "methods" plumb command plumb "methods"

Plan 9 / Inferno does it... by porttikivi · 2000-08-19 15:32 · Score: 1 · on Pipes In GUI's

In Plan 9 and Inferno all objects communicate through network transparent text or binary channels. The Plan 9 main user interface framework ACME is built on such set of files. The concept of "plumbing" allows run time combining of different application into systems with channels.

See acme command acme "methods" plumb command plumb "methods"

Generic Java by mouseman · 2000-08-09 05:40 · Score: 3 · on C# Under The Microscope

The designers of C# have admitted the usefulness of genericity, but also confessed that C# is not going to support genericity on first release. More interestingly, they are unhappy with C++'s approach to genericity, which is based entirely on templates. It would be interesting to see what approach C# would take towards the concept, seeing as templates are pretty much synonymous with genericity at the moment.

As others have pointed out, parametric polymorphism / generic classes are supported elegantly in other languages, such as ML and its variants, without resorting to the hack of templates. But I've only found one post, by an AC, score zero, buried deep in one of the threads (alas, no moderator points) that mentions Generic Java (GJ). GJ provides an elegant solution to adding generics to Java, and may find its way into future Java specs. It essentially works by having the compiler do type checking based on the generic types, but then translate to standard Java by "deleting" the generic parameters and inserting type casts where appropriate. The compiler guarantees that none of those type casts will ever raise an exception. The result is that where C++ templates result in code bloat by producing a copy of the generic class for every concrete instance, the GJ approach yields a single class, but type errors are still caught at compile time as they should be. The rewriting approach also ensures compatability with the JVM, since it compiles down to pure Java (with the addition of a little glue code). The catch is that there is no run-time information about the parameters of generic classes, so explicit runtime type checks (instanceof, etc.) can't be used for parameterized types. There was a nice article about GJ in the Feb 2000 Dr. Dobbs's

I've used GJ quite a bit, and I'm quite happy with it. Furthermore, there's reason to hope that code written in GJ (the syntax of which is similar to C++ templates) will be compatable with future versions of Java, since Sun is looking into adding genericity to Java, and looking at GJ in particular.

Generic Java by Anonymous Coward · 2000-08-09 03:33 · Score: 1 · on C# Under The Microscope

Hence Generic Java. In my experience, GJ is clean and works well. The GJ page includes comments from Bill Joy and Guy Steele, as well as links to info on the incorporation of genericity into standard Java.

Re:All Java's are not created equal by bgalehouse · 2000-08-09 03:26 · Score: 1 · on C# Under The Microscope

Roughly speaking, the copying collector family (which includs the algorithms used hotspot) has overhead proportional to the amount of data (in both bytes and objects) saved - not the amount of data collected. This is very different than mark sweep.

On the other hand, the box/unbox problem is still a good topic for debate. Boxing means wrapping into an indepedent object so that the garbage collectors and utility classes and remote references can be less type aware.

Java provides a set of unboxed scalars (int, byte, etc), and the ability to manually box them. It sound like C# gives the ability to treat structs as scalars - effectively unboxing them.

Some languages (ML in particular) defer boxing questions to the compiler. This makes the compiler author sweat more if he'd like to avoid the overhead associated with boxing. Problems like this explain why SML/NJ is such big program.

Re:Back to C... by VP · 2000-08-09 03:10 · Score: 1 · on C# Under The Microscope

I think choosing a good type system is where a lot of languages fall flat, and I'm not a big fan of the huge C++/Java Object/Type/Library approach, although I haven't seen a truly good solution to this problem yet.

You may want to check out Standard ML (SML). It is a functional OO language, it is interactive, and compiled. Here is a good starting point.

Objective-C, NeXTStep, OpenStep, Mac OS X, and C# by plsuh · 2000-08-09 02:35 · Score: 5 · on C# Under The Microscope

It is useful to note that much of what C# provides actually originated in the context of NeXT, the Objective-C language, and the associated operating systems.

Inheritance and Interfaces

Another idea that was lifted directly off Java, and one which turned out to be very controversial is that of multiple inheritance. In what seemed like a step backwards, Java did not allow you to define classes that inherit from one than one class. Java did let you define "interfaces", which work like C++ abstract classes, but were semantically clearer: an interface is a functional contract that declares one or more methods.

Objective-C in the OpenStep/Mac OS X environment has single inheritance from a base class (NSObject), and protocols, which are precise counterparts to Java's interfaces. I have run into situations, however, where multiple inheritance is exactly what is required, and using interfaces meant that I had re-write the exact same code more than once, as I was implementing a group of specialized collection classes in Java. There were two axes of differentiation: mutability = (immutable, mutable), and ordering (partially ordered, ordered, strictly ordered). There was a lot of code that had to be duplicated that I should have been able to inherit from two abstract superclasses, one for mutability, and one for ordering. (*grumble*)

Garbage Collection and Memory Management

One new feature that I mentioned already was that of copy-by-value objects. This seemingly small improvement is a potentially huge performance saver! With C++, one is regularly tempted to describe the simplest constructs as classes, and in so doing make it safer and simpler to use them. For example, a phone directory program might define a phone record as a class, and would maintain one PhoneRecord object per actual record. In Java, each and every one of those objects would be garbage collected! Now, Java uses mark-and-sweep in order to garbage collect. The way that this is done is this: the JVM starts with the program's main object, and starts recursively descending through references to other objects. Every object that is traversed is marked as referenced. When this is done, all of the objects that aren't marked are destroyed. In the phone book program, especially if there are thousands and thousands of phone records, this can drastically increase the time that it takes the JVM to go through the marking phase. In C#, you'd be able to avoid all this by defining PhoneRecord as a struct instead of a class.

Objective-C provides a semi-automatic reference-counted garbage collection mechanism that is amenable to programmer intervention to increase efficiency, through a construct called an Autorelease Pool. Every object has a retain count, which can be incremented or decremented. The object's retain count starts at one, and when an object's retain count goes down to zero it is garbage collected. Note that this happens the instant that the retain count drops to zero, not during a mark/sweep. However, you may need to pass an object on to another part of your app, but your code does not need/want to retain it. What you do instead is tell the object to auto-release. It is then put into the autorelease pool, and later on during the system's garbage collection each object in the autorelease pool is sent a release message. Some objects that are entered in the autorelease pool still have a retain count (as they are being retained by other objects) and are simply removed from the autorelease pool; others have their retain counts drop to zero and are garbage collected.

You can fine-tune this mechanism to a high degree, by putting your own autorelease pool in the stack ahead of the system's primary autorelease pool. For instance, suppose you know that you will be allocating a whole bunch of objects for use in a part of your program, and after you exit you will never need them again. Well, you can put your own autorelease pool in for the system's autorelease pool at the start of that section of your code, write normal code, then remove and release your private autorelease pool and put back the system autorelease pool, which release all of the objects you created in your little section of code. Conversely, if you want an object to stick around, just don't ever release or autorelease it.

However, from a business standpoint, I find that the automated garbage collection and never having to worry about memory allocation issues is a strong point of Java. It allows me to code more complex applications and avoid memory debugging issues that invarable bedevil complex Objective-C and C++ programs. I can get a WebObjects application to a customer much more quickly using Java than using Objective-C, with quicker turnaround and more feedback cycles.

Events, Notifications, and Delegation

Personally, I found C# support of events to be a very exciting new feature! Whereas an object method operates the object in a certain way, object events let the object notify the outside world of particular changes in its state.. A Socket class, for instance, might define a ReadPossible event or a data object might release a DataChanged event. Other objects may then subscribe for such an event so that they'd be able to do some work when the event is released. Events may very well be considered to be "reverse- functions", in the sense that rather than operate the object, they allow the object to operate the outside world, and in my programming experience, events are almost as important as methods themselves.

The OpenStep and Mac OS X operating systems (viewed separately from the Objective-C language, as these features are available from Java as well) have long had notifications and delegates. There is a system-wide notification center, objects can define notifications that they will post in response to certain events, and objects can register to receive particular events or classes of events. This mechanism has been in place for a long time.

Delegation is a bit more tightly tied to Objective-C, as objects in Obj-C can pass messages (i.e. method calls) onto to other objects, and objects can "pose as" other objects. An object can register to be the delegate of another object (in Java, the delegator object needs to make special provision for this), and there are "informal protocols" or "informal interfaces" defined that indicate the possible messages a delegate might receive from its delegator. Again, this is not new, and its assembly into a single OS is not new.

Primitive Types

C# classes are also all eventual descendents of the object class, but unlike Java, primitives such as integers, booleans and floating-point types are considered to be regular classes.

This is one feature that I like very much, and wish that Java had. Objective-C, of course, will always have to support native types such as char's and int's, as it is defined as a superset of C. However, Java had the opportunity to remove this artificial distinction, and has caused lots of cursing from yours truly over the past couple of years.

Compiling to Native Code

It's not yet clear whether C# programs would need the equivalent of a Java Virtual Machine or whether they could be compiled directly into standalone executables, which might positively affect C#'s performance and possibly even set it as a viable successor to C++, at the very least on Windows.

I would point out here that compiling to native code may not result in the fastest execution. Review the HP Dynamo project, as written up on Ars Technica, for the reasons why JITC can actually exceed the speed of native code. The whole Transmeta Crusoe architecture is built around this theory of operation, and no one will claim that it's too slow.

Genericity

One thing that's sure to be missing from C#, and very sadly at that is any form of genericity.

Amen to this. The fact that genericity is missing from Java is a serious gripe of mine, and the fact that it is missing from C# is a serious omission. This business of casting objects coming out of arrays is a pain the in neck, and it is often tough to find out where an object of the wrong type went into an array, although on the cast coming out you get a ClassCastException. Far better to catch the problem when the object goes in, which often gives you a better idea of where your design is broken. One of these days I am really going to have to start using the stuff coming out of the GJ project.

Conclusions

Overall, I find that the "new" stuff in C# is really old stuff. Furthermore, this is not the first time that all of this has been pulled together in one place. Almost all of this has been in the NeXTStep/OpenStep/Mac OS X family for a long time, and the implementations there are quite mature. I suspect that the implementations in C# will require several revisions before they reach the levels that programmers can really use.

Just so everyone knows, I am a Consulting Engineer working for Apple iServices, a part of Apple Computer, specializing in WebObjects development. These opinions are my own, however, and not those of Apple.

--Paul

Actually, there is a different application here by SWPadnos · 2000-08-07 03:22 · Score: 1 · on Linux In A Box

Thanks. I've heard of the LRP, and looked into using it for our router/firewall here.

That's a different beast, though. All of the firewalling code relies on routing. A packet exists on one subnet (on one interface), and if certain conditions are met, it will be passed through to another subnet (on the other interface). This is great, but I think it would be better if this could be done with a bridge instead of a router. A company with a class A/B/C network has to split their net into multiple subnets for a router-based firewall to work, but not for a bridge-based firewall.

For some info on this technique, check out This link.

Since a bridge looks like a wire to the outside world (it has no effect on the topology of the network), a potential intruder won't know whether their packet has hit a firewall or not. A bridge that rejects a packet looks like the target machine (behind the firewall) is physically disconnected from the network. A traceroute won't identify the firewall (since the packets don't have to go through an IP "interface"), so that makes it harder for someone to figure out what machine to target for an attack.

I think that some of this functionality is available in the new 2.4x kernels, since they have disconnected the ethernet interfaces from the IP addresses (for other reasons). (This HOWTO has info on bridge/firewalling)

The next thing to do is to actually give a bridge an IP address - the same address for either NIC. You'd still have to know which "side" a packet comes from, for the firewalling to work. Once you have this setup, you can contact the machine (if you know its' address), but it doesn't show up if you try to contact something beyond it. Additionally, you can do things like have remote users (whose IP addresses change each time they dial in) use your SMTP/FTP/whatever boxes by authenticating to the brigde/firewall, and having the authentication script add a temporary IPChains-like entry for the dynamic address. That fixes a lot of the problems with spammers using relay hosts. (yes, this sounds a lot like a slightly modified proxy server)

Maybe this is a good separate topic for discussion on /.

Information by dvize · 2000-08-06 14:04 · Score: 1 · on File Packaging Formats - What To Do?

Two possibly relevant places:

The Software Deployment Information Clearinghouse stuff to read
Not-So-Bad Distribution another packaging system

Parametric Polymorphism in Java by Y · 2000-08-04 23:38 · Score: 1 · on Anders Hejlsberg Interviewed On C#

If you're interested in parametric polymorphism, check out GJ or this paper on NextGen. GJ is currently available for download, and NextGen is still in development.

> Mike

Re:Microsoft goggles by Y · 2000-08-04 04:19 · Score: 1 · on Anders Hejlsberg Interviewed On C#

It isn't clear to most people that C++ and Java are simply poor languages for frameworks, and parametric polymorphism, and binary portability.

While I sort of side with you on C++, I disagree strongly with Tim Sweeney's remark about parametric polymorphism and Java's inability to deal with it. I assume Mr. Sweeney has not taken the time to look at GJ, a.k.a., Generic Java which provides a good start towards parametric polymorphism. The type parameterization of classes/interfaces/methods provided by GJ has been a godsend for me - fewer messy manual casts to deal with.

Also, take a look at this paper on NextGen, which is an extension of GJ that will allow expressions like "new T()" and "instanceof T" where T is a type variable.

It is my personal belief that C# is one of the most poorly designed languages to come around in recent years, but I will expound on this in a different post because I have to catch the bus home in a few minutes.

> Mike

Re:This is not meant too gratuitously ... by Y · 2000-07-31 21:31 · Score: 1 · on Overcomming Programmer's Block?

I have to agree with Megasphaera - I often find coding in C++ tiresome. I've worked with Java for a few years now, and I find it fits my needs rather well. Recently, I've taken to coding in GJ, which is an extension of Java to allow parametric types (something like templates in C++). However, unlike C++ templates which copy the entire class guts into each ground instantiation (e.g., Vector<String> is a ground instantiation of Vector<T>, where T is a type variable) of a parameterized type, GJ creates a base class and performs type-checking at compile time to ensure proper usage of a ground instantiation. It eliminates a lot of the nasty manual casts one might have to do in a Java program and all ground instantiations are related to each other semantically.

Although java may be ..uhm.. quicker? simpler?

I'm going to go with "designed better". Yes, I'm one of those ivory tower wackos who believes in type safety over speed/efficiency. I will concede that debugging under Java sucks, make that blows. Java, on the other hand, makes it easier to get it right the first time so you don't have to waste as much time debugging your "new" and "delete" statements. Also, contrary to popular belief, garbage collection is a Good Thing (TM). A copy collector is by its nature more efficient than hand allocation because it only touches memory currently in use. Hand deallocation has to touch all allocated memory, not just the memory in use (unless you are a fan of memory leaks).

For low level programming where time is important, I wouldn't recommend Java - I'd say use C. For high level programming, I would recommend Java.

> Mike

Several Options... by Christopher+B.+Brown · 2000-07-31 02:28 · Score: 5 · on Distributed Operating Systems?

Mach was the "granddaddy" of distributed OS work, with most of the recent efforts going into GNU Hurd.
There's Mosix that builds a NOW atop Linux
The MIT Parallel and Distributed OS Group should be mentioned; efforts include the Exokernel
Plan 9 has an interesting model for splitting work across "compute servers" and "file servers" and "display servers."
Distributed Operating Systems lists lots of them...
Sun's Spring was the basis for much of what is in CORBA;
Sprite provided a Unix-like distributed OS that provided much of what is being used now to build journalling filesystems
Amoeba was Tanembaum's successor to Minix; note that Python was one of the side-effects of the Amoeba project...

Each has some somewhat different insights to bring to the table; there is no unambiguous way of saying "this is all vastly superior."

Google, anyone? by leshert · 2000-07-31 02:02 · Score: 1 · on Distributed Operating Systems?

A very quick Google.com web search for "distributed operating system" turned up a lot of information. Did you try this?

Some good links:

Amoeba, one of the first, most mature, and most well-known distributed OS projects.
Guide, a distributed "operating environment" that runs on top of *NIX.
Plan 9, from Lucent, has some distributed components

Plan 9? by cbwsdot · 2000-07-31 01:56 · Score: 1 · on Distributed Operating Systems?

Plan 9

Chris Williams

It's NOT a factor of 12 !!!!! by Clifton+Mars · 2000-07-28 21:50 · Score: 1 · on Tighter Video Compression With Wavelets

If you go to the technical paper you will see that they claim a factor of 4 (or 12 dB). Somehow someone has confused 12 dB with a factor of 12 compression, which they do NOT claim.

Anyway, this is a static compression factor. The big problem in video compression is taking into account frame to frame changes. This is why a (broadcast quality) MPEG 4 video takes 1 MBit per second to show talking heads, but 3 Mbit per second plus to show, e.g., a basketball game. How well their static technique helps video codecs will depend on how easy it is to adapt it to the dynamic problem.

Re:Attn: "Real Unix" zealots by kps · 2000-07-27 20:55 · Score: 1 · on FreeBSD 4.1 Released

FreeBSD contains no original unix code

Well, of course not. No current UNIX(TM) contains original Unix code. It was PDP-7 assembly code, after all. No current Unix can contain code from anything earlier than Seventh Edition without it having been significantly rewritten, since the C language changed substantially between V6 and V7. Original code is not the point; the point is the continuous line of descent from {V6,V7,32V} through {2,4}BSD to 4.4BSD to the current free BSDs.

and is not certified as UNIX by the Open group

Who cares what the suits say? By their criteria, no real (i.e. Bell Labs Research) Unix would qualify as such.

Current free BSDs' kernel sources contain some AT&T copyright notices, by the way. If you really, really care how much code hasn't changed much since (say) Seventh Edition, you can now get the latter from SCO for free.

Yes, IKIHBT, and yes, IAHAND, thank you. HTH.

Ian Presentation at Purdue on 7/24/00 by Multics · 2000-07-27 10:29 · Score: 3 · on Ian Murdock Answers

I attended a presentation he made at Purdue on Monday, 7/24/00 to the PLUG (Purdue Linux Users Group). He gave an hour presentation and dealt with an hour of formal questions and more than an hour of one-on-one questions. Several things struck me about his presentation:

1) In the hour presentation, he spent 40 minutes talking about Unix history. Sadly, he was wrong about lots of little things, such as Unix was designed to be a time-sharing system -- NOT. I would have hoped for 10 minutes of history and 50 minutes of NOW.

2) In the remaining 20 minutes, he described NOW. It sounded much like Athena and especially Plan-9. It is problematic that Plan-9 solved many of his problems and took 10 years to do that while they have far less time than that. He was "not familier" with MIT Oxygen

3) NOW's time-line seemed unrealistic. NOW's lack of core PhD class CS problem solvers was notably missing. NOW's goals (given the time line) should have been aggresively well defined and yet "we're looking at that" was often an answer.

4) He was factually incorrect about the features of Plan-9. If he'd even read and absorbed Plan 9 from Bell Labs he'd have been in better shape.

5) The company is missing a definitive business plan. It shows already and they're barely off the ground.

6) The office location they've selected in Indianapolis, is one of, if not the most expensive locations in the entire city. This means their venture capital burn rate will be extremely high. Within 5 minutes of that location there are places that cost 25% of that location.

7) The presentation was an un-abashed hunt for warm bodies that know something about Unix (Indianapolis is a nice place, but far from a hot-bed of computing -- Unix or otherwise).

So I came away with the feeling that they'd not done their homework before they started. Further that their venture capitalists said, "Linux is hot, who is available? Ian? oh good. Let's give him buckets of money and see if he can do 'stuff'."

In the end, they're destined to fail. They have a poor grasp of Linux pre-history (Multics & Unix real history) and lack good technical management to judge wisely how to spend their finite amount of money.

Too bad. NOW as a concept doesn't seem like a clunker as little as we were told about it.

Get it from the horse's mouth by spongman · 2000-07-24 11:29 · Score: 3 · on The History of UNIX

Denis Ritchie's site is excellent.

There are some very interesting insights into his work on Unix & C.

Specifically:
The Evolution of the Unix Time-sharing System
and
The Development of the C Language

If you're reading these slashdot articles you should be reading these papers instead!!

Also check out "The Unix System" by S.R.Bourne.

Get it from the horse's mouth by spongman · 2000-07-24 11:29 · Score: 3 · on The History of UNIX

Denis Ritchie's site is excellent.

There are some very interesting insights into his work on Unix & C.

Specifically:
The Evolution of the Unix Time-sharing System
and
The Development of the C Language

If you're reading these slashdot articles you should be reading these papers instead!!

Also check out "The Unix System" by S.R.Bourne.

Get it from the horse's mouth by spongman · 2000-07-24 11:29 · Score: 3 · on The History of UNIX

Denis Ritchie's site is excellent.

There are some very interesting insights into his work on Unix & C.

Specifically:
The Evolution of the Unix Time-sharing System
and
The Development of the C Language

If you're reading these slashdot articles you should be reading these papers instead!!

Also check out "The Unix System" by S.R.Bourne.

Another Link by Yudit · 2000-07-24 07:49 · Score: 2 · on The History of UNIX

How about this link: http://cm.bell-labs.com/cm/cs/who/dmr/hist.html ? (The Evolution of the Unix Time-sharing System)

Re:Paridigmns for a new OS? by F2F · 2000-07-20 03:17 · Score: 1 · on Miguel Says Unix Sucks!

Geez... making wishlist would be way more easy if you tried searchin for the answer first (any search engine would suffice)... The OS you're looking for is called Plan9. The objects composing it are called files.

Re:Where's this paper? It's not in POPL 83 by Animats · 2000-07-20 03:12 · Score: 2 · on What About Functional Languages?

Sure it is. On the POPL '83 page, see

Session II: January 24, 1983 - Chaired by Michael Fischer (Yale Univ.)

Automatic Program Proving for Real-time Embedded Software
Scott Johnson
John Nagle (Ford Aerospace)

The name of the paper in the proceedings was slightly different, but that's it. The text, unfortunately, isn't on-line anywhere.

Re:Paridigmns for a new OS? by mrogers · 2000-07-20 01:48 · Score: 1 · on Miguel Says Unix Sucks!

Or how about this...the GUI is the text. Multiple windows of text ala an Xterm, clicking on the word disk0 or some such thing would open up another window showing you the contents of the disk0 object.

Every piece of text is a mouse clickable object. If you type in disk0 it becomes a mouse clickable object which links to the contents of disk0.

Take a look at acme and an acme clone for X, Wily. (The acme link is just a link to the man page, because the main acme page has disappeared; the Wily link is a link to a mirror because the main Wily page has disappeared.)

$ cat < /dev/mouse

Paridigmns for a new OS? by shutdown+-h+now · 2000-07-19 21:43 · Score: 5 · on Miguel Says Unix Sucks!

I think UNIX did alot to change the way OS design was viewed. UNIX treats everything as a file. UNIX focused on making a system with multiple users on the same system at the same time.(multiprocessing anyone?)

I think the boys over in Murray Hill are doing alot now with Plan9 and a few other ideas I sometimes hear they kick around.

My question to all of you obviously more experienced coders out there:

What's the next paridigmn for creating the next less sucky OS?

Treat everything as a data object? a module?

I don't know. I would love to see an OS based on a functional programming language. Something small and compact without too much bloat to it. Code up a decent GUI as well. Or how about this...the GUI is the text. Multiple windows of text ala an Xterm, clicking on the word disk0 or some such thing would open up another window showing you the contents of the disk0 object.

Every piece of text is a mouse clickable object. If you type in disk0 it becomes a mouse clickable object which links to the contents of disk0.

Perhaps we would arrive at a new GUI or a new concept that makes either more sense to users, or perhaps is faster to operate with, with minimal learning curve.

A natural language based OS?

A user can type in his questions (eventually speak to the computer ala voice recognition) and receive textual and aural inpouts from the machine. I.E. "Computer, please tell me the contents of disk0." "The contents of disk0 are, foo.txt, bar.c, baz.h"

Eventually somebody or something has to sit down and figure out a different way of looking at the data we are presented and see if it makes more, or less sense than what we currently have.

I don't know who that somebody is but I think it won't kill me to sit down tonight and see if I can come up with a few ideas.

I'm thinking about using a functional language because it forces me to look at things slightly differently than when I write C code.

Anyone else have any ideas or pointers to projects currently looking at stuff like this?

It would be a nice project to jump in to, no?

Dan O'Shea

Paridigmns for a new OS? by shutdown+-h+now · 2000-07-19 21:43 · Score: 5 · on Miguel Says Unix Sucks!

I think UNIX did alot to change the way OS design was viewed. UNIX treats everything as a file. UNIX focused on making a system with multiple users on the same system at the same time.(multiprocessing anyone?)

I think the boys over in Murray Hill are doing alot now with Plan9 and a few other ideas I sometimes hear they kick around.

My question to all of you obviously more experienced coders out there:

What's the next paridigmn for creating the next less sucky OS?

Treat everything as a data object? a module?

I don't know. I would love to see an OS based on a functional programming language. Something small and compact without too much bloat to it. Code up a decent GUI as well. Or how about this...the GUI is the text. Multiple windows of text ala an Xterm, clicking on the word disk0 or some such thing would open up another window showing you the contents of the disk0 object.

Every piece of text is a mouse clickable object. If you type in disk0 it becomes a mouse clickable object which links to the contents of disk0.

Perhaps we would arrive at a new GUI or a new concept that makes either more sense to users, or perhaps is faster to operate with, with minimal learning curve.

A natural language based OS?

A user can type in his questions (eventually speak to the computer ala voice recognition) and receive textual and aural inpouts from the machine. I.E. "Computer, please tell me the contents of disk0." "The contents of disk0 are, foo.txt, bar.c, baz.h"

Eventually somebody or something has to sit down and figure out a different way of looking at the data we are presented and see if it makes more, or less sense than what we currently have.

I don't know who that somebody is but I think it won't kill me to sit down tonight and see if I can come up with a few ideas.

I'm thinking about using a functional language because it forces me to look at things slightly differently than when I write C code.

Anyone else have any ideas or pointers to projects currently looking at stuff like this?

It would be a nice project to jump in to, no?

Dan O'Shea

Paridigmns for a new OS? by shutdown+-h+now · 2000-07-19 21:43 · Score: 5 · on Miguel Says Unix Sucks!

I think UNIX did alot to change the way OS design was viewed. UNIX treats everything as a file. UNIX focused on making a system with multiple users on the same system at the same time.(multiprocessing anyone?)

I think the boys over in Murray Hill are doing alot now with Plan9 and a few other ideas I sometimes hear they kick around.

My question to all of you obviously more experienced coders out there:

What's the next paridigmn for creating the next less sucky OS?

Treat everything as a data object? a module?

I don't know. I would love to see an OS based on a functional programming language. Something small and compact without too much bloat to it. Code up a decent GUI as well. Or how about this...the GUI is the text. Multiple windows of text ala an Xterm, clicking on the word disk0 or some such thing would open up another window showing you the contents of the disk0 object.

Every piece of text is a mouse clickable object. If you type in disk0 it becomes a mouse clickable object which links to the contents of disk0.

Perhaps we would arrive at a new GUI or a new concept that makes either more sense to users, or perhaps is faster to operate with, with minimal learning curve.

A natural language based OS?

A user can type in his questions (eventually speak to the computer ala voice recognition) and receive textual and aural inpouts from the machine. I.E. "Computer, please tell me the contents of disk0." "The contents of disk0 are, foo.txt, bar.c, baz.h"

Eventually somebody or something has to sit down and figure out a different way of looking at the data we are presented and see if it makes more, or less sense than what we currently have.

I don't know who that somebody is but I think it won't kill me to sit down tonight and see if I can come up with a few ideas.

I'm thinking about using a functional language because it forces me to look at things slightly differently than when I write C code.

Anyone else have any ideas or pointers to projects currently looking at stuff like this?

It would be a nice project to jump in to, no?

Dan O'Shea

give it a try! by jetson123 · 2000-07-16 01:51 · Score: 2 · on What About Functional Languages?

The reasons why functional languages are not more widely used are the same reasons why other "minority" languages aren't more widely used: lack of training and lack of vendor adoption. Also, the creators of functional programming languages make adoption hard by picking somewhat unusual syntactic features.

It's hard to explain in a paragraph or two why functional programming is so great. Suffice it to say that it allows for much more reuse than object-oriented programming, opens up whole new ways of abstracting out functionality, and prevents one of the most common sources of bugs--aliasing.

Not all functional programming languages are purely functional. In fact, many programmers program in such functional programming languages like they do in Perl or Python. That can be both bad and good. On the one hand, because functional programming languages are powerful even for procedural programming, they may never be encouraged to learn how to take advantage of functional features. On the other hand, it may be a good way of getting work done.

My recommendation for people wanting to use a statically typed, efficient functional programming language would be OCAML. It has a full object system, yet also offers a full set of functional programming primitives. SML/NJ is another excellent implementation supporting both procedural and functional programming, and very lightweight threads (as an alternative to objects; cf. the GUI system).

Scheme and CommonLisp are also great languages. As a procedural or OO programmer, you can think of them as Python with a different syntax and a much better compiler. MzScheme is an excellent Scheme system for learning, and Bigloo is a powerful Scheme compiler. You can find more information at schemers.org.

For heavy-duty programming, CommonLisp is still better than Scheme, IMO, but it's significantly more complex. You can find a bunch of implementations at cons.org. I recommend CMU CommonLisp highly. For experimentation, CLISP by Haible is a good small interpreter. There are also a few "scripting" implementations of CommonLisp around.

Haskell is absolutely amazing for distilling programs down to 1/10 or 1/100 their size. However, it really requires a very different way of approaching programming. I'm not sure whether to recommend starting programming with it or not, in particular if you come from other languages.

There are also some special-purpose functional programming languages for high-performance computing. Those languages give performance similar to Fortran or C on numerical problems and can actually be parallelized more easily.

Of course, whether any of these links help you depends on whether you can get started using a new language with a reference manual, user manual, short tutorial, and implementation. If not, there are lots of textbooks around. The Haskell site in particular also has lost of link for FP-related resources. Also search Fatbrain.

So, in summary: functional programming languages are definitely ready for many applications. If you want to get started, there are lots of resources available. Try to find a book that you like and experiment. MzScheme or OCAML are fairly traditional ways of getting started (you still get a lot of the features you are used to from procedural languages). I suspect that functional programming is going to be the "next big thing" in programming after OOP, and I also think it's a lot more useful than OOP and a lot more well-founded.

Why Functional Matters by Tom7 · 2000-07-16 01:17 · Score: 5 · on What About Functional Languages?

I've always thought about submitting one of these "why not functional?" or "why not ML?" ask slashdots... but I think I know the answer.

My favorite functional language is ML (standard). It isn't "purely functional" like haskell (though we often write purely functional programs); it includes imperative features like assignment and arrays and IO, which are usually useful in real programs.

I work on an ML compiler here at CMU called TILT (which I'd like to think is one of the most advanced research compilers around), so I am sort of biased. But I also know what I'm talking about...

(Incidentally, the FoxNet Web Server is written entirely in standard ML, including the network stack (with ethernet, down to the hardware device driver)!)

Anyway, back to the question. Why does functional programming matter?

Programming functionally is closer to thinking in terms of math. Lots of algorithms and data structures are expressed more beautifully in a functional style. It's almost impossible to write gross hacks if you're programming functionally (most quick hacks actually turn out looking quite beautiful). Programming functionally has some direct advantages in this vein, and I find that I write better code faster when I write functionally. (I'll admit to hating it for a semester! But once I got used to it, I don't want to go back...)

There are some awesome features of most functional languages, most notably: Parametric Polymorphism and Higher Order Functions. (more rarely, such gems as functors and higher-order continuations (aka callcc; think a typed and higher-order setjmp). These all deserve their own posts to explain their incredible benefits. You are missing out if you've never written a program using these features.

But mostly, functional programming is useful for its indirect benefits. Let me explain some of these:

- Concurrency. Writing concurrent programs in a functional language is so much more natural. It's easier to avoid certain kinds of race conditions too, since you don't update variables in a functional language. SML/NJ has an awesome concurrencly package called CML .

- A powerful static type system and type safety. It's difficult to design a language (and many smart people have tried) that's imperative, type safe, and powerful. Features of functional languages like garbage collection and non-updatable values make it easier to define a language with a powerful type system. (in case you're still stuck in the 60s, type safety guarantees that your program CANNOT crash at runtime. No more uninitialized pointers, using memory after it's freed, bad casts, or other plagues of C++ programming).

A powerful static type system gets you a lot:

- Debugging. It's easier to find mistakes in your program. When I program in ML, I get a list of all the type errors in my program when I compile. I can go back and fix these before I have to run my program on test cases, etc. Debugging is so much easier. It's hard to explain how incredibly useful this is compared to programming in C++. Everyone who's used ML can attest to this fact: once your programs typecheck, they Just Work.

- Your programs run faster. Java has a somewhat more mature type system than C++ (it guarantees safety, for instance), but most of this is dynamic. That means all your objects are tagged, and these tags are checked frequently to make sure you're not doing anything wrong! There's no way the compiler can optimize these out; mistakes in the definition of the language (array subtyping) make tags necessary for type-safety. In ML, we don't have to tag values or check them at runtime. Yet we guarantee our programs run safely because we verify all of the types at compile-time!

- Compiler Technology Advances. Most research in programming languages and compilers these days is on languages with interesting type systems. We're seeing fewer and fewer improvements to C compilers, and lots of improvements on "advanced" programming languages. The type system allows you to make more optimizations, because the compiler has more information available to it. Some concrete examples:

Aliasing - a big problem for C/C++/Java compilers. If you've ever looked at the machine code they produce, you've seen this effect. "Why is it fetching that address again??" ... because two pointers may have pointed to the same thing, and in order to preserve the semantics of the language, redundant work is done. When you're not doing updates (functional programming), the compiler doesn't have to worry about aliasing.

Function Calls: Practically every C/C++ compiler treats functions as a black box. Languages with stronger type systems are able to optimize around function calls because much more information (types) are available.

Our TILT compiler that I mentioned earlier does something rather new: Each compilation phase transforms not only the program but its type. We keep the type information around even when we are dealing with assembly language! This enables us to perform some unprecedented optimizations.

- Machine independence. Making a type system usually means hiding away the details of the machine, and this usually means that the execution of your program is completely predictable. (Compare to C/C++ "undefined" behavior!) ML programs are extremely portable.

- Modularity. I was able to understand and start working on the (100,000 line+) TILT compiler in a matter of days rather than weeks because of ML's strong modularity features. The most interesting of these are:

Signature Ascription - This allows you to define abstract data types by naming a type and some operations on it (and their types). This is similar to header files in C (much more refined), but thanks to the type system, you can guarantee that the user can ONLY use your abstract data type the way you intended. They cannot cast, subclass, or use any other tricks to get at your datatype. (Some OO folks have solutions for this too, but they are not as elegant). This is awesome, because it helps you figure out where bugs are. I can attest that this really works; my project this summer is to change the way a very important module works... and so far, I have only experienced one observable effect of changing the representation!

Functors - This is somewhat like C++'s template system (but more refined); allowing you to write programs which operate on modules. (Ie, you give me a module which implements sets, and I'll give you back a module which implementes maps). This is very useful, and since all the work is done at compile-time, incurs no runtime cost.

- Proof-carrying code. You haven't seen this yet, but you will. What if you could download a program off the internet and run it, knowing that it won't do anything wrong? What if it wasn't subject to sandboxing (and slowdown) like Java apps? What if you didn't need to trust the source (certificats/signing)? Proof-carrying code carries a proof of its type-safety (and other safety metrics) with it; your computer verifies the proof and then runs the bare code! You can read more about this here .

Now here are some answers to the question of why not functional?

- RIGHT NOW, functional languages are slower (estimate 2x) than languages like C. Against a "modern" language like Java they fare rather well. Compiler technology is advancing and will fix this! I'd also argue that the other benefits (developer productivity, code maintainability) far outweigh the slowdown.

- Functional is weird for a lot of people. It took me at least 6 months to figure out why it was good, and I consider myself a pretty good hacker. Most people are more comfortable with imperative languages (at first...), possibly because that's usually their introduction to programming.

- There are not many commercial applications for functional programming yet (outside of Ericcson), and some people just program for money.

I would like to see the hacker types of the world pick up some new, interesting languages. Most of these languages don't have powerful marketing engines like Sun or Microsoft behind them, but hacker types are (usually) smart enough to see past that stuff!