Slashdot Mirror

Let's not forget Donald Knuth for TeX which powers it all, and Leslie Lamport for the LaTeX macros. And of course, Bram Moolenaar for my preferred authoring environment.

Also cheers to the folks behind EMBOSS and those behind the R project. Wayne Rasband for ImageJ, and all responsible for SciLab. Thanks to everyone for making science (more) fun. :)

ECC has been cracked...it just takes roughly the combined powers of 50 PCs to do it. This is a really old link but its valid for this thread.
http://cristal.inria.fr/~harley/ecdl7/readMe.html

But if you're still concerned about speed, you can always go with something like OCaml which is just a shade behind C in speed, yet offers you true type saefty, expressiveness, and flexibility all in one package.

There's been a lot of work done in programming languages over the years, and there are a lot of good languages out there to work with, despite what a glance at the sorely lacking O'Reilly catalog might say...

I'm uncertain what you mean when you suggest that "the current state of O'Caml is that interfacing to these kinds of 3rd party libraries (using standard DLL or share library interfaces) is almost unworkable."

Are you referring to the ability to construct bindings for shared libraries written in C? Are you referring to being able to generate bindings to shared libraries written in C? Are you referring to being able to write short annotations for introducing symbols from shared libraries written in C in OCaml code?

I suppose one of the problems with being vague is that people have no idea what you're asking.

You can write bindings to C libraries by hand using the FFI, like you can with Python, Perl, or Java.

There are ways of generating wrapper code for interfacing to shared libraries, like CamlIDL and SWIG. You could also generate interfaces for use with the Dl module.

The Caml Humps site is a good place to start looking for some of the presently available libraries.

I think a far more annoying aspect of Objective Caml is that it is not currently possible to have natively-compiled dynamic shared libraries written in Objective Caml; all programs will be statically linked to Objective Caml libraries. You can load dynamic bytecode, but that's really just not the same.
There once was a program for wrapping Objective Caml code into a DLL but I don't think it has been kept up to date, it's a dirty approach, and as far as I recall it only worked on Windows.
There's the SCaml effort, but it seems to be falling behind, is incomplete, and only works on a few platforms.

I'm uncertain what you mean when you suggest that "the current state of O'Caml is that interfacing to these kinds of 3rd party libraries (using standard DLL or share library interfaces) is almost unworkable."

Are you referring to the ability to construct bindings for shared libraries written in C? Are you referring to being able to generate bindings to shared libraries written in C? Are you referring to being able to write short annotations for introducing symbols from shared libraries written in C in OCaml code?

I suppose one of the problems with being vague is that people have no idea what you're asking.

You can write bindings to C libraries by hand using the FFI, like you can with Python, Perl, or Java.

There are ways of generating wrapper code for interfacing to shared libraries, like CamlIDL and SWIG. You could also generate interfaces for use with the Dl module.

The Caml Humps site is a good place to start looking for some of the presently available libraries.

I think a far more annoying aspect of Objective Caml is that it is not currently possible to have natively-compiled dynamic shared libraries written in Objective Caml; all programs will be statically linked to Objective Caml libraries. You can load dynamic bytecode, but that's really just not the same.
There once was a program for wrapping Objective Caml code into a DLL but I don't think it has been kept up to date, it's a dirty approach, and as far as I recall it only worked on Windows.
There's the SCaml effort, but it seems to be falling behind, is incomplete, and only works on a few platforms.

You do realize that MatLab runs in Linux if you're willing to licence it, which it seems you are under windows...

Anyway, a quick freshmeat search showed me that Nulab, Yorick, Scilab, FrAid and Lush are all possible replacements, depending on the application. Moreover, many of those refer to Octave which might be suitable, depending on your needs.

Likewise National Instruments makes LabVIEW for Linux, and freshmeat says to look at Flow Designer and TACO as potential free replacements.

If the two are used for related purposes, then consider RobotFlow which came as a result under both searches...

Just in case you decide to retry the system at a later date...

