Slashdot Mirror

As far as time limits are concerned, may I suggest Mercury. It's a functional/logical hybrid that's somewhat unorthodox for VHLLs in that it's a compile-only rather than interpreted-only or interpreted/compiled. Its designers claim that it can get similar performances to programs of similar functionality written in C, alhtough I haven't seen any benching, and I'll believe it when I see it. :)

Anyone think perl might be the language of choice? :)

No, because Perl isn't a functional language. *sigh*.

You're kidding, right?

How often, in every day life, do you notice diffraction and interference? I never do. Consider also that the size of objects which cause diffraction are the same order of magnatude in size as the wavelength of light (i.e. 10^-7m). Which, BTW, is far smaller than you can see. Now imagine you're going to keep track of polygons/voxels 10^-7 in size, for a room that's 10m by 10m by 3m. That's 10*10*3/(10^-7)^3 =~ 3*10^23 voxels to keep track of. Forget it. There are far better ways to simulate diffraction, if you really wanted it.

What I have seen, that's really cool, are Relativistic ray tracing. Do that Nsuck^H^H^H^Hvidia!

--Bob

I can think of several other projects funded by Microsoft that produce GPL'ed code. Some work on the Mercury language, for example, was funded by them. One of the conditions for the cooperation was that "all the support for the .NET platform in the Mercury system will be available on the same terms as the rest of the Mercury system, i.e. open-source under the GPL or LGPL".

This seems all the more ironic since I understand Craig Mundie to be telling the government not to support GPL'ed development. Is Microsoft itself now going to stop research funding for software under such cancerous licenses?

I can think of several other projects funded by Microsoft that produce GPL'ed code. Some work on the Mercury language, for example, was funded by them. One of the conditions for the cooperation was that "all the support for the .NET platform in the Mercury system will be available on the same terms as the rest of the Mercury system, i.e. open-source under the GPL or LGPL".

This seems all the more ironic since I understand Craig Mundie to be telling the government not to support GPL'ed development. Is Microsoft itself now going to stop research funding for software under such cancerous licenses?

If you find early computers fascinating, visit Melbourne Australia sometime. The only surviving first generation computer is displayed at the Melbourne Museum.

CSIRAC was built in 1949, and unlike other similar machines, was not upgraded or broken up.

http://www.cs.mu.oz.au/csirac/csirac.html

The first time a computer played music was in 1957, at Bell Labs in the United States.

The reference is wrong. According to this page, both British and Australian computers had been used for playing music at least six years previously.

The music of CSIRAC, the first Australian computer, has recently been recreated using an emulator and rebuilt hardware, and a CD has been released.

Go you big red fire engine!

Check out One of the first computers to play music. The way it was done was amazing with what they had to work with.

Mercury (a pure, fast, functional/logic programming langauge) has a very simple performance model for the basic language. Some of the higher level aspects of the language, such as typeclasses and higher order code, have less obvious models, but as soon as the optimizer is turned on in any language you lose the simple performance model. That said, you can do much more in the way of optimization with a pure, referentially transparent language than you can with imperative stuff like C and (ugh...) C++.

