Slashdot Mirror

Another recent paper by the same research group shows that it's often possible to identify an individual using BitTorrent through Tor, because the BitTorrent protocol leaks their true IP address, and their other traffic (such as webmail) passes through the same Tor tunnel as their BitTorrent traffic.

Perhaps I'm exposing my own ignorance (because I've never felt the need to use Tor myself) but that strikes me as surprising if it's true. And something that even savvy internet users might not think about.

The sawy internet users are kindly invited to read the paper on weaknesses of BitTorrent over Tor to reduce their level of ignorance. There are 2 passive ways and an active way (running a Tor exit node) to exploit "BT leaks" (not really leaks since it wasn't designed with security/privacy in mind).

And for all those languages, nobody wants to implement a DirectX wrapper library. Since you can’t use it on any platform other than Windows anyway. And so it’s an annoying waste of time.

Oh really?

DirectPython
Java3d
DirectX SDK For Delphi
DirectX Bindings for Haskell
OCaml library that uses DirectX

In the long run, DirectX will go the way of Internet Explorer 6.

Such has been claimed since the mid 90s and all who have claimed such have been wrong over and over.

``It's hard to place the language in any camp, because it does furnish functional programming and object-oriented features without really committing to the dogma of either one. It gives you a ton of interesting features that seem to work really well in concert''

There actually is a camp for languages like that. They're called multi-paradigm languages, and I believe a language that can elegantly express many paradigms is a Good Thing. Languages commonly considered to be multi-paradigm include Ruby, Lua, Common Lisp, and OCaml.

Now, when he says "truly correct", I'm assuming he doesn't mean formal proving. That would be absurd, especially for an operating system as complex as Windows or Linux (or really anything with limited resources). Anything short of the formal proof and you just have empirical evidence that it works - but if there's a billion branches and trillions of code paths, nobody will hit all of them with all data.

I used to hear similar sentiments with regards to compilers. Check out Xavier Leroy's work: http://pauillac.inria.fr/~xleroy/ Yeah, that's mainly the work of one guy; his students' work is related, but not necessarily in support of his project.

There are a lot of us who are spending serious time understand Coq et al. because formal verification is advancing to the point where if you don't understand the technology and how to use it, you're going to be out of a job.

In case you're thinking of starting such a book, I present a handy guide on how to write English. You might also want a collection of words to demonstrate how easy it is to pronounce English.

In case you're thinking of starting such a book, I present a handy guide on how to write English. You might also want a collection of words to demonstrate how easy it is to pronounce English.

Your discussion of classes is confusing, as OCaml doesn't have them.

The OCaml documentation says otherwise...

• LablGTK. GTK on Windows. Yuck.
• LablTk. Tk is a toy GUI kit.
• OCaml-Win32. If you have to ask what's wrong with the win32 API, you've never had to use it in a language other than C.
• Some alpha or out of date binding of wxWidgets or Qt for OCaml.

OCaml programs aren't shorter than scripting languages, and they're limited to a curses interface at best. Together with its speed, OCaml gives off the impression of being a language you'd reach for when you write high performance, low interaction programs---like automated financial trading agents. Not many of us do that. And so not many of us use OCaml.

You're a funny guy but obviously have zero idea about what you are talking about. It's a bit aggravating that ignorant folk still come out with the same old 'slow' mantra and unfortunately even more ignorant folk buy into it. That keeps people writing crappy software on C++ or C when quite often Java would be a good fit for them and the performance is mostly a non-issue these days (unless you write very inefficient programs).

I used to eschew Java for the speed of C++ but now I've completely switched to Java for most development tasks (apart from some C glue-code [JNI] when I need to integrate some scientific instrument or another). I'm doing instrument control, image processing and analysis and I need both reasonable latency, multithreading support, and every performance cycle I can get, and yet Java is plenty fast enough for me (and even embedded devices these days have relatively large amounts of RAM this is far less of an issue than it used to be).

Seriously Java is very fast these days. Graphics2D is all done in Direct3D or OpenGL shaders, the VM is very optimised and quite often approaches FORTRAN (which is faster than C). Don't believe me? check out the links below.

So please, next time stop with the FUD (that used to be marginally true 5 years ago) and start with an open mind.

• From http://en.wikipedia.org/wiki/Java_performance#Use_for_High_Performance_Computing
  "However, High Performance Computing applications written in Java have recently won benchmark competitions. In 2008, Apache Hadoop, an open source High Performance Computing project written in Java was able to sort a terabyte of integers the fastest.[46]"
• INRIA (French scientifc Institution) report on High Performance Computing with Java [Summary: Java approaching FORTRAN for speed, although some network intensive speed bumps still remaining]
  http://hal.inria.fr/inria-00312039/en
• From http://blogs.sun.com/jag/entry/current_state_of_java_for
  Current State of Java for HPC
  
  At the last JavaOne I did a walk-on talk during the AMD keynote where I talked about how incredible HotSpot's performance had become - beating the best C compilers. I ended my talk with a joking comment that "the next target is Fortran". Afterwards, Denis Caromel of Inria came up to me and said "you're already there". He and some colleges had been working on some comparisons between Java and Fortran for HPC. Their final report Current State of Java for HPC has been made available as a Tech Report and makes pretty interesting reading. There are a lot of HPC micro benchmarks in it which look great. Thanks! Permalink Comments [3]

"Well, NT didn't work to begin with, that was the problem" - by Chasmyr (1261462) on Thursday April 30, @06:45PM (#27780347)

NT worked fine to begin with, especially with the equipment certified for it by MS, in its day 1993-1996: This is certain!

(Hardware Compatibility Lists, anyone? WHQL (Windows Hardware Quality Labs) testing as well...)

NT 4.0 onwards, thru 2000, XP, Server 2003, Vista, Server 2008, & soon Windows 7 all/each of them, have their own HCL!

(& possibly NT 3.5-3.51 may even have one also, per this possible evidence thereof, here in the next url below, & this quote from it, from the year 1996:

----

http://bat8.inria.fr/~lang/hotlist/free/abuse/askdrbob-jan96.html

"If a machine is on the HCL for NT 3.5, that doesn't imply that the machine will run later versions of NT."

----

Now, for NT 3.51?

IIRC, I downloaded it from MS' old FTP site ftp://ftp.microsoft.com/bussys/winnt/winnt-docs/hcl/

(& it had a lot of equipment on it that was proven to work with it (especially NT 3.1-3.51, because they were new & had Win9x competition too))...

See here, for all the lists of Microsoft OS that have an HCL -> http://www.microsoft.com/whdc/hcl/default.mspx

NT 4.0's there, alongside even older Win9.x series... & leads to this example thereof -> https://winqual.microsoft.com/download/hcl/NT40xHCL.txt

APK

P.S.=> In other words, there are literal LISTS of tons of devices that "NT Worked with", though you said it did not work (it could be very stable & was Orange Book C2 Secure level granted secure as well)...

So!

That "all said & aside"?

I must ask you a question:

Had YOU ever used Windows NT 3.1-4.0, yourself, & especially back in the days it came out circa 1993-1996? apk

Most the papers written by french CS researcher can be accessed online in the HAL-INRIA database. ArXiv is also widely used in physics.

I would say OP should broaden his mind and learn a functionnal language such as caml. He will probably never use them professionally but they are so enlightening.

The French public sector (much bigger in proportion than the US one) did contribute significantly to opensource software (for example, the first linux thread library and Ocaml has both been written by a French public sector researcher, Xavier Leroy, and you'll find thousands of other cases, like Frama-C.).

Also, French government did issue several contracts (outside of Gendarmerie) to support opensource software, and did pay development of significant applications. My perception is that the French government is supportive to open-source.

At last, French private sector is increasingly contributing to opensource projects (for example Penjili at EADS or Airbus).

Unfortunately, several French government sites are using proprieray (non-standard) technologies (like Flash at Assemblée Nationale - the lower Parlement Chamber).

The French non-profit APRIL association is quite powerful at lobbying for free software.

What about taktuk or kanif ? They are tools over ssh used to propagate files. I use them to ready machines for MPI run. They can be used to use broadcast tree or pipelining, they can use proxy command to connect to strangely configured machines...

Or perhaps by "without having to ssh into each and every machine on the network." you meant pulling the files instead of pushing the files ?

What about taktuk or kanif ? They are tools over ssh used to propagate files. I use them to ready machines for MPI run. They can be used to use broadcast tree or pipelining, they can use proxy command to connect to strangely configured machines...

Or perhaps by "without having to ssh into each and every machine on the network." you meant pulling the files instead of pushing the files ?

ProofWeb http://proofweb.cs.ru.nl/ is an IDE-like system for teaching logic and formalized proofs through the web. It was designed for teaching logic to undergrad CS students, but it's been successfully used to teach proof assistant courses.

While ProofWeb's database is limited to simple logic exercises, it is actually based on the Coq proof assistant http://coq.inria.fr/, which can be used to develop software in an interactive way and even certify that it meets a formal specification. (It uses a functional programming language, similar to Haskell or ML.) My guess is that an extended version of this system could be very useful in CS and software engineering.

For a while, I've been using the Linbox Converter [0]. Running on a dedicated Windows server with MS Office installed, it can convert documents sent over the network into âoecleanâ PDFs by print-to-file'ing them, and sending them back.

This is not exactly what's required here, as I suppose the documents have to be editable. The glue to make the system run, however, is mostly written in Python. This may make adding functions like saving as an earlier version of the format (âoebye bye OpemXMLâ) quite easy to implement.

There are Unix and Windows clients available at [0], but I once did a bit of packaging to make the installation of clients easier [1].

(Disclaimer: I once was an intern at Linbox, and did not conduct an unbiased survey of such solutions before deciding to use the aforementionned one. It turned out to work well enough for my needs, though.)

[0] http://www.linbox.com/en/converter
[1] http://gforge.inria.fr/frs/?group_id=424&release_id=897

I think we all could take a cue from the French, and start some of our programming classes in one of the ML families, like Caml Light, Standard ML, or my personal favorite Ocaml. These are fairly advanced languages, and support both imperative and functional features, so you can teach for loops AND recursion. Of course, you can do this with Lisp too, but honestly, the syntax of the ML families is a lot better than Lisp. Also you can do object-oriented programming with Ocaml.

In addition, Yale also taught its intro CS class in Standard ML a while back, and I understand it was a big hit.

Of course, it's the course content that matters the most, but why limit yourself? As already stated on Slashdot, FP is increasing in importance due to its ability to handle parallelism, so I think you can really have the best of both worlds with these impure functional languages.

I did try OCaml a little while back, reasoning that because it supports mutable state, it would be easier to learn. It was. I ended up writing procedural code in it, which rather defeated the whole point.

Ocaml was a nice transition language for me. I got used to ML syntax and functional programming ideas, but I could fall back on imperative concepts if I got stuck. This book helped a lot to show how to get stuff done in a number of different styles.

Haskell's the best option that I know of, but the syntax is rather weird to anyone who's used to languages like C or Java. Are there any other lazy, strict functional languages that aren't descended from the ML family that I should look at?

There may be, but none that I'm familiar with. Syntax you can get used to if it's consistent; that's one reason I prefer haskell to ocaml, the former (in my view) has a better thought out syntax. (Ocaml's revised standard form seems to be a lot better than the default syntax, but the existence of a whole cottage industry in the ocaml world around camlp4 scripts to modify the syntax should be an indication that something is wrong.)

That said, there are some common coding idioms in haskell that I've just never gotten used to. The "$" operator I have come to appreciate, but "." just seems confusing. I think the best approach if you're writing code from scratch is to just use whatever syntax seems the most straightforward at the time, and ignore whatever you don't need to get the job done.

If you're still willing to give haskell a go, I'd recommend "The Haskell School of Expression" as a pretty good book on doing things in a functional way. It's perhaps a less good book if you don't want to write just pure code, but want to understand IO, state, and monads in depth as well (for which "Real World Haskell" is perhaps a better choice).

So if C is too slow, what language do you use when speed matters? Literally just curious

To be fair, I didn't actually say that C is too slow. I questioned whether glib's awful abstractions slowed things down, and asked if anyone had benchmarks.

Nevertheless, I'll plug OCaml here. It's about as fast as C and far nicer to use. As I mentioned in another comment, you can use C to fine-tune the layout of OCaml structures in memory to get maximum performance.

Rich.

For example, some of the following: OCaml, Python, Ruby, C++, D.
But there are really lot of them available. What's best, depends on what you try to do and your taste.

OK, so why is it so hard to create a hybrid language?

It's not hard, and there are plenty of them:

• Objective Caml
• F#
• Nemerle
• Scala
• Clojure

From the list above, OCaml is presently production-quality, and used rather widely. It also has a good performance profile, rivalring C/C++ with carefully written code. Of the others, the fastest-growing seems to be F# (mostly because Microsoft announced that they're making it into "Visual F#" and likely including it into Visual Studio 2010 alongside C# and VB as the third out-of-the-box .NET development language). Scala has a pretty large following in the Java land, so much so that some call for freeze of Java language spec for the sake of stability, and moving onto Scala for further language development.

Also, most modern dynamic languages (Perl, Python, Ruby, JavaScript) have many functional traits, and so do quite a few mainstream static ones (C#, VB).

As an example of the learning curve, I wanted to learn a little OCaml. I played around with this insertion sort example. I used it to sort a list of 10,000 integers, and it took 10 seconds, versus <1 second in C with linked lists. Not too horrible. But changing it to 100,000 integers made it die with a stack overflow, so I'm guessing that its memory use goes like n^2. However, it's not at all obvious to me from looking at the code that this would be the case. I think if I wanted to do a lot of OCaml programming I'd have to develop "FP Eye for the Straight Guy." Probably if you wanted to make it perform better on big arrays you'd want to make it tail-recursive, but it's not totally obvious to me from the code that it's *not* tail-recursive; although the recursive call isn't the very last line of code in the function, it is the very last thing in its clause...?

I know of at least one well known OSS project in Haskell, written by a very smart guy, that is really struggling with performance issues. I wonder whether bad performance is to FP as null-pointer bugs are to C. Sure, a sufficiently skilled programmer should theoretically never write code that will dereference a null pointer, but nevertheless my Ubuntu system needs a dozen security patches every month, many of which are due to null pointers, buffer overflows, etc.

1) You didn't read what I wrote in what you first quoted of mine. Please actually read before replying to someone.

La la la la, I'm not listening... *plugs ears and sticks out tongue*

2) I'll paraphrase from the Tao: Though a program be but 3 lines long. Some day, someone will have to maintain it. Similarly, no matter how small a program is, it will contain bugs.

Oh really? Here's a three line program in the simply typed lambda calculus with algebraic data:

data Nat where
Zero : Nat
Succ : Nat -> Nat

two = Succ (Succ Zero)

Where's the bug? Oh, that's too trivial for you? Let's try another:

data Nat where
Zero : Nat
Succ : Nat -> Nat

add : Nat -> Nat -> Nat
add m Zero = m
add (Succ m) n = Succ (add m n)

I can *prove* my add function correct here by induction on the second argument. Similarly, I can *prove* that it's an associative and commutative operation. Where's the bug? Oh, you didn't realize you can prove properties about software? Oh, you mean you were full of shit all along? Oh, I see.

By the way, purity (look it up) in proofs and proof irrelevance (look it up) mean that you don't have to "maintain" a proof in the same way you have to maintain some toy piece of software written by some amateur hacker.

3) Having to go in a check the checker defeats the purpose of the checker.

Just like checking your proof defeats the purpose of you having written it, right? Oh wait, have you ever actually written a proof of anything? Have you ever written a *formal* proof of anything? Personally, I doubt either case is true. I think you're the kind of person that sits there and reads about mathematics in popular science articles and then comes on slashdot and tries to act like you're some sort of expert. Maybe I'm wrong though. Perhaps you would be so gracious as to give us some details on your past conquests in formal proofs, or the formal, axiomatic, correct mathematics you referred to earlier.

4) It isn't my job to check the checker. Nor is it any Mathematicians job to check the checker.

