Slashdot Mirror

In my opinion, working with "pure" functional languages like Haskell which do not allow any form of imperative updating (and yes, I know about monads) is too difficult for most programmers at this point in time. Therefore, I advocate languages like Objective CAML and guile scheme which support imperative programming as well as functional programming. These languages have different niches:

-- Objective CAML is an extremely fast dialect of ML with full static type checking and an object system (and, AFAIK, the only statically-typed functional language that has any object system at all). Timing tests have shown that ocaml can compile to within 25% of hand-optimized C code for many computationally-intensive tasks. Thus, many tasks that would normally be done in C++ can be done in ocaml.

-- guile scheme is a dialect of scheme which is targeted at the python niche: a scripting/extension language. There is no good reason why scheme can't be a superb extension language.

Unfortunately, as of this moment it's not possible AFAIK to build an application using ocaml on the bottom and guile as an extension language, but hopefully this will happen in time. Regardless, the point is to use these languages for your own pet programming projects, get the source out there, spread the word, and let functional programming grow organically, instead of trying to force it down people's throats.

Mike

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.

I don't think Scheme can't change that. It has been around for 25 years now, hasn't really taken off, and is more fragmented than ever. Besides, many people are still reluctant toward this lisp-type syntax. I don't see why Haskell could change that either: it's nice, but it has a very small installed basis, which is not growing very fast. It cannot be used for system programming and big projects, and it suffers serious competition on smaller projects from fast-growing procedural "elegant" high-level languages, especially Python. Eventually, I don't see why Common Lisp should succeed now, after years of disappointments and decline.

Here's the problem: try to imagine a functionnal language, whose compilers bring performance that are far superior than Java compilers', and approximately as good as C++ compilers'. This language should be highly portable, suitable for Java-types applets, and have an object-orientation design at least as good ad Java's and CLOS. Its syntax should be more attractive than Lisp's, it should be interpreted and convenient to use and debug via a command-line interpreter just the way Python or Lisp dialects are, and in the same time, as mentioned above, compilable into a very fast executable code. It should also be able to interoperate wich C modules (and maybe others). And, besides all these qualities, it should also be much more than that, and bring other unique advantages.

Such a language exists, it is called Objective Caml. One thing only is missing, the most important one, the installed basis. So there is a need to create the ecosystem. Here's a suggestion:

One could think of a new type of desktop environment which would be based on Objective Caml. Emacs users know that Emacs is an incredibly powerful and convenient Lisp environment, which is unfortunately limited to textual tasks, due to the limitations of Emacs Lisp (at the beginning, Emacs Lisp was supposed to be used solely as a macro language for an editor, and it has gone much beyond that). Imagine an environment in the spirit of Emacs (highly integrated, fully extensible, customizable, reconfigurable and reinterpretable when you use it, etc...), but whose scope would not be limited to textual tasks, and which could actually serve as a full "multimedia-hype-buzzword-whatever" universal desktop. To put it another way, try to imagine an Emacs type environment which would cover all the functionnalities of a, say, MacOS X or Windows user environment. It this is doable, then it's in Objective Caml.

Now, I know, I have a big mouth, and I should show some code. Anyway, comments appreciated.

I have personally developed commercial software in a functional language (Objective Caml -- a form of ML).

The fast code and small memory footprint of our product completely undermine most people's objections to functional languages. The most significant comment we receive is how rarely the product crashes -- this (to me) is the most important part of programming in functional languages: getting the job done without bugs.

A project to reimplement similar functionality in C++ had to start by writing an efficient memory allocator, implementing reference counting et cetera. I get this for free, along with true higher order functions, and much more.

But remember kids: use the right tool for the job!

-- Hopeless

I think the real reason Java and Perl have been successful is that they were all carefully designed to resemble established, popular languages. Stroustup's stated goal in designing C++ was compatibility with C. Java is basically a simplified C++ with garbage collection. Perl is based in awk, sed and unix shell. All of these languages have marginalized languages that are technically superior in many ways - C++ vs. Ada or Modula, Java vs. Smalltalk, and Perl vs. Python.

Unfortunately, most of the obstacles to the acceptance of a new language are social rather than technical. Backward compatibility and the support of a powerful company are key. A new language faces the same resistance that a new operating system does. Corporations and programmers have made substantial investments in their current toolsets and skills and are very reluctant to throw that time and money away. Something like Java, that looks and feels very familiar, is palatable, but something like Haskell causes panic.

Open source programmers are lucky, though, because there are far fewer constraints on the tools and languages they use. We pride ourselves on making design and implementation decisions on a strictly technical basis, and there's no reason we shouldn't make our choice of languages any other way. There are a number of high quality free implementations of functional languages out there.