CeCILL: First French Free Software License
Produced by the CEA, the CNRS, and the INRIA

Paris, 5 July 2004

The CEA, the CNRS, and the INRIA have just produced the first license that defines the principles of use and distribution of Free software in accordance with French law. This license called CeCILL (Ce: CEA (Atomic Energy Comission), C: CNRS (National Center of Scientific Research), I: INRIA (National Institute of Computing and Automation Research), LL: Free Software) is meant to be adopted by French research organizations and more generally by any entity or individual that wishes to distribute its work under a Free software license, with complete legal assurance. This project, welcomed by the Agency for the Development of Electronic Administration (ADAE), enters into the debate on collaborative development of Free software components prescribed by the ADELE (Electronic Administration 2004-2007) government program.

Distributing Free software does not mean giving up all rights to the product: the author and the user each have rights, requirements, and responsibilities that are defined by the license attached to the software. Currently, the majority of French Free software is distributed under Anglo-Saxon licenses, notably the General Public License (GPL), as Free software was first developed in the United States. The project of the CEA, the CNRS, and the INRIA was to produce a license adapted to French law and compatible with the GPL, from which its principles are derived. Its two guiding criteria were:

• The respect of the principles of Free software distribution. This consists of a computer program widely distributed, at no cost or sometimes for a fee, under the terms of a license that authorizes its use, copying, and modification, for its adaptation, improvement, and evolution, benefitting of its author and the whole community. The user's exercising of these freedoms is subject to certain requirements in order to preserve the Free character of the software during subsequent redistribution.
• Its conformity to French law in two respects, civil liability on one hand and intellectual property on the other. Regarding civil liability law, access to the source code and the right to copy, modify, and redistribute coming from such a license is balanced by the fact that only a limited guarantee is provided to users by the author and his successors / beneficiaries. As for French intellectual property rights, the license offers better protection for the authors and copyright holders of the software.

This license is the first of a family based on the same principles as those of other frequently used licenses.

For the CEA, the CNRS, and the INRIA, which play a major role in French and European research, the development of Free software is essential. This license, which conforms to French law, is both a tool for the initial publication and distribution of research in a competitive global context and a tool of transfer to organizations and end users, who are becoming more and more interested in this economic model.

Software is said to be "Free" if its source code is available and freely modifiable and it can be redistributed to third parties, unlike proprietary software. Access to source code allows a community of developers, users, and even commercial partners to collaborate on the software. Thus, they share the high cost of software production and maintenance (customizations and services, for example). Due to this, Free software is constantly improved by the community of developers and users. This is what is frequently called "Free" or "Open Source" software, which is not necessarily zero-cost.

CeCILL: First French Free Software License
Produced by the CEA, the CNRS, and the INRIA

Paris, 5 July 2004

The CEA, the CNRS, and the INRIA have just produced the first license that defines the principles of use and distribution of Free software in accordance with French law. This license called CeCILL (Ce: CEA (Atomic Energy Comission), C: CNRS (National Center of Scientific Research), I: INRIA (National Institute of Computing and Automation Research), LL: Free Software) is meant to be adopted by French research organizations and more generally by any entity or individual that wishes to distribute its work under a Free software license, with complete legal assurance. This project, welcomed by the Agency for the Development of Electronic Administration (ADAE), enters into the debate on collaborative development of Free software components prescribed by the ADELE (Electronic Administration 2004-2007) government program.

Distributing Free software does not mean giving up all rights to the product: the author and the user each have rights, requirements, and responsibilities that are defined by the license attached to the software. Currently, the majority of French Free software is distributed under Anglo-Saxon licenses, notably the General Public License (GPL), as Free software was first developed in the United States. The project of the CEA, the CNRS, and the INRIA was to produce a license adapted to French law and compatible with the GPL, from which its principles are derived. Its two guiding criteria were:

• The respect of the principles of Free software distribution. This consists of a computer program widely distributed, at no cost or sometimes for a fee, under the terms of a license that authorizes its use, copying, and modification, for its adaptation, improvement, and evolution, benefitting of its author and the whole community. The user's exercising of these freedoms is subject to certain requirements in order to preserve the Free character of the software during subsequent redistribution.
• Its conformity to French law in two respects, civil liability on one hand and intellectual property on the other. Regarding civil liability law, access to the source code and the right to copy, modify, and redistribute coming from such a license is balanced by the fact that only a limited guarantee is provided to users by the author and his successors / beneficiaries. As for French intellectual property rights, the license offers better protection for the authors and copyright holders of the software.

This license is the first of a family based on the same principles as those of other frequently used licenses.

For the CEA, the CNRS, and the INRIA, which play a major role in French and European research, the development of Free software is essential. This license, which conforms to French law, is both a tool for the initial publication and distribution of research in a competitive global context and a tool of transfer to organizations and end users, who are becoming more and more interested in this economic model.

Software is said to be "Free" if its source code is available and freely modifiable and it can be redistributed to third parties, unlike proprietary software. Access to source code allows a community of developers, users, and even commercial partners to collaborate on the software. Thus, they share the high cost of software production and maintenance (customizations and services, for example). Due to this, Free software is constantly improved by the community of developers and users. This is what is frequently called "Free" or "Open Source" software, which is not necessarily zero-cost.

Like I said above, that's fine. I find generics tend to lead to sloppier and more confusing code at the expense of saving a couple of keystrokes -- you like 'em for whatever reasons you like 'em for. As a wise man once sang, it takes diff'rent strokes to move the world...

Presumably in Ocaml, you'd override the sort method on a subclass. Seems I have to use objects to get pervasive polymorphism in Ocaml ... something I wouldn't mind, but for the fact that objects come with their own strange set of type restrictions. It's like two languages fighting each other inside Ocaml -- I'd just like one of them to win at long last.

Well yes and no. You're still not getting ad hoc polymorphism. The sort function outlined in my earlier post is still parametric polymorphic with type

(< of_list : 'b list -> 'a; to_list : 'b list; .. > as 'a) -> 'a

type 'a sortable_container =
Array of 'a array
| List of 'a list
| String of string;;