Really? I happen to know several mathematicians whose paychecks are causally related to their work on ensuring that various proof assistants are correct. Here are a few of them:

INRIA TypiCal Team

Isabelle at Cambridge

Programming Principles and Tools at MSR

This is only a very, very small sampling of some of the people involved in working on proof assistants and related technology. There are hundreds, potentially thousands of others that use them in secondary projects such as in industry.

These people range from being traditional classical "working mathematicians", to logicians, to computer scientists.

Your claim about mathematicians here is a bit laughable, in part because you have zero credibility -- you haven't responded to a single claims of mine, probably because you can't. You haven't demonstrated how you are in any way representative of the so-called "Mathematician".

5) Re: well defined "A sufficiently well behaved function": You're taking what I wrote completely out of context (see (1)). Note the ()'s after that in which you quote: rigorous within context

I could go on, but I won't waste my time with someone that clearly hasn't actually read what I wrote.

I don't think you personally are capable of even giving a definition of a "well-behaved function" in ANY context, so it's a moot point. Most competent mathematicians, logicians, or computer scientists would have no problem giving such a definition, if it were sensible to do so, but they also wouldn't make the asinine cla

For what it's worth, I've had good experiences with coq: http://coq.inria.fr/ Although I've never used it for anything large, it has the nice ability to make proofs about code, and export the code to haskell, scheme, or ML. I had a fun time proving that the min function always returns the lesser of the two values.

