Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Clean

By nuntius in News
Sun Jul 16, 2000 at 10:25:11 PM EST
Tags: Software (all tags)
Software

Clean is a rather new programming language being developed at the University of Nijmegen in The Netherlands.


The biggest thing which distinguishes Clean from languages like C/C++/Java/Python/Perl is that its a functional programming language.

(No language wars, please. Functional vs Procedural has been beaten to death enough already.)

The reason I bring this up is that Clean looks like it might be worthy of real-world programming. There are several other good functional languages like SML/NJ, but Clean has several features which make it stand out. The libraries impressed me the most. Now I'm not a big functional programmer, but I wasn't aware of any functioal languages which had good support for things like TCP, integrating with C, and programming GUI applications. The GIMP uses Scheme for scripting user graphics filters, but I'd never seen the functional language being used as the actual backside/graphics engine.

Does anyone here have experience with the newer functional languages? (Clean, in particular.) Has anybody had much experience in this area, or are there some other languages which they'd like to recommend?

I'd just appreciate hearing other's experience with the new programming languages. Are any other languages (other than things like D-flat) coming of age?

Thanks,
Nuntius

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Clean
o SML/NJ
o Free for non-commercial use
o Good libraries
o The GIMP
o Also by nuntius


Display: Sort:
Clean | 40 comments (34 topical, 6 editorial, 0 hidden)
(3.00 / 1) (#5)
by Florian on Mon Jul 17, 2000 at 10:19:49 AM EST

There were some posts on clean in comp.lang.functional in the last days, the main argument against Clean was that it is a non-standard, non-free language with just one supplier, i.e. it is extremely risky to do any real world work in it.
  • Erlang is supposed to be very good at network stuff (ericson does all the programming for their large ATM switches in erlang),
  • Standard ML can do all the networking things (including web servers), too
  • as can Objective CAML
  • there are defined ways to interface Haskell with C
(And there is the recent discussion on The Other Site)

(4.00 / 1) (#6)
by Florian on Mon Jul 17, 2000 at 10:20:14 AM EST

There were some posts on clean in comp.lang.functional in the last days, the main argument against Clean was that it is a non-standard, non-free language with just one supplier, i.e. it is extremely risky to do any real world work in it.
  • Erlang is supposed to be very good at network stuff (ericson does all the programming for their large ATM switches in erlang),
  • Standard ML can do all the networking things (including web servers), too
  • as can Objective CAML
  • there are defined ways to interface Haskell with C
(And there is the recent discussion on The Other Site)

Sorry for posting twice... (2.00 / 1) (#7)
by Florian on Mon Jul 17, 2000 at 10:25:38 AM EST

... but I regard it as a bug in the software if you can post a message accidentally by just pushing the back button, or whatever happened (i didn't submit the comment twice). Why do all weblogs make it so extremely hard to return to the discussion a comment belongs to from the "Thank you for posting"-page?

[ Parent ]
Think I found the problem (2.00 / 1) (#12)
by Florian on Mon Jul 17, 2000 at 10:35:55 AM EST

Since I couldn't find a clean way to get back to the discussion I used the kuroshin.org-link at the top of the page in the hope it would bring me back to the top level of the site, and instead it resulted in a second and third posting of the same message. This is counterintuitive.

[ Parent ]
Re: Think I found the problem (2.00 / 1) (#16)
by fluffy grue on Mon Jul 17, 2000 at 11:11:44 AM EST

By 'the top of the page' do you mean 'the URL field in the browser'? Either way, it sounds like a browser bug, and your browser's trying to be "too smart" by reposting form data when you go to a recently POST-accessed URL. It also sounds like when you're hitting 'back' it's redoing the POST without asking. What browser are you using?
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Re: Think I found the problem (2.00 / 1) (#29)
by Florian on Tue Jul 18, 2000 at 04:35:55 AM EST

I'm using lynx, and this happens when i activate any of the links titled "Kuro5hin.org" and pointing to http://www.kuro5hin.org on the page that confirms the posting, not when i push back (in that case lynx politely asks if it should resubmit POST-content). I'll try it again and look at my squid log to see what happens.

[ Parent ]
Re: Think I found the problem (2.00 / 1) (#30)
by Florian on Tue Jul 18, 2000 at 04:36:31 AM EST

I'm using lynx, and this happens when i activate any of the links titled "Kuro5hin.org" and pointing to http://www.kuro5hin.org on the page that confirms the posting, not when i push back (in that case lynx politely asks if it should resubmit POST-content). I'll try it again and look at my squid log to see what happens.

[ Parent ]
Re: Think I found the problem (2.00 / 1) (#31)
by Florian on Tue Jul 18, 2000 at 04:43:06 AM EST

OK, i followed the link to kuro5hin.org in the line
Add to my.netscape | kuro5hin.org is supported by Intes.net and powered by Scoop
on the "Comment posted"-page and it resulted in another POST-request, resubmitting the same comment. Is this a bug in lynx or in the html generated by scoop?

[ Parent ]
Re: Think I found the problem (2.00 / 1) (#33)
by fluffy grue on Tue Jul 18, 2000 at 12:10:43 PM EST

Sounds like a lynx bug. Lynx is notoriously buggy when it comes to handling POST requests properly. Switch to w3m; it's a MUCH better text browser (though there's a few niggling interface issues).
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Think I found the problem (2.00 / 1) (#13)
by Florian on Mon Jul 17, 2000 at 10:38:04 AM EST

Since I couldn't find a clean way to get back to the discussion I used the kuroshin.org-link at the top of the page in the hope it would bring me back to the top level of the site, and instead it resulted in a second and third posting of the same message. This is counterintuitive.

[ Parent ]
Sorry for posting twice... (2.00 / 1) (#8)
by Florian on Mon Jul 17, 2000 at 10:25:54 AM EST

... but I regard it as a bug in the software if you can post a message accidentally by just pushing the back button, or whatever happened (i didn't submit the comment twice). Why do all weblogs make it so extremely hard to return to the discussion a comment belongs to from the "Thank you for posting"-page?

[ Parent ]
Sorry for posting twice... (2.00 / 1) (#9)
by Florian on Mon Jul 17, 2000 at 10:26:19 AM EST

... but I regard it as a bug in the software if you can post a message accidentally by just pushing the back button, or whatever happened (i didn't submit the comment twice). Why do all weblogs make it so extremely hard to return to the discussion a comment belongs to from the "Thank you for posting"-page?

[ Parent ]
As for posting TWICE... (1.00 / 2) (#11)
by Pac on Mon Jul 17, 2000 at 10:33:45 AM EST

There are two kinds of people in the world, those who can count and those who can't... :)

Evolution doesn't take prisoners


[ Parent ]
Re: As for posting TWICE... (1.00 / 1) (#22)
by mbrubeck on Mon Jul 17, 2000 at 02:47:13 PM EST

Isn't that three kinds of people?

[ Parent ]
Another Functional Language.. Erlang. (4.75 / 4) (#10)
by swdunlop on Mon Jul 17, 2000 at 10:29:26 AM EST

I'm a big fan of a cousin language to Clean, Erlang. Erlang is also a functional language, and while it doesn't have quite such a flashy GUI library, it /is/ opensource, and it has several advantages vs. Clean and other functional languages.

Advantages over Clean et al.:
* A Functional Programming Language. Simplifies implementation of many complex algorhithms. (Okay, so Clean considers itself a Functional Language. I've got a purist's rant coming later in the list.)
* Lightweight threading. The Erlang VM provides its own extremely light process scheduling, running in one OS-level thread. Context switches are claimed to be at least one order of magnitude faster than native threads.
* Simplified interprocess communications. Erlang provides a mechanism for sending and recieving messages between processes that is far easier to wrap your head around than any other I've seen.
* Distributed Processing. The kernel is designed to communicate not only with processes running in the VM, but with other instances of the VM, even on other hosts running other architectures.
* Powerful Distributed Database. Mnesis, a standard library included with the distribution, provides a very flexible relational database that is process-safe, and remotely accessible in a fairly transparent fashion.
* <Purist-Rant>Truely Bind-Once. This is a common complaint by elitist bastards like myself. Clean allows the redefinition of a bound variable.</Purist-Rant> This offends the classical properties of a functional language, but, to be honest, the side effects introduced, are not much more dangerous than those introduced by file access, communcations with other processes, user input, etc.
* Open-Source, Free and Portable. Clean's source is not freely available, and it is only available for a limited number of platforms. Erlang /is/ opensourced, and has an active outside group of developers extending, maintaining and improving. Since you have the source, and the source was designed to compile on Unixen in general, as well as Win32, it is in essence, more portable.

I have to run to a meeting, so I'll return with the disadvantages in a bit. Nothing like a serial-posting, right?



Erlang v. Clean, Part Deux. (4.00 / 1) (#18)
by swdunlop on Mon Jul 17, 2000 at 11:31:20 AM EST

There.. Pesky Developers. Where was I.. Oh yes..

Advantages of Clean over Erlang: * Clean has a higher level IDE. While Erlang provides a nice bash-like interface, replete with introspection, tab-completion, and other goodness, Clean provides module browsing, source editing and other IDE functionality that has come to be the standard for Visual * developers.
* Clean has, arguably, a better GUI library. They really focus on userland applications, with an eye to the rapid design of interfaces and integrating the user with the system.
* The Platform Game Development Kit. Okay.. So you and I, being ever so serious developers, don't need this.. But it /is/ rather easy to work with, and may provide the necessary carrot to bring schoolchildren into the Functional fold. Brainwash 'em while they're young, I always say.

You'll notice that there are a lot more advantages posted under Erlang, but not necessarily because Erlang is the best language, merely because it is the one my team has settled on, and the one that I use most, after comparing it with Clean for our project. Almost every advantage posted under Erlang is something we use on a daily basis. For more information, please visit the Erlang/OTP website.



[ Parent ]
Re: Erlang v. Clean, Part Deux. (3.00 / 1) (#19)
by Anonymous Hero on Mon Jul 17, 2000 at 01:29:22 PM EST

Very interesting. How are you finding performance? I read a while back that Clean had come up with ways of approaching C++ performance...Have you found that to be accurate, is Erlang comparable, or is it just not an issue for your project?

[ Parent ]
Our Project's Mileage (4.00 / 1) (#20)
by swdunlop on Mon Jul 17, 2000 at 02:20:04 PM EST

For us, Erlang was signifigantly faster. Our design was originally implemented in C++, and was forced into initial beta trials due to Management concerns. (Evil, bad, nasty Management. I can talk dirty about them, because they never read anything outside of Ziff-Davis. ;) ) The tests showed that under real-world loads, the application pegged the CPU, became sluggish, and in the case of our Linux version, had a chance of bringing down the kernel. This had two effects: firstly, it convinced Management to listen to the team, and secondly, it convinced us to experiment with other environments.

Erlang quickly won the heart of one of our more academic coders, and he managed to cudgel/beat/cajole the rest of us into learing FP. It was a little tricky converting our Object-Centric design specification over to the new paradigm, but the implementation went extremely fast. Erlang seems eminently suited to the three things our application hinged upon: Low Overhead Processes, A Flexible Database, and Asynchronous Interprocess Communication.

The new version is much more stable, performs well within our goals, and gained quite a bit in maintainability. I believe, when concurrent processes are involved, Erlang will outperform most C/C++ environments.



[ Parent ]
Re: Our Project's Mileage (3.00 / 1) (#21)
by swdunlop on Mon Jul 17, 2000 at 02:33:09 PM EST

I suddenly realized that I didn't answer all of your question, Hero.. Blame it on the post-meeting drowsies. We didn't really compare Clean and Erlang's performance when selecting a Functional system. To be honest, we saw Erlang's feature set, and pretty much ignored all the others. (When you've got a nail, and only one tool looks like a hammer, you don't go examining the wrenches too much.)

I have recently been playing with Clean, simply because it is another Functional Language but with a different focus than Erlang. I haven't benchmarked one against the other.



[ Parent ]
Ironic... (2.50 / 2) (#17)
by fluffy grue on Mon Jul 17, 2000 at 11:18:24 AM EST

Whoever did the website of this "free[beer] for non-commercial use" language didn't seem to have any problem with prominently displaying badly-bootlegged images of Calvin and Hobbes.

Also, what's with this nice website design which is utterly spoiled by having all these pointless animated .gifs and HUGE images, and having the "thumbnails" be the actual pictures with WIDTH and HEIGHT attributes? The language may be "clean," but the website sure isn't...
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]

I _HATE_ functional languages (1.00 / 3) (#23)
by tilde on Mon Jul 17, 2000 at 02:54:22 PM EST

There's a reason it's called reverse _polish_ notation. Are there good concepts in it? yes. Is it an interesting research tool? Yes. Is it retarded-chimp easy to write intepreters? absolutely, i've written one myself for some internal scripting on a custom deamon i wrote to serve up dynamic xml.

BUT

It's still the most bassakward notation for writing anything, it's messy( calling it Clean is like the name of greenland), and it's Just Plain Bad.

-T

Re: I _HATE_ functional languages (2.00 / 2) (#24)
by Anonymous Hero on Mon Jul 17, 2000 at 03:30:40 PM EST

You seem to be thinking of the Lisp family of languages, with their parentheses? While the basic idea of functional programming arose from Lisp, I have never seen a modern functional language withLisp-like syntax -- all of them use 'standard' infix syntax. Perhaps the reason for this is that those who are happy with Lisp, don't need to invent new languages because of the incredible ease of adding features to Lisp itself (made possible, of course, by the simple syntax).

[ Parent ]
Re: I _HATE_ functional languages (2.00 / 1) (#25)
by Anonymous Hero on Mon Jul 17, 2000 at 04:03:41 PM EST

two things, idiot:

- functional languages do not, by definition, use reverse polish notation (or any particular sort of notation.) and in any case, I can't think of any functional language that uses *reverse* polish notation; perhaps you have your terminology mixed up?

- clean, specifically, uses infix notation for operators, and prefix for function application.


[ Parent ]
Re: I _HATE_ functional languages (3.00 / 1) (#26)
by fluffy grue on Mon Jul 17, 2000 at 09:22:20 PM EST

So you're saying that Polish people are stupid, just like those stereotypical jokes? My grandfather was Polish. He worked on signifigant parts of some of the Viking probes. Whereas it obviously doesn't take a rocket scientist to bash things they don't understand. (See, because I probably have to spell it out for you, having worked on some of the Viking probes would make him, literally, a rocket scientist.)

No functional language uses RPN. LISP and its ilk use forward-polish (prefix) notation such as (+ 1 2). RPN (postfix) is used in *stack* languages, such as Forth and HP calculators, which are closer to imperative than functional. Half of the functional languages I've used are prefix, half are infix (if you count Prolog, which is technically infix but it has a prefix preprocessor, and which also isn't technically a functional language but it can be used as one). Functional languages aren't about the notation used but about the mentality - everything is based on the return value of called functions. You can have PN and RPN imperative languages just fine.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

So.. (3.00 / 1) (#27)
by swdunlop on Mon Jul 17, 2000 at 09:46:07 PM EST

A Functional language that supports both Prefix and Infix is.. Mixfix?

[ Parent ]
Re: So.. (3.00 / 1) (#32)
by fluffy grue on Tue Jul 18, 2000 at 11:52:06 AM EST

Hm, I'll have to mention that to one of my profs who's a HUGE Prolog zealot. :) He'd probably just explain that although there's syntactic sugar to make it look like you can use infix, though, internally it's all stored as prefix (and yet when a prefix expression is printed out, it's reformatted to be infix).

Basically, it's more like "a mess."
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Avoid Clean like the plague! (4.00 / 1) (#28)
by Anonymous Hero on Tue Jul 18, 2000 at 03:26:24 AM EST

I am a major fan of functional langauges, but Clean is just a non-free non-standard Haskell rip off which you should avoid at all costs. If you want a good functional langauge look at Haskell (Lazy) or ML (Strict). Haskell and ML both have several varients, many/several portable GPL compiler AND interpreter implementations, and libraries which support most anything practical which you want to do (Databases, GUI Toolkits, CORBA, COM, parsing, mathematics, etc.). Haskell and ML are the real work horses of the functional langauge community, both for research and software development. Note: Haskell's monads are the development which really broke down the walls between Lazy functional programming and object oriented programming / side effects. This is why Haskell is the Lazy langauge with all the DBI, GUI, and CORBA shit. Plus, the Haskell compiler GHC actually produces pretty good code. I think it's pretty safe to say that Clean has no chance of keepping up with Haskell on all three fronts (Theory/Research, Libraries, and opimisation). Haskell has many diffrent groups of people working on these diffrent aspects of functional programming. Clean is closed source, so it has not where near as many people who care about it. Actually, ErLang is interesting too, but I've never learned it. I think it's claim to fame is tring to bring "formal correctness and verifiability" into real world software development.. with some succes.

FP (none / 0) (#34)
by stimuli on Tue Jul 18, 2000 at 01:34:25 PM EST

I'm not that excited about Clean. I've had enough of single vendor languages.

I have used Haskell in some home projects and I really love it; however, I do have problems getting my head around using GUI components in a stateless environment. *Manipulating Stateful Objects* is just so central to the GUI design paradigm that mapping it over a functional base is not obvious.
-- Jeffrey Straszheim

Amen! Also, object orientation is essential. (none / 0) (#35)
by Paul Crowley on Tue Jul 18, 2000 at 06:12:56 PM EST

Trying to do GUI stuff without thinking object-oriented gives you the same impedance match. I once had to write a GUI program in ML, and one look at the way they'd bound Motif to ML functions convinced me that no language without extensible types can do this job. I've never known why people believe in FP. It's an excellent fit for the problems set to students in Universities. It's just not a good fit for the problems computers are used to solve in the real world.
--
Paul Crowley aka ciphergoth. Crypto and sex politics. Diary.
[ Parent ]
Re: Amen! Also, object orientation is essential. (none / 0) (#37)
by Nyarlathotep on Wed Jul 19, 2000 at 12:43:17 AM EST

I don't know about ML, but your general comments about FP are total bullshit. Haskell uses monads to allow side effects and object oriented programming without any problems. It dose a better job of object oriented programming then most of these crappy object oriented langauges like Java and C++.

The only real problem with Haskell is that some libraries predate the development of monads, so they are hackish. Look at the very youngest monad driven GUI tookits for Haskell.

BTW> Monads scare some people since they come from some pretty deep mathematics (category theory), but they are not very had to understand in practice. I suppose they require a serton degree of forthough and style.. like everything in FP.

Campus Crusade for Cthulhu -- it found me!
[ Parent ]
Re: FP (none / 0) (#38)
by Nyarlathotep on Wed Jul 19, 2000 at 12:53:40 AM EST

<i>I have used Haskell in some home projects and I really love it; however, I do have problems getting my head around using GUI components in a stateless environment. *Manipulating Stateful Objects* is just so central to the GUI design paradigm that mapping it over a functional base is not obvious.</i>

Object oriented programming and manipulation of stateful objects in a functional langauge many not be obvious, but it has become well understood within the last 10-20 years. Monads allow a perfect way to introduce states / objects / IO to a lazy functional langauge.

Actually, monads work so well that you can write C style imperitive code in Haskell. Haskell uses monads for it's main IO library, but unfortunatly many of the older libraries do not currently use them. I would assume that most of the GUI libraries have/are migratting to monads now. Hell, Haskell works with CORBA and COM, i.e. things which claim to require object oriented programming more then GUIs.

Anywho, I think it's safe to say that Haskell has totally anihilated the old "we can't use FP because then we can't use OOP argument."

Campus Crusade for Cthulhu -- it found me!
[ Parent ]
Thanks (none / 0) (#36)
by nuntius on Tue Jul 18, 2000 at 08:48:21 PM EST

Maybe I didn't make myself clear, but I know the good and bad aspects of FP/procedural.

Many thanks to those who got past that and recommended other languages. Erlang doesn't seem tailored to my needs, but I'm giving Haskell another look. Special thanks to swdunlop for coming back and posting his followup and the Anon Hero who mentioned that GHC produces good code. I had originally read on the Haskell page that its slow, but they were meaning the environment, not the code...

Thanks to all,
Nuntius

P.S. Does anyone know what ever happened to Haskell Quake? (I can't read the Swedish on their site very well ;-)

Re: Thanks (none / 0) (#39)
by Nyarlathotep on Wed Jul 19, 2000 at 08:31:14 AM EST

Yes, the GHC compiler is truely amazingly slow, but the code is about the best I've seen a functional langauge compiler spit out. There are some pretty smart people who have spent a lot of time improving it's preformence. It's worth mentioning that GHC has profiling stuff too. BTW> GHC dose the high level optimisations and compiles Haskell to C where GCC takes over to produce the lowlevel optimisations and produce the code. We all like to think about all the insane optimisation that a functional compiler which produced it's own code could do, but that would be so much work to write that compiling to C really makes more sence for the short term.
Campus Crusade for Cthulhu -- it found me!
[ Parent ]
There can be only one? (none / 0) (#40)
by Anonymous Hero on Wed Jul 19, 2000 at 10:39:38 AM EST

Seeing all these Functionnal Languages (Lisp, Scheme, Haskell, Camel) with all these variants on the same language, I'm wondering if functionnal language are not doomed to remain quite "confidential". . One thing which makes Pascal fails (I realise that its still there with Delphi, but its success is quite limited) is that there were many vendors with many incompatible variants... Well on the other hand, language research in the C family is much less active, I think.

Clean | 40 comments (34 topical, 6 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!