I've spent the last few years studying functional programming in my spare time. While I'm not sure that I'll ever use a functional language professionally, there's no question that I'm a much better programmer than I would be otherwise. Libraries like the C++ STL and language extensions like Java's anonymous inner classes make a lot more sense if you've been exposed to closures and generic functions. Studying CLOS makes the limitations of single-dispatch OO systems like C++ and Java clear. But most importantly, functional languages help you see the larger picture - to focus on the architecture of a system without getting lost in implementation details. My experience with functional programming has taught me more about software design than the shelves of OO design pattern books and UML bibles I've waded through.

Any programmer that really loves the craft of programming owes it to themselves to take a walk on the wild side with a functional language or two. I'd recommend Ocaml, a mature, full-featured system that comes with a blazingly fast byte-code and native code compiler, a debugger and profiler, a first-class YACC-like compiler generation tool, a full-featured standard library, and a growing collection of contributed code. If you really want your mind blown, read SICP.

Ocaml!
It can be interpretted (e.g. Perl, Python).
It can be byte-compiled (e.g. Java).
It can compiled into native code (e.g. C++).
It has garbage collection.
It has a module system.
It can be object-oriented.
It's functional.
It's type-safe.
It has type inference.
It's succint.
It's sexy!

It can be used on Unices (the use of emacs as frontend is strongly recommended, it's an excellent collection of modes for it in the ESS package) and on Win32, there's a GUI for it on that platform.

Then, there's the PDL, offering "Number crunching capabilities for perl", I haven't used that either, but I hear it is good. Probably meant as an alternitive to IDL, that I have used, I didn't like it's syntax, so I did some hacking to replace the features I needed from IDL in R.

As an alternative to MATLAB, I hear SCILAB can be used. It doesn't seem to evolve very fast, and I haven't used it.

Now, I miss an alternative to Mathematica. Mathematica is the only proprietary software (and that I would think about using...) I can think of that still is better than Open Source alternatives. I have heard that some emacs package does have symbolic mathematical capabilities, but I don't what it is.

Elliptic curves got into the press because they're good for cryptography and some smart arse's cracked one landing themselves $10k.

Emacs is the ultimate windowing system. I haven't gotten around to write a window manager in elisp yet, but I'm sure there's somebody out there that would do it. :)

Both gwm and the more recent Sawfish are extensible window managers which are implemented in an elisp-like language.

Somebody suggested, as a 'blue-sky' feature for GNOME a while ago, a kind of Emacs window manager where you have each app open in its own buffer and switch between them with C-x b, C-x o and so on. For the special case of shell buffers, we already have this. Something like a VNC-mode for XEmacs would probably allow you to implement this fairly easily.

One is the KAME IPv6 project wich is a stack for FreeBSD/NetBSD/BSD/OS.

Another IPv6 stack for FreeBSd/NetBSD is made by INRIA IPv6.

Another interesting site is the Alternate Queueing (ALTQ) for queue and bandwidth management use under *BSDs.

And once you got this all working, why not play with OpenBSD and PGPnet VPN support.

Erik

• linuxtv
• inria.fr
• dvb.org
• protocol notes
• gilat
• europeonline
• drdish
• helius
• telemann.com
• broadcast.philips

Ah well, I should have been a bit more careful before posting: Octave is not really a symbolic math program. So I wouldn't mind if my previous comment as well as all others that suggest using Octave were moderated down as "Offtopic"...

For symbolic math, maybe SciLab (Open Source, not much symbolic stuff but a bit of it anyway) or MuPAD (free but not Open Source) could help, although I haven't personally tested them.

Unfortunately, like Matlab, it depends on Maple for its symbolic capability. So, what's needed is either a standalone symbolic kit for SciLab, or an open implementation of Maple...

CJW

I've used it in a previous life, not bad. http://www-rocq.inria.fr/scilab/

Actually that was sequence 81, one of the most basic:
%I A000081 M1180 N0454
%S A000081 1,1,1,2,4,9,20,48,115,286,719,1842,4766,12486,3297 3,87811,235381,
%T A000081 634847,1721159,4688676,12826228,35221832,97055181, 268282855,743724984,
%U A000081 2067174645,5759636510,16083734329,45007066269,1261 86554308,354426847597
%N A000081 Rooted trees with n nodes (or connected functions with a fixed point).
%D A000081 J. Riordan, An Introduction to Combinatorial Analysis, Wiley, 1958, p. 138.
%D A000081 F. Harary, Graph Theory. Addison-Wesley, Reading, MA, 1969, p. 232.
%D A000081 N. L. Biggs et al., Graph Theory 1736-1936, Oxford, 1976, p. 42, 49.
%D A000081 D. E. Knuth, Fundamental Algorithms, 3d Ed. 1997, pp. 386-88.
%D A000081 F. Bergeron et al., Combinatorial Species and Tree-Like Structures, Camb. 1998, p. 279.
%D A000081 R. C. Read and R. J. Wilson, An Atlas of Graphs, Oxford, 1998.
%H A000081 Index entries for sequences related to rooted trees
%H A000081 Index entries for sequences related to trees
%H A000081 Index entries for "core" sequences
%H A000081 ECS 57
%F A000081 G.f. A(x) = x exp(A(x)+A(x^2)/2+A(x^3)/3+A(x^4)/4+...)
%F A000081 Also A(x) = Sum_{n>=1} a(n)*x^n = x / Product_{n>=1} (1-x^n)^a(n).
%F A000081 Recurrence: a(n+1) = (1/n) * sum_{k=1..n} ( sum_{d|k} d*a(d) ) * a(n-k+1).
etc.
Neil Sloane (njas@research.att.com)

Overall, I'm quite pleased with this mobo!

Does Python implement closures properly yet? If not, I'll stick to my favourite language Objective CAML: http://caml.inria.fr/

Maybe the Slashdot team could use a hand in the ECC2K-108 cracking effort ...

There's another one that's been missed: MMM, which runs on most Unices and is available here. It's written in Objective Caml and seems a little outdated (1997). I haven't tried it myself (it wants old versions of libtk and libtcl which I can't be arsed to install) but even if it's of no practical use, it lets us say "There are n+1 browsers available for Linux!".

There's another one that's been missed: MMM, which runs on most Unices and is available here. It's written in Objective Caml and seems a little outdated (1997). I haven't tried it myself (it wants old versions of libtk and libtcl which I can't be arsed to install) but even if it's of no practical use, it lets us say "There are n+1 browsers available for Linux!".

There's another one that's been missed: MMM, which runs on most Unices and is available here. It's written in Objective Caml and seems a little outdated (1997). I haven't tried it myself (it wants old versions of libtk and libtcl which I can't be arsed to install) but even if it's of no practical use, it lets us say "There are n+1 browsers available for Linux!".

He never once considers (as far as I could tell in my admittedly hasty reading) speed issues for more advanced languages. There are plenty of fancy languages out there, but C/C++ is still the choice for power without sacraficing speed.

There's a link on the vic page to IVS, another very similar also-opensource tool.

I haven't used either of these tools myself because I can't afford the hardware, but I have a feeling that the Linux/Wintel crowd is ignoring a lot of research that has already taken place. Research people are often uninterested or incompetent in packaging and marketing their tools, but they may well have already done the hard part for you. And it looks to me like Apple and Microsoft stole most of their ideas from these guys.

I humbly suggest Efuns, which is an editor based on the design philosophy of Emacs, but rewritten from the ground up in Objective Caml (with some C in the necessary places). Yes, you can use advanced, powerful, type-safe "academic" programming languages to write Real Programs! And the Ocaml group at INRIA recently placed all of the Ocaml system under Open Source licenses -- LGPL for the runtime, QPL for the rest of it. Efuns is available here.

I humbly suggest Efuns, which is an editor based on the design philosophy of Emacs, but rewritten from the ground up in Objective Caml (with some C in the necessary places). Yes, you can use advanced, powerful, type-safe "academic" programming languages to write Real Programs! And the Ocaml group at INRIA recently placed all of the Ocaml system under Open Source licenses -- LGPL for the runtime, QPL for the rest of it. Efuns is available here.

Char of char
| Epsilon
| Empty
| Concat of regexp * regexp
| Union of regexp * regexp
| Star of regexp
| Underscore
| And of regexp * regexp
| Top
| Not of regexp

acc r1 s (fn s' => if s = s' then false else acc r s' k)

acc r1 s (fn s2 => acc r2 s (fn s2' => s2 = s2' andalso k s2'))

(* nacc (s1, s2) where s1 @ s2 = s *)
fun nacc (s1, s2) = (not (acc r s1 List.null) andalso k s2) orelse tryNextSplit (s1, s2)
and tryNextSplit (s1, nil) = false
| tryNextSplit (s1, a::s2) = nacc (s1 @ [a], s2)

in

nacc (nil, s)

end

At one time, I want looking for a modeline generator and found this one. I was surprised to see all sorts of weird resolutions in the results, like 1448x1086. Much to my surprise, that one actually worked on my monitor, which isn't rated for anything higher than 1280x1024. So, the question is: Why doesn't anyone talk about or offer resolutions other than the familiar 1024x768, 1280x1024, 1600x1200, etc? It doesn't seem there's anything magical about these numbers at all.
--

http://www.inria.fr/cgi-bin/nph-col as-modelines

Get your monitor manual and look up the parameters (max hor/vert refresh rate, etc). I was able to get 1536x1152 @ 95Hz for my Iiyama, veeery nice...

-adnans

Now if there was only a way to get this kind of speed with no wires at all!

I dream of an inexpensive, wireless gigabit/sec connection!

Well, afaik some of the most high-end wireless consumer networks available at this time would be Hiperlan (23.5Mbps). Some information is available
here and here.

There exists faster wireless networks, however then we're not in the "consumer end" any more.

I think the X mouse wheel scroll page will help you out.

You don't need to use imwheel, you just need to use a version of XFree86 from the last year or two, and you need to follow the instructions on the X Mouse Wheel Scroll Page (basically make sure scroll wheel support is turned on in XF86Config, then add new netscape entries to your .Xdefaults file).

Then voila, you've just added mouse wheel support to an app that was written before mouse wheels existed. I was thinking about how cool this was the other day while wondering why Regedit (in Win98) was ignoring my friend's wheel mouse...

Yes, OCAML also has a native code compiler.
See Chapter 10 of the documentation.

Yes, OCAML also has a native code compiler.
See Chapter 10 of the documentation.

MMM 0.4.1 Browser writtem in OCAML (interpreted language). Despite that fact, it's really not THAT slow.

AFAIK, The INRIA implementation of OCAML can compile and bytecode-compile OCAML, so the bit about OCAML being interpreted is incorrect. see: caml.inria.fr BTW, an OCAML entry won the ICFP contest this year.

The ECDL project has GPL-ed source code. Plus it involves actual mathematics, not just brute force.

It has given $12000 of prize-money to the Free Software Foundation.

The next challenge starts in a few days and will give $8000 to the Apache Software Foundation.

It's at http://cristal.inria.fr/~harley/ecdl/

Yes. Has been for quite a while, actually. Try http://www.inria.fr/koala/colas /mouse-wheel-scroll/ for information on making it all work. StarOffice supports it out-of-the-box, Gnome mostly does, KDE is working on it, and a bunch of other applications are or already have added support for it.

And where are the breakthru languages?

You just aren't looking.

• Cecil

• Dylan

• Haskell

• Objective CAML

• Sather

• Self

Recently-obsoleted 3d cards are cheap. Go for a 3dfx or RIVA TNT card, or maybe a Matrox card. I think the Viper is a Riva TNT or TNT2 card. I am in the same boat for ram (4mb).

BTW - My video card is a 4mb riva128 and I drive it at 1280x1024x16 - which I find very likeable. If I want 32bpp I drive it 1152x900 which is also nice. You have to generate the modelines but there is a web page here that makes this a little easier. After generating the modelines, I used xvidtune to fine tune them so I could maximize the painted region on screen.

It may be difficult to identify 100% non-american code, but I guess it still can be found (maybe DaVinci, PDore, etc...). More systematic search in non american university/research centers may help (for instance, in France, INRIA software - if they can be redistributed).

Amaya is a result of a project called Opera at the INRIA research institute in France, which is studying user interfaces for the editing of structured documents. (They also produced the thot editor and GRIF, a successful, commercial SGML editor.)

It may not meet everyone's needs, but is definitely work checking out, if only to see structured document editing done properly. Amaya also supports MathML, and has some preliminary support for Java and plugins.

There's a good explanation of how to set things up here. The new Gnome stuff (and I assume that this comes from GTK 1.2?) handles the wheel automagically. It's nice.

For the "small history":

Last year, top government officials were contacted by Microsoft, which basically said that France was "behind" in information technology and Microsoft would help it improved its education system on advanced technologies. Bill Gates even met Chirac on this.

Of course, lots of people (engineers, academics...) didn't like this. The problem was that Microsoft did its marketing right: the POLITICIANS are indeed very backward when it comes to technology, and they can get misled by clever marketdroids. If I were even more cynical, I'd say that politicians think of themselves as so bright and intelligent that if they are nonknowledgeable in a particular area, then it must be that the whole country is as ignorant as them.

So AFUL was founded notably by people from INRIA. AFUL is mainly a lobbying group for Linux and free software.

Our American friends may not be aware of this, but the bugs in Windows and Linux advocacy have been discussed on prime-time nation-wide radios; not to mention the mainstream magazines and journals talking about Linux.

I begin to think that after all academics can make good lobbyists.

here.

Someone posted that they couldn't ping www.inria.fr--well, I can ping it just fine, and, more importantly, reach it w/ http. Maybe it was down for a moment or something. Anyway, the url for ivs is www.inria.fr/rodeo/ivs.html. It may or may not be a good solution for you, but I've had a very good experience with another piece of INRIA software (scilab--like matlab but better, imo). Yay for french socialism and free software. Now check it out.

Wheel works fine for me long time. See above for details.