let sort cmp (c : 'a sortable_container) =
match c with
Array a -> Array.sort cmp a; Array a
| List l -> List (List.sort cmp l)
| String s -> failwith "Haven't implemented string sort yet...";;

let a = Array [| 10; 3; 5; 1; 4; 7|];;
let l = List [ 10; 3; 5; 1; 4; 7];;
let b = sort compare a;;
let m = sort compare l;;

val a : int sortable_container = Array [|10; 3; 5; 1; 4; 7|]
# val l : int sortable_container = List [10; 3; 5; 1; 4; 7]
# val b : int sortable_container = Array [|1; 3; 4; 5; 7; 10|]
# val m : int sortable_container = List [1; 3; 4; 5; 7; 10]

Module functors are also supposed to address the issue, but I'm still searching for any documentation of how.

I'm not sure how functors would help you out here either (have you tried asking on the OCaml mailing list there are some serious OCaml gurus there). Functors are just modules parameterized over module types, so you could use one to build, say, a sortable data structure out of one that has no sort function yet, but is a subtype of some other module, but then you would have to do something like:

module SortableDS = Sorting(UnsortableDS);;

let sds = SortableDS.some_initialization_function;;
let ssds = SortableDS.sort sds;;

While at first blush, that sounds like a good idea, from my viewpoint I don't really see how useful or wise that really is. First of all, you could do such a thing with a little bit of work by first wrapping at least the List and Array modules up as objects (something I believe has already been done and is available at the OCaml humps) -- I suppose you might want to do the String and Buffer modules as well, but none of the other standard modules make any sense in terms of sorting. Then you can just define

let sort o = o#sort

< sort : 'a; .. > as 'a

let sort (a : 'a) : 'a =
let l = a#to_list in
let l' = List.sort compare l in
a#of_list l';;

< of_list : 'b list -> 'a; to_list : 'b list; .. > as 'a

The biggest problem I see with a fully generic sort is that it really just doesn't make sense. Arrays and lists are not the same things. For one thing, lists are immutable structures, arrays are not -- therefore, if you define a fully generic sort that works on both arrays and lists, you are now kept from using methods that sort arrays in place (unless you're willing to do the horribly inefficient task of tearing down and rebuilding the list every time you want to modify a value to emulate sorting in place). So now you need to define two functions: one for sorting in place (which can only be used with certain classes of types) and one for sorting externally. And of course certain data structures are more efficient to sort using "method A" than others, blah, blah, blah... (DISCLAIMER: I am not Joe Type-theory, so there is likely a better line of reasoning behind this behavior of OCaml -- go ask someone like Xavier Leroy or Benjamin Pierce if you really care.)

All of this may still be possible to graft onto OCaml (see the work that was being done on GCaml, but I only see a small portion of that really being useful to me. Apparently YMDV, and that's cool...

here are a few good math programs:
Scilab, Octave, r-project, And for making webpages emacs works great ;)

But usually you'd get a TCP stack on the floppy your ISP gave you when you signed up. Like many small ISPs we used to distribute an install floppy containing the shareware version of Trumpet Winsock, which included a PPP dialer. When MS finally came out with a free install kit for making floppies for Windows 3.1 that included IE, the Windows TCP stack, and a nice dialer it was like a godsend (even though we viscerally hated what MS was trying to do with IE).

Look for Caml and OCaml. Ocaml is going strong and is a remarkable language: concise, safe, and about as fast as C. And, of course, there's always Lisp.

MLDonkey written in OCAML, not Python.

Not true, mldonkey is done in Ocaml.

in a lot of higher-level languages, eg functional languages like lisp, haskell and ocaml. But not only debugging: in these languages you tend to write code that doesn't have bugs in the first place. No need for mallocs, no buffer overflows, no memory leaks. And if you're careful to write in a functional style, no "side-effect" bugs (variables that change value when you weren't expecting them to). For a language that started out in the 1950s, it's amazing how far ahead it was and still is as a development environment. This paper is a fascinating read, especially the section on Worse is better that describes why Unix/C won. And there are other languages like the ML family and Haskell. OCaml (Objective Caml, a descendant of ML) is as concise and elegant as python, but produces native-code binaries quite competitive in speed with C, and occasionally faster. I'm wondering why anyone uses C-like languages anymore.

Also remember the moore's law doesn't apply to factoring algorithms.. This is because for the GNFS the *memory* speed is what's important and that isn't growing nearly as quickly..

Not convinced? Look at the linear proportionality in this graph

Simon.

Not sure exactly what this is, but I imagine it makes D into a fully-functional language. Sounds great! It makes me even more interested.

I'd be intersted to see an example of how D's array slicing compares to C++'s interator-based programming. I'm not sure what's being talked about here, exactly.

There's really no meaningful way you can say C++ doesn't have array bounds checking. Come on! What C++ has, which might be much better than D, is switchable array bounds checking. You don't _have_ to check array bounds (e.g. for release builds), but it's trivial to add if you want it.

Conditional compilation At least this gives you some of the power of a preprocessor. But why stop there? Why not have _all_ the power. While you at it, make a cool preprocessor, like O'Caml's, or Lisp's.

Java, among other high level languages (lisp/scheme, Objective CAML, Standard ML, Haskell, etc), are memory safe because they hide the issue of memory management under the carpet by using a garbage collector. Since the language itself does not have the expressive power to deal with memory directly (some has strong type checking that guarantees even stronger memory safety properties), they're considered "safe." However, a clever hacker might handcraft in bytecode, thus bypassing the type system entirely. The runtime system of the language (which you may consider as the operating system in a board sense) still needs to perform dynamic security policy checking.

On the other hand, the critism on Java or any other high level languages as an interpreted language is ill-founded, as those languages can be compiled to run as native executable.

foreach (element, list)
process (element);

(foreach element list
(process element))

List.iter process list

foreach (element, list)
process (element);

(foreach element list
(process element))

List.iter process list

This sounds pretty far off. But you can fudge in some places, like, run the prover a few times on different, failure-prone hardwares, that would reduce the chance of a non-detected hardware error to acceptable levels (you could go exponentially low, say, to 1:10^1000 with a few different hardwares).

The software part is already solved... Just take a look at Coq. It's a manually proven core with proven logics on top. Besides, it can do Extraction by the Howard-Curry-Isomorphism if you do the proof the right way. So, in fact, if you want, you can do a computer-assisted, correct proof.

If you want, you can also do a brute-force algorithm which will certainly find the (correct, manually checkable) proof if there is one, the only problem is that the Problem "prove X" is NP (of course .) and undecideable, so that the running time can be arbitarly long, and might be infinite without a way to know if it is or not. This renders the possibility pretty useless.

Some Problems have been proven by computer, mostly combinatory ones involving a mind numbing amount of similar subcases. Canonical Example here is the Proof for the Four Color Theorem by Appel and Haken.

Functional programming seems to be what you're describing.

It's a different kind of programming than basic/C++/Java. I'm looking into it at the moment. The OCaml language seems especially interesting.

As I understand it, functional programming can be seen as a higher level of abstraction over other languages. Just like C and Java are a bit closer to human comprehension than assembler, functional programming is farther away from the hardware than C/Java but is still as fast or faster.

The best explanation I found was that functional programming is like making an (excel) spreadsheet. When you enter equations into cells you don't exactly tell the PC how to perform that calculation (first get the entered number, convert to a double, then this then that) you just give the cell a certain mathematical equation/function that it needs to perform on the input and you don't care how the computer performs that calculation.

Some advantages are:
- Shorter, more understandable programs
- Therefore, programming is faster than with other languages
- Less bugs
- Free multiprocessing/multithreading with some functional languages, so no special programming necessary for that, this is going to be important in the future, especially in game consoles like the PS3

As I said, I'm still looking into it. For example I don't know why more people aren't using functional programming, probably popularity inertia of the current languages.

A slashdot story about functional languages

Each time somone talk about moving from C to some others languages, we heard about C++, C# or Java. All are kind of OOL, but whatabout typed functionnal programming languages ?

I'm using OCaml every day, for many things (in the CDuce interpreter, see www.CDuce.org, but also in other coding projects.) And it is fast (nearly as C, just take a look at this language benchmark), it is in some way safe (the famous : "Well typed programs cannot go wrong"), it has a good interaction mechanism with C librairies, programs can be compiled in native or in bytecode, OCaml native code compiler is giving very good result on many arch/OS ...

And, speaking about gnome, there's also a "wrapper" for GTK and GTK2 (called lablgtk and lablgtk2.)

You could complain about C all day, the problem is, it's the best thing we have right now.
Hardly.

One of the problem with modern languages is, you can't write an operating system in them.
Sure you can, with little more ASM code than is required for a C-based operating system. Heck, lots of OSs have been written in things like Lisp. Actually, C is a terrible language for writing operating systems. Because its not safe, you have to have an MMU to protect programs from each other. This sucks for performance. Not only do you have the hit of memory protection, but you have to have bounderies between userspace and kernelspace, and between programs. That's why it takes 600(!) clock cycles on my P4 to do something trivially simple like gettimeofday()! If you use a safe language, you don't need memory protection, or even a kernel/userspace boundry for that matter. You get completely fine-grained protection for all objects. See this SF project for an OS written in a safe language.

One of the problems is half the new languages are scripting perl/python like langauges and the rest compile to byte code.
I don't know what's the current fetish with VMs, but most of the really advanced languages (Lisp, ML) compile to well-optimized native code. Look at the recent comp.lang.lisp thread where they ported Almabench to CMUCL, and got within a few percent the performance of C.

Maybe C would go away if there was a compiled langauge that wasn't largely controlled by one company that produced fast code and was portable.
Common Lisp
Another Common Lisp
Ocaml
Scheme
Dylan
Another Dylan

We have lots of languages that are much more powerful than C (hell, they're much more powerful than Java/C#), safer than C, and very close in performance. It is merely a failure of programmers and the software industry that we have not been able to utilize them.

Exactly, there will be "kind of" a functional language - which has to use the same libraries everyone else does, which are all just like the Java libraries. So people using this pseudo-functional language will be hard-pressed to really see the advantages of a functional language as you would if you had a real function language with a set of libraries as broad as that offered by Java.
I heard F# was supposed to be based on OCaml.
OCaml already comes with a nice set of libraries, not to mention parser tools (which I heard were missing from C#). It even has bindings for SDL!
And I don't know why you call it "pseudo" functional.
Although I agree on the fact that the syntax for .NET bindings would probably have to be weird.

Exactly, there will be "kind of" a functional language - which has to use the same libraries everyone else does, which are all just like the Java libraries. So people using this pseudo-functional language will be hard-pressed to really see the advantages of a functional language as you would if you had a real function language with a set of libraries as broad as that offered by Java.
I heard F# was supposed to be based on OCaml.
OCaml already comes with a nice set of libraries, not to mention parser tools (which I heard were missing from C#). It even has bindings for SDL!
And I don't know why you call it "pseudo" functional.
Although I agree on the fact that the syntax for .NET bindings would probably have to be weird.

Exactly, there will be "kind of" a functional language - which has to use the same libraries everyone else does, which are all just like the Java libraries. So people using this pseudo-functional language will be hard-pressed to really see the advantages of a functional language as you would if you had a real function language with a set of libraries as broad as that offered by Java.
I heard F# was supposed to be based on OCaml.
OCaml already comes with a nice set of libraries, not to mention parser tools (which I heard were missing from C#). It even has bindings for SDL!
And I don't know why you call it "pseudo" functional.
Although I agree on the fact that the syntax for .NET bindings would probably have to be weird.

srytch wrote:
>
> Total lack of ad-hoc polymorphism. This language has such a problem with overloading,
> you need a different operator for adding floats than you do for adding ints.

This is a Good Thing (TM). That means that your language isn't going to do implicit conversions from floats to ints (or vice-versa) behind your back. This was an explicit design decision, due to the recognition that the programmer is smarter than the compiler. You are the programmer so you should decide how types are converted from one type to the other, not the compiler. Of course, if you want, and only if you want, you can easily create a composite type and a library of functions that will do all of the conversions for you. Curiously no one has seen the need to implement such a library.

> Lack of compiler warnings. My all time favorite error in ocaml goes like
> "The value is declared type Foo, but is used here with type Foo".

This is covered as the first question in the OCaml FAQ, and personally I have run in to that situation exactly once in my entire experience programming OCaml. So I consider this particular error message a relatively rare corner case... certainly nothing to condemn a whole language over.

> As a better C, ocaml looks great. But it fails to offer many credible alternatives to what
> even ugly old C++ offers in ad- hoc and parametric polymorphism.

Don't even get me started on C++. Instead, start by reading this. C++ is not even in the same league as your average functional programming language, much less OCaml.

Second, ocaml has parametric polymorphism. Read this. And this... google for more. And here's an example of OCaml's parametric polymorphism:

# let f x = x ;;
val f : 'a -> 'a = <fun>

This creates a parametrically polymorphic function, named "f". And here is how you would use it:

# f 3.14159 ;;
- : float = 3.14159
# f "0wn3d" ;;
- : string = "0wn3d"

I only wish that I could use OCaml in my projects. Unfortunately, on 32-bit architectures (read: x86), OCaml native arrays can contain no more than 2^22 elements.

However, if you tend to work with arrays containing 10M elements or more, OCaml just is not an option. (BigArray is not an option unless your data are all numerical.)

Sadly, this restriction rules out the use of OCaml in large-data settings, i.e. most numerical and scientific computing.

Does SML have array size restrictions?

I only wish that I could use OCaml in my projects. Unfortunately, on 32-bit architectures (read: x86), OCaml native arrays can contain no more than 2^22 elements.

However, if you tend to work with arrays containing 10M elements or more, OCaml just is not an option. (BigArray is not an option unless your data are all numerical.)

Sadly, this restriction rules out the use of OCaml in large-data settings, i.e. most numerical and scientific computing.

Does SML have array size restrictions?

Red-black binary tree

Skew-binomial heap

Real-time catenable deque

They're buried in a library containing a lot of other goodies that I haven't ported to all the platforms where Ocaml runs. The data structure modules are pure Ocaml, though- so, you can just lift them. The library is BSD licensed (two-clause), so take all the liberties you want as long as you give me props in your distribution and you can cope with the fact that you get NO WARRANTY from me. (It would be nice if you told me you were using it too-- that would help motivate me to care about timely release of updates.)

* The real-time deque is not technically a pure functional data structure since it uses lazy evaluation for handling concatenation, but- to be fair, a lot of the algorithms in Okasaki's book have a similar property. He is, of course, careful to distinguish the difference between pure and non-pure functional data structures.

Don't forget the wonders of lexical closures, something offered by any self respecting interpreted language.

And also offered by any self respecting compiled language. Just because C doesn't have 'em doesn't mean nobody else does, you know.

Actually, first implementations of generics come from the functionnal progrmming community, esp. Philip Wadler et al. So, the java genericity's genealogy would rather lead to Hindley/Milner type sytems, through Haskell

The fact that most universities and engineering copmanies have these packages readily available is probably why a big reason why open source alternatives have not shown up.

This comment was modded "insightful". Unfortunately it is not true. Depending on what you want to do, there are some highly specialized, hardcore symbolic programs which make Maple, Mathematica, and Mathcad seem like toys. Really, those commercial apps just give you a smorgasboard of basic functions and formulas so as to be considered useful to all. Once you start doing something more serious, you might drop them completely (unless you use their programming languages). If all you're looking for is some general purpose thingie which is a clone of the very popular commercial apps, try the options others already suggested. One I don't think has been mentioned so far is Scilab, which seems to look like Matlab, and looks pretty extensive, though I've never used it. And by the way, the reason why all the specialized programs exist is because scientists and mathematicians find commercial apps largely inadequate for their needs. What's so funny is that this largely parallels the Windows vs. Linux situation-- the commercial players make general purpose, easy-to-use programs which are very pretty and have lots of ohhhhh-ahhhhhh eye-popping features that are very useful for powerpoint presentations.

1. Would it be faster in C or C++? Sure
2. Would the change of a defect increase in C or C+ vs python: Sure, far more chance to screw something up
3. Is it worth rewriting in order to get 1200 million firewall events / day instead of 300 on a single server? Not now - I'd rather keep it in python and just split the processing across two servers than implement in C or C++. Of course, we could always go to psycho, or rewrite small parts first. But eventually, if those steps failed to keep the load manageable, then *maybe* i'd consider rewriting in C/C++.

There are more languages than python and C and C++ (two different languages).

I had a similar issue with some of my log processing apps at work. I prototyped all of the original stuff in python, and in some cases it was taking 23 hours to process the daily logs. I tried various languages for rewrites. I really dislike C as a language, but I rewrote some of the slowest components in C while looking at other languages.

This was a very good thing for me, as it's how I discovered O'Caml. It's a very pleasant language to use...very high level, functional, generic, statically typed (but types are inferred, so you write like you're writing dynamically typed code), and mind bogglingly fast. It's not uncommon to see stuff like this from new users:

http://caml.inria.fr/archives/200401/msg00301.html .

...static typing (as done in Java and C++) cripples your productivity.

Fortunately, programming languages have advanced somewhat since then. In OCaml, if I declare let f x = x#quack (# being the method-call operator), then the type of f is inferred as < quack : 'a; .. > -> 'a, which is a function whose argument is an object that can quack and which returns whatever type the quack method returns. It is, of course, a type error to call f with an object that is not known to quack, and such code will not compile; yet, note the absence of any declared class or interface, or any other explicit type annotation, in the code.

I'm not talking about Python. Python is positioned as a scripting language, and hence doesn't have a powerful compilation infrastructure. Although, Pysco does some very cool dynamic optimizations for Python.

In contrast, there are many high-level languages like Common Lisp, Dylan, Scheme, ML, Ocaml, etc, that have very powerful native compilers. They do optimizations that C/C++ compilers simply cannot do, because of the low-level C memory model. Literally decades of research has gone into making these compilers, and they have optimizations that (while not quite magical) are very impressive.

Variously:

- There are type-inference optimizations that eliminate the overhead of dynamic dispatch.
- There are heap-analysis optimizations that stack-allocate objects whenever possible, to avoid heap allocation.
- There are analysis that avoid heap-allocating closures.
- There are analysis that eliminate type checking and array bounds checking.
- There are analysis that perform large-scale optimization of class heirarchies, to eliminate the over head of OOP.
- There are memory allocation analysis that reduce the overhead of garbage collection (region inference).
- They do method specialization, allowing the C++ template advantage of generic functions optimized for a given type, without actually having to deal with explicit type parameters.

Some useful pointers:

Apple Dylan Wiki
Lisp vs Java vs C/C++ performane
Bigloo Scheme Compiler
Gwydion Dylan compiler
CMU Common Lisp Compiler
UW Vortex Compiler
MLKit ML Compiler
Ocaml Compiler

See GNU Octave and Scilab.

See GNU Octave and Scilab.

An external keyboard for the device

Don't you think that's a little disingenuous?

No, I honestly don't.

I do think that there is a problem here, but I have a different viewpoint on what the problem is. In my view the problem is not the way X behaves, but the way many users behave - expecting X to behave like a different system, instead of learning to use it the way it actually works. I find it far more useful than the alternatives, personally, and I cringe when I see people trying to fix things that aren't broken because they are unwilling to consider the possibility that X has it's own, in most respects superior, ways of handling these things and that they could be a lot more productive if they would learn them instead of breaking them to 'fix' them. In particular because it results in a very degraded 'user experience' and usability, for me, when I run into the ever increasing number of programs that do this.

When I'm writing reports, I frequently switch out to Excel to generate a chart which I then copy and paste into the Word document.

I've done this, and my coworkers do this - and I've seen it cause problems. For instance, graphs that are pictures when you want them to be actual graphs, and vice versa. Not that I'm disputing that it can be mildly useful at times - but when you realise that implementing it in X means breaking a very clean and useful paradigm, and that the lack of it just means you save the chart in the format you want, then import it to the document - it's a feature I'd rather do without. I think the negatives outweigh the positives.

Obvious he wasn't using one of the new windows keyboards

If programming that big project is like trying to cross the Sahara then discriminating hackers choose a caml. It's unlikely to get bogged down, overheat or require dozens of volatile tank expanders.

My current spam filter is SpamOracle. It's a simple procmail filter based on Bayes' formula. It's really efficient, I haven't had a spam mail in my inbox for a week. The only bad thing is that it's written in ocaml which might not be on everybody's machine. Mandrake users can install a contribs package and don't need ocaml at all.

I've noticed that the home page is kind of slow. There's the original, old one at INRIA.

HTH

As far as I know, many of those filters are based on a decision rule of the form

P(mail is spam | words X, Y, Z, ... are in it) > 1-epsilon

The computation is then done using Bayse's rule (P(A|B)=P(B|A)*P(A)/P(B)) under certain independance assumption which makes it tractable.

So this is actually bayesian filtering ...

My favorite filter is spamoracle

What about OCaml ? (See the last item in "news" for a "benchmark")

But why? Are there really enough interested
people to justify a book about ~planned~ changes
to Perl? Yikes. I really don't understand most programmers.

Why not print the O'caml book: Developing Applications with Objective Caml
(the ICFP contest champ).