Even nicer than preview-latex: Whizzytex

http://cristal.inria.fr/whizzytex/

``It is unfortunate that the mono is so closely associated with Windows, if the mono team had created/implemented a
completely new set of cross-platform libraries (that bore no relation to Microsoft's framework) it would be more accepted.''

But then they would just have done what various others have already done, wouldn't they?

I think that one of the most interesting developments of C# and most mainstream programming languages is that they keep borrowing long-established elements of functional programming.

All and all this is a positive development. The only irritating aspect about it is the number of Microsofties who think M$ is inventing new stuff and being "innovative(TM)". A good example of this is F#: while the language is basically an adaptation of Ocaml to the .NET environment (to the point that simple programs are indistinguishable), I've seen plenty of people touting F# as the best thing since sliced bread, but completely failing to mention its roots, or the fact that Ocaml is a well-established language with a long history, and perhaps the most successfull (in terms of actual usage in the industry) of functional programming languages.

(Though I give credit to the interviewee in this particular article for being an exception to this rule, and for acknowledging F#'s pedigree).

Incidentally, this has long been a burning question for me: why is a language like Ocaml ignored to such an extent within the mainstream open-source community? It already has a small but vibrant community, excellent coverage in terms of libraries, performance comparable to C++, and the safety and cleanness that comes with functional programming. I even see Linux people excited with F#, seemingly oblivious to the fact that we *already* have a language better than F# that runs natively under Linux!

(Note: I consider Ocaml to be superior to F# because in the process of transforming Ocaml into F#, Microsoft removed two of the most interesting and powerful features of Ocaml: functors and polymorphic variants)

It's a pretty much work. A lot of 'obvious' English sentences translate to bulky code for proof verifier.

Just look at the definition of Peano arithmetic, for example: http://pauillac.inria.fr/coq/V8.1/stdlib/Coq.Arith.Plus.html

API: http://caml.inria.fr/pub/docs/manual-ocaml/index.html
Tutorial (and excellent reference in general): http://www.ocaml-tutorial.org/

C#/.NET - http://msdn.microsoft.com/
Haskell - http://haskell.org/
Nemerle - http://nemerle.org/
OCaml - http://caml.inria.fr/
PHP - http://php.net/
Python - http://python.org/
Ruby - http://ruby-doc.org/ (API docs), http://ruby-lang.org/ (for more links and info)
SML - http://smlnj.org/ (the most popular implementation), http://standardml.org/Basis/ (standard library)

(X)HTML/CSS/DOM/XSL/etc. - http://w3.org/

Hm. Now that I've written it down, I see most of these are obvious, but then it makes sense, that the "official" sites tend to be the best reference.

But you do see that. :) Everything casts shadows on everything (unless it's been specifically disabled by the artist).

If that's true, then where are they? I have yet to see a gameplay example where a soldier casts a shadow on himself. You can see a soldier's shadows on the ground, plants, buildings, and in other areas, but never on the soldier himself.

Crysis has completely uniform shadow mapping.

I don't think that means what you think it means. A uniform shadow map is a shadow map that's effectively fixed regardless of perspective. This is inferior to raytraced results.

This is exactly the same as ray traced shadows, the only difference is quality and power requirement.

You keep repeating that, but it's simply not true. Shadow maps only compete with raytracing if you spend the computational power to project a shadow for every polygon in the scene for nearly every frame. Game don't do that. It's far too expensive.

There's a good discussion on the Crysis shadowing technique over on the OGRE3D forums.

I have a feeling you may be thinking of projected shadows which do indeed have a few of those attributes (they suck).

Shadow maps ARE a form of projected shadows. That's why they're also referred to as projective shadowing.

I have to admit, I don't see what is frustrating about this. Perhaps it's because I'm an academic game theorist, and not a psychologist.

"In other words, I'll be impressed when someone is able to pin down what makes one shape strong and another weak precisely enough to put it in an algorithm."

It's as simple as this: one shape is stronger than another if it leads to a win more often than the other. What else would one want? The computer is trying to win. Therefore, it chooses one move over another if that move is more likely to win. That's what humans do, too, when evaluating the strength of positions.

And by the way, I think MoGo does more than just simulate.

I think we are basically in agreement.

As another poster noted, I was thinking more of Scheme, and not Lisp in general. The power of Scheme, (and what I perhaps incorrectly projected to all Lisp) lies in being able to express anything (multiple-entry-exit procedures, indexed jumps, switch/case, loops, while/break, gotos, exceptions, co-routines, etc) using just the fundamental language constructs - lambdas with tail-recursion and continuations. Perhaps more importantly, besides emulating most constructs from other languages, it allows for powerful new ways of expression which are impossible in other languages. Combine that with macros and you have the ultimate power. (Of course, it is a pity that there isn't a single usable Scheme implementation (well, probably with the exception of Bigloo http://www-sop.inria.fr/mimosa/fp/Bigloo/ )

So, from that angle, JavaScript is much closer to Java and C than Lisp-1.

On the other hand, closures and higher order functions are not necessarily Lisp specific. You can write the Y Combinator in SML, etc.

Indeed. In fact, most of the interesting algorithms come with a proof of correctness and termination. The problem is, traditional programming languages are not expressive enough to specify and prove termination within the language itself. But there are many ways to achieve this : either annotate the program with logical assertions, allowing an external automated demonstration program to *try* to check soundness and completness; or program directly with Coq or PVS. Some links : http://why.lri.fr/ & http://coq.inria.fr/.

apt-get is not perfect. In fact, you may call "a hack." I don't think there's any real "theory" behind it. apt-get may even remove a user's kernel package, as one of the 600 traces in this study reveals:

OPIUM: Optimal Package Install/Uninstall Manager

http://pho.ucsd.edu/rjhala/papers/opium.html

Also worth reading are:

Search heuristics and optimisations to solve package
installability problems by constraint programming

http://www.info.ucl.ac.be/~pvr/report_ingi2800_C.pdf[pdf]

Maintaining large software distributions:
new challenges from the FOSS era

http://pauillac.inria.fr/~xleroy/bibrefs/EDOS-FRCSS06.html

where they mention "Theorem 1 (Package installability is an NP-complete problem). Checking whether a single package
P can be installed, given a repository R, is NP-complete." (result is to be published elsewhere, though).

JoCaml is an extension of OCaml that supports concurrent and distributed programming through the use of the Join Calculus. Unlike other, more well known, process calculi such as CCS and Pi-Calculus, Join Calculus was design to allow efficient implementations.

The basic model is message passing (ala Erlang), but the killer feature is that you can specify "joins" -- think of them as functions that get called when a specific combination of messages are received. I managed to convert a single-threaded simulation into a parallel version that distributes over an arbitrary number of cores/computers in less than three hours. I'm not saying it's a silver bullet or that it's ideal for your next project, but it worked damn well for me. The underlying calculus could be implemented in other languages, although it probably works best in languages with good match statements, such as OCaml and Haskell.

JoCaml is an extension of OCaml that supports concurrent and distributed programming through the use of the Join Calculus. Unlike other, more well known, process calculi such as CCS and Pi-Calculus, Join Calculus was design to allow efficient implementations.

The basic model is message passing (ala Erlang), but the killer feature is that you can specify "joins" -- think of them as functions that get called when a specific combination of messages are received. I managed to convert a single-threaded simulation into a parallel version that distributes over an arbitrary number of cores/computers in less than three hours. I'm not saying it's a silver bullet or that it's ideal for your next project, but it worked damn well for me. The underlying calculus could be implemented in other languages, although it probably works best in languages with good match statements, such as OCaml and Haskell.

I, for one, sincerely hope that C++ is indeed losing ground. The language started already on the wrong foot (making it backwards compatible with C was a terrible mistake) and has since become the ultimate cathedral of rococo horror.

(Have you noticed how most (relatively) sane C++ developers tend to use only a subset of the language? And how C++ dev teams inevitably run into problems when the subsets mastered by different programmers are disjoint?)

Note that I did dabble in C++ for a number of years. But now, I only regret not having discovered Ocaml sooner. Though a functional programming language, it isn't one useful only for academic wankery. Quite on the contrary; it's very pragmatic in its design, supporting also imperative and object oriented programming. And by virtue of its very expressive and strong type system, it makes programming far safer than in C++ or even Java (no "null pointer exceptions" or that sort of runtime failure). Moreover, it is a very fast language (comparable to C++ in terms of speed) and has an excellent coverage in terms of available libraries.

So you will pardon me if I don't shed a tear on news of C++'s impending demise...

Ruby and Erlang are the two I've spent the most time with so far. I like Ruby enough so far, that I've decided to write the initial
batch of install scripts for OpenQabal in Ruby.

Outside of that wish-list, I also harbor some vague hope of one day finding time to dabble with Forth, Fortran, Perl, and maybe Dylan.

• Lambda calculus-ish
  • Scheme
  • Haskell
• Combinator/Forth-ish
  • Joy
  • Interesting but not practical: unlamdba iota and jot
• Logic
  • Prolog
  • Mercury - compiled and pure
  • Lygon - prolog like linear logic programming.
• Pi calculus-ish
  • Join calculus
  • Nomadic Pict

I think I want to master logic programming next, though it may be better for me to do some haskell programming first so I have a better foundation. Monads/Arrows give me a headache, but with enough time, I'm sure I could get used to them. s-expressions a-la lisp/scheme are very similar to xml, except better, but logic programming seems more likely to make the hardest parts of internet programming easier.

Unfortuately, I have nowhere near enough time to get proficient in all these languages.

Give Objective Caml a try.

I used to be a die-hard C/C++ programmer, and I figured I'd never be quite as comfortable in another language. These days, though, I don't feel productive unless I'm using OCaml. You won't realize how broken and clumsy most mainstream languages are until you learn OCaml or one of its ML relatives. It takes some time, but it's worth it.

And yes, you can actually write real programs with it!

Thanks for mentioning that. Your post has prompted me to finally set up a page for TurboVM, a virtual machine I have been working on. What makes TurboVM interesting is that it's (1) small and simple, (2) not tied into a programming model like typical VMs that are designed with a single language in mind, and (3) FAST.

There is a bytecode interpreter which seems to outperform OCaml's (widely considered fast) by about a factor 2 to 3, and a compiler that compiles bytecode to C which can then be compiled to native code and will run about as quickly as an equivalent program written in C to begin with (everything compiled with maximum optimizations). An assembler and a disassembler are also provided.

All this is in a pretty early stage of development, not very well tested (I think some of the signed operations are wrongly implemented), poorly documented, and lacking features (right now, programs are just instructions...I want something with sections, labels, linkable libraries, etc.), and so on, but you can download it now and it compiles and runs. I hope some of you will be as excited about it as I am. :-D

Mogila (1986) reported a field study at the Monastery of the Caves, Kiev, where conventional sub-surface radar had failed to locate secret passageways. Of 130 sites indicated by dowsers, 73 (56%) corresponded with existing passages, previously known to the curators but not to the dowsers. At a further 29 dowsed sites (22%), previously unknown to the curators, test drillings revealed cavities. This gave a total success rate of 78%.

so not ALL studies have been found against the technique, but it is definitely not proven for sure.

Pycaml is a Python binding for OCaml. From their website:

"If there's a native library you want to use that has a python wrapping, for very little extra cost, it can have an ocaml binding. This also means that ocaml code can import pure python modules and use them, making it ideal for using to implement test-case code on event processing systems. [Pycaml also] allows ocaml code to embed the python interpreter, define modules, classes, structures, etc."

If you want to use C and/or C++ libraries in OCaml, you can use SWIG. See SWIG's OCaml docs for details.

As for LDAP in particular, there's OcamLDAP. OCaml has many other native libraries. Check out the the OCaml Hump.

Ah, the title seemed promising: someone had come to the conclusion that there is a world outside of the Rails hype-machine. Perhaps they were telling us to look into the truly innovative frameworks, such as Lift (for the Scala language), or even Ocsigen (for the OCaml language). But no. They decided to go back to PHP!? I am confused: is this story about S&M fetishes?

I have been using Ocsigen myself for a few months now. It is based on OCaml, so it's very high-level while still being extremely fast (it can be compiled into native code, comparable in speed to C++). Moreover, OCaml has very strong types, and Ocsigen leverages that type-safety to ensure the produced markup will always be Xhtml compliant and that there are no inconsistencies or broken links within a website. Heck, you can even extend that type-safety into the database access, so there is no chance that you'll be processing data the wrong way. And best of all, all mistakes are detected at compile-time! It really is a pleasure to use...

If you had really complete freedom and were willing to try out something radically different from existing frameworks, I would suggest you would take a look at Ocsigen. It is based on the OCaml language, which alone implies a different mindset from traditional frameworks based on imperative languages. Some of Ocsigen's cool features:

• Extends the OCaml type-safety into the generation of XHTML. This means that producing valid XHTML is not only "nice", but actually enforced by the framework: your programme won't even compile otherwise!
• The entire site is seen as a programme where each public URL is a function. The OCaml type-safety is extended to forms and internal links, meaning there can't be any inconsistencies whatsoever.
• With database bindings such as PG'OCaml, you can extend the type-safety also to database access. Think about it: the compiler checks at compile-time if your programme is consistent with the database itself!
• Functional programming is very high-level, which means rapid development and happy programmers.
• It is fast. And by fast I mean really, really, fast. How would you like your web framework to generate native code whose speed is close to that obtained with C?

Sorry if this sounds like a sales pitch, but I would just like to point out that there are wonderful technologies out there, if people were just willing to take a step outside the trodden path.

Ocaml doesn't support true concurrent programming. Threads in Ocaml will only run one at a time, even if you have 80 cores. Apparently, it's a deficiency of the garbage collector they use. Jocaml is an Ocaml extension to support concurrent and distributed programming. Speed-wise, wasn't there some controversy over the benchmarks testing more of the performance of Ocaml's imperative features rather than its more interesting functional programming features?