Of course, it would have been nice if M$ had have extended a similar courtesy to the Java community :-(

On R&D:

... most really innovative stuff in Oz gets done by the CSIRO (commonwealth science and industry research organisation) and the universities. ...

As for software verifiability, plenty of people *have* done research into it. Aside from many problems in the field turning out to be NP-hard or worse (yes, there are such problems), stating exactly the properties you wish to verify is in itself a large intellectual effort.

Notwithstanding all of this, there have been some interesting projects done, some of which have made it to some areas of industry. One simple-to-grasp example of a useful project was an automated termination analyser for the Mercury programming language. While it obviously can't be 100% accurate, it could prove that about 80-90% of the Mercury language's standard library would terminate in finite time for all inputs - and, usefully, it turned out that code for which termination couldn't be proven often contained subtle bugs.

Mercury, however, has features that make this kind of thing much, much easier than conventional programming languages (but make programming in it somewhat of a challenge to learn initially). Trying to do this on pointer-ridden C is probably too difficult and too inaccurate to be useful.

The Mercury programming language is another interesting example of a programming language. The Mercury group's goals were to build a logic programming language suitable for large conventional programming projects. Therefore, they required it to have execution speed comparable to conventional imperative language, strong typing, full support for I/O without going outside the logical framework, a module system, amongst others. Not surprisingly, they claim that their project so far supports *their* goals better than any other language, and they are probably right too!

It's difficult, but not impossible, to design languages that meet your requirements better than existing ones. Languages become widely used when your goals match the needs of a sufficiently large group of programmers significantly better than their current language.

• OCaml is multithreaded (linuxthreads was born as a way to get it to work on linux), although a single program won't take advantage of a multiprocessor. Core dump is impossible using its static strong typing, and the optimizing native-code compiler provides with great performance.
• JOCaml is an extension of OCaml based on the Join-Calculus, the latest and greatest paradigm for distributed programming (can be seen as actor-based programming done right, as based on a well-understood algebra). Can take advantage not only of multiprocessors, but of processor farms, or any distributed architecture, even heterogeneous architectures. Only bytecode can migrate, native code modules and primitives must be compiled into the servers.
• Erlang is based on a paradigm quite similar to jocaml, but is designed for industrial applicability rather than hacker coolness; it has dynamic typing, a pure functional core (despite the logic programming syntax, it only has matching, not unification), enriched with explicit asynchronous communication primitives, and an implementation that every phone call you make depends on, if you use British Telecom. If you need tens of thousands of threads and/or lots of nodes, this is what you need.
• There is also Mozart, an distributed implementation of Oz, a real logic programming language (has unification).
• Haskell and Mercury also have extensions for concurrent and distributed programming in the works, but I admit I don't know how usable they are for real programming.

-- Faré @ TUNES.org

It's all here, and it's all under open licenses of one sort or another.

But I've got to say, I was somewhat perturbed by the fraction of Linux training material which was proprietary...

I am in a similar position to the original poster. I am just about to graduate (6 months from when I was meant to, but anyway), from the Univeristy of Melbourne, Australia. There basic policy, from what I can garner from this statute is that so long as there is no commercial exploitation, i.e., making money from it, of the IP, then the uni doesn't care what you do. If you do make money from it, then either the uni wants a piece of the pie, or, you must get permission from the IP officer of the uni. That is how things such as Mercury can be released under the GPL.

As for the publishing of thesis, they don't want these published commercially because that means the won't be able to include this in there citation statistics to show that they are the "premier research institution in Australia", as shown here. The more research they do, the greater the income for them.

its interesting to read its old opcode spec list and other tidbits... anyone fancy an emulator?

mercury delay lines and drum storage. yum!

Write your Own Operating System [FAQ]!

I suspect there are several things that would help classify a computer as vintage.

I'm guessing the most importaint factor is that it has been abaondoned by its maker. Things like a Sun 3 are vintage while a sparcstation 1 isn't (yet). A PDP-11 and most vaxen are but the Microvax isn't yet at least till the end of the month.

I also expect that a minium of 5 years (or should it be 10) is needed. My web server is running on a Sparcstation 1 that is now over 11 years old and its not vintage yet so maybe 10 years should be the cut-off.

I do know the the first computer to do music that they are installing accross the street from my house counts as vintage since its now 50 years old.

On a more general level, I believe that "computer history" is a job for both CS people *and* historians. Professional historians have learned a few tricks over the years about understanding the past, and trying to write history without their skills leads to amateurish, sloppy work. If historians were trying to use computers for their job, should they get help from an expert or should they try and write the code themselves?

• Functional languages are slower, as a rule, than imperative languages. Compilation, rather than interpretation, helps - but few functional languages can approach the speed of a well-written imperative program. Of course, there are many occasions where speed doesn't really matter, and even if it did it's limited by I/O, rather than CPU, but it's still a factor
• A lot of functional languages still have the element of research tool rather than real language about them - particularly in the area of their libraries and other associated bits. They don't support things like graphics toolkits, CORBA bindings, parser generators, database interfaces, and the like. Similarly, the toolchains are generally less sophisticated - while some very clever debuggers have been written for functional languages, they haven't been turned into real tools in many cases.
• A lot of people just don't get non-imperative languages. I taught Haskell as a first computer language at a university, and people frankly struggle with it - much more than they seem to with imperative languages.

I like functional languages - the project I'm working on uses them extensively, and Scheme is great to work in. It's a shame that they're not more widely used.

And, while we're naming our favourite alternative languages, you could try Mercury, a logic programming language designed for real-world programming. It compiles to C, it's got the best type checking of any language I've ever used, it's fast, and its compiler is good. The fact that it's developed at my former university has nothing to do with it :)

Check out the Agents Group for this and other projects.