Slashdot Mirror

OCAML is much more expressive and safer than C++. Think of it as always programming in templates. It has an IDE too called Cameleon. I guess the one thing it lacks from your feature set is operator overloading.

OCAML is much more expressive and safer than C++. Think of it as always programming in templates. It has an IDE too called Cameleon. I guess the one thing it lacks from your feature set is operator overloading.

Short, obviously english inspired, but clearly understandable. I'm
sure your trip went well, hasn't it?

Persistence: Not sure about memory-mapped files - these lack
transactions, queries and those other good 'enterprise' features. I
think you're closer when you mention meta-programming further down.

Alot of the issues you are bringing seems to involve difficult
tradeoffs of memory usage, safety and performance. This would explain
why they are not making way into language support. This is were
metaprogramming comes in nicely : once you have picked a library which
implements the balance you are looking for, if its syntax is the
simplest and cleaness, can ensure a more regular usage across your
programming team.

Anyway, the idea is that the process state is preserved
without the kind of explicit programming involved in a workflow system
- 'business process' and program process are congruent.

Oh, I see now. You want programmable access to coredumps. mm, tricky.

OCAML: I've heard really wonderful things about this, but people tend
to emphasise the type-safety and functional programming aspects. I'd
certainly like to check out the meta-programming-like features to see
how far it could be turned into 'enterprise programming nirvana'!

The caml's meta-programming tools and called camlp4. I also got excited
about openc++
and its sister openjava.

Commercial information tends to be persistent, not transitory. A good language should work directly with stored data.

Is that you wish your developers used more memory-mapped files rather than file streams?

Processes in organizations are long-lived and distributed, whereas typical programming languages just deal with transient threads etc. (outside workflow systems such as WebLogic Integration).

Check out channels threading primitive. Although I'm not sure what you mean by transient threads.

Programs represent rules, algorithms and other forms of knowledge that end-users will want to add to (e.g. a discount formula). Not only should the environment allow run-time modification and extension, it should also support representations and syntaxes accessible by non-programmers.

You would like languages that ship with an interpreter within the library, like lisp.

Although I clearly don't understand everything involved in the rest of the examples you give, it seems to me they can be solved with either lamba's ("SQL-style set predicates") or meta-language extension.

I would sugest you check out ocaml, which a natively-compiled, c++ fast, safe web enabled language with a browser applet plugins (if thus is your focus). Very buzzword compliant, very worthy.

Serialization is called Marshalling in caml. Check it out.

I know that we sometimes live with legacy code; fair enough. But I claim that it is entirely inappropriate to write security-critical internet daemons in C!

There are lots of people here claiming that this is caused by sloppy or inexperienced programmers. I think that this is bullshit. Are the authors of wu_ftpd bad programmers? BIND? IIS? perl? telnetd? quake 3 arena? sshd? All of these have had remote overflow (or related) exploits. There are hundreds more... Have you personally ever written a multi-thousand-line network daemon that you know is buffer overflow free? How do you know?

Here is what I say: C the language makes it easy to make the kind of mistake that leads to a remotely exploitable buffer overflow. It is almost as if the language is designed to enable this behavior. According to CERT and others, buffer overflows (and related format-string vulnerabilities, also endemic to C) are the most common source of security holes in UNIX applications (On win32, they are second only to Outlook attachments).

There are only two reasons I can imagine that people would reasonably use C:

Low-level Hardware Access - Fair enough. There are not really any good alternatives now. However, network applications do not need to do low-level hardware access at all.

Raw Speed - Though I believe that other languages are very near to C in performance (http://www.bagley.org/~doug/shootout/craps.shtml) , conventional wisdom says that if you want ultimate speed, use C. However, network applications are not typically CPU-bound, they are network bound. ESPECIALLY FOR THE HOME USER, with a 1.5ghz PC and 5 users per day, this argument is totally silly. Outside the enterprise (where hopefully people can custom tune their software and have people devoted to keeping it secure), there's no reason to need C's speed in a network daemon.

IN A NETWORK APP, SECURITY (SAFETY) IS CRITICAL. That means that all network apps should be written in a language with machine-checked safety. This might mean Java for people who need it to feel like C. (Note that there are several good native code compilers for java, and it has reasonable network support.) In these kinds of languages, buffer overflows and format string vulnerabilities are automatically impossible. Personally, I prefer a more efficient language with stronger safety guarantees: SML. (Ocaml might suit the slashdot audience better) In fact, at the time of the last wu_ftpd remote root exploit, I decided that it was time for me to rewrite my ftp daemon in SML. It took me only 1 weekend to get it working, by myself. It does not support every feature of FTP (especially obsolete things and dubious "features" like SITE EXEC), though it supports plenty for say, the average linux desktop user. Writing code in a modern, high-level language has other benefits too: it is only about 3000 lines, including library code that I wrote to implement MD5 passwords and various other things that I plan to use in other daemons (the core ftp server is only 850 lines). Compare this to wu_ftpd (8000+ lines) and the PAM MD5 password implementation (200 lines). Most importantly, I know that by using a safe language that I have a 100% buffer overflow free daemon. Thus, I can spend more time looking over the code for more subtle security problems, such as possibilities for Denial of Service attacks. (I didn't do much of this, actually, though it is not vulnerable to the ls globbing attack, SITE EXEC, or PAM authentication bugs that have been in other ftp servers.)

If you think this sounds good, you can get my FTP server here and an ML compiler here . (It is just a proof of concept, so don't get too excited!) But what I would rather you do is just listen to my advice, and demand better from your software manufacturer! Linux distributions that want to be secure should be rewriting this kind of software in some modern safe language. It is easy to do, and the results are worthwhile.

I think we learned that many problems that we're facing in terms of Perl implementation right now have already been thoroughly researched and dealt with as many as 30 years ago; but we also learned that if we want to get at this research, then we need to do a lot of digging. The academic community is good at solving tricky problems ... but not very interested in working out all the implications.

This is the best paragraph in the article. Here's what makes me sad:

Slashdot-type hackers have an amazing ability to get things done. They can really come up with a working product faster than anyone.

BUT, slashdot-type hackers have a tendency to implement olddd ideas, and also frequently to make well-understood mistakes. It is true that we are on the cutting edge of implementing internet protocols and maybe window managers, but in other areas we are implementing 30 year-old ideas still. (OS design and programming languages come to mind especially.)

WHO, if not the hackers, will embrace this stuff? They are the only ones that are supposed look beyond the hype and marketing and status quo to evaluate things based on technical merits, and to create implementations of new ideas.

I know only the OS design that I learned in my undergraduate course. But that is enough to know that the design of the kernel is very conservative! Where are capabilities? Where is fine-grained access control? Does anybody *really* think that their internet daemons should run as *root* just so they can open up a port with a low number? (I know there are plenty of workarounds...) I am sure that there are dozens of great ideas in OS design from the last 20 years that would be totally appropriate for a hacker's kernel.

I know a bit more about PL design. Being in academia pollutes the mind, I know, but I am sure that almost all I see in the slashdot PL community is reworking of old, mediocre ideas. Who in the world will use and develop new programming languages if not hackers?

(So, the PL fanatic in me wants to point out caml, which, even though it is not my personal favorite, I think could become really popular with slashdot-style hackers. It is really fast -- probably the fastest, it is hacker buzzword-compliant (it has "objects"), and yet it has taken many great ideas from academia and put them in a really usable, accessible form. Try it if you are in for a taste of something different!)

Anyway, just trying to say that if you are tempted to go hack up your own programming language, please at least don't assume that Perl is the state of the art because it is the most popular scripting language or something. Take a class, read a book, and check out some of the weirder languages coming out of academia first. Hackers are how the revolution happens...

...out there and here.

True; the fact they don't under linux is an artifact of LinuxThreads. As Xavier Leroy notes in his FAQ, a one-to-one (every thread maps to a kernel thread) thread implementation implies that every context switch must be at the kernel level, which is more expensive than a pure user-space context switch. It's the price you pay for simplicity. This is somewhat mitigated by linux's fast context switching.

Processor instructions such as "test and set" don't typically need supervisor priveleges.

Correct, so you can do atomic variables in user space :)

Actually, I'd argue that the genericity of lisp's syntax is as much a hindrance as it is a help, emacs parenthesis-matching aside.

The above quoted lisp sexp could mean almost anything or nothing, depending on the context in which that sexp occurs. (Is it data? Is it code? In what evaluation context will it be processed?). Java, C, and most other languages at least give you more distinct contextual tokens to guide you in your understanding.

I like Lisp a lot, but I tend to agree with this point of view. I'm simply more comfortable infix-syntax for simple arithmetic. Prefix syntax is great for function calls -- and I don't really care whether the parens go around the whole thing (Lisp), after the function name and aroudn the arguments (most languages), or aren't there at all (ML/Haskell/Logo). Hell, I even cope happily with postfix function calls (Postscript/Forth/GML).

But when it comes to control structures I really, really prefer a keyword-rich syntax and explicit markers saying just what it is that you've just come to the end of. e.g. if/then/elseif/fi or any of a number of equally reasonable alternatives.

This is why I think that Dylan is currently the best language out there. It does pretty much everything that Common Lisp does, but in a more familiar syntax and with a lot of CLs historical cruft cleaned up. Dylan was designed by a bunch of Common Lisp gurus with the intention of designing the replacement for CL. And I think they suceeded technically.

Dylan currently has two implementations, one open source batch compiler for Unixy systems and one commercial IDE for Windows (with a free personal edition). Both systems compile to fast machine code and can compete with C in all but the most hardcore applications -- certainly far far better than Java or Perl or Python.

Functional Developer is a quite mature system with nice IDE and debugger and lots of libraries.

Gwydion Dylan is a bit less polished, but it's still good enough that a team using it managed 2nd place this year in this year's ICFP 72 hour programming contest.

All previous winners at this contest have been written in either C or else one of the Hindley-Milner statically typed languages (SML/OCaml/Haskell), all of which have very fast execution speeds with a good compiler.

You don't necessarily have to have the best possible langauge to win at ICFP, but you must have no major weaknesses -- you have to have a language and compiler that lets you develop and debug complex code in a very short time, and the end result must run fast. Much like in the real work :-)

Common Lisp and Scheme have never yet won a prize here (though I believe Common Lisp could), and it seems that the large number of Java and Perl and Python entries produced every year simply don't run fast enough to do well. On the other hand, the vast majority of C and C++ programs get eliminated because of bugs (occasionally one gets through!).

Having said all that, the one-line summary is this: if you like the idea of Common Lisp but just can't stand all those parens, take a close look at Dylan instead.

You might want to have a look at other alternatives such as Scilab. Other free mathematical programs also exist, but scilab and octave seem to be the closest in spirit (and language) to matlab.

Postgres has shown time and time again that it blows the shit out of MySQL for any kind of select statement where your 'where' clause is even just slightly more complicated than 'x = y'.

I'm using MySQL to perform selects that join five tables, including one with over 800,000 rows and one with over 5 million rows. It can perform these selects in a fraction of a second, more than adequate performance for my application.

I might be missing something, but I don't see anything contradictory in these two statements. If your "where" clause is sufficiently easy and you can take advantage of indexing, you would expect any decent system to perform reasonably well when it is returning a handful of rows. Five table joins would only be scary when you can't toss out the vast majority of your 5 million rows at step one.

MySQL has also been very reliable for me.

One thing that has just occurred to me in this, round 5,408 of the MySQL-versus-PostgreSQL flame fest is to ask if anybody has tried to replace MySQL with PostgreSQL or vice versa in any project that both sides would consider "worthy" in some sense. One problem here, of course, is that if you really wanted an ACID solution, you weren't (aren't?) likely to choose MySQL in the first place. But what if you wanted to use PostgreSQL with the Slashcode; would this port be doable in anything like a reasonable amount of time? If done, could it then be shown that the result was any different (for better or for worse) than what you get with the current system?

Another idea would be to borrow an idea from the functional programming community and do a "database programming contest" like the the annual ICFP Programming Contest. You could try to find a sponsor and give out cash prizes, or you could get *really* serious (like the ICFP people do) and award year-long bragging rights.

I mean, both PostgreSQL and MySQL fans would probably go to great lengths to avoid having to refer to the other product as, for example, "the relational database system of choice for for discriminating hackers" in public. Not to mention the possibility that both of them would have to acknowledge the supremacy of DB2 or Oracle or something. :-)

I happen to think that Haskell [haskell.org] is one of the semantically cleanest languages out there

For example, consider the expression,

foldl1 (*) [1 .. 1000]

(...((((1 * 2) * 3) * 4) * 5) ... 1000)

Humans can easily see that the expression can be evaluated left to right, treating the operator (*) as strict, and, with the list defined by [1..1000] being built lazily, it is possible to evaluate the expression in constant space:

= foldl1 (*) [1 .. 1000]
= foldl (*) 1 [2 .. 1000]
= foldl (*) 2 [3 .. 1000]
= foldl (*) 6 [4 .. 1000]
= foldl (*) 24 [4 .. 1000]
= ...

= foldl1 (*) [1 .. 1000]
= foldl (*) 1 [2 .. 1000]
= foldl (*) (1*2) [3 .. 1000]
= foldl (*) ((1*2)*3) [4 .. 1000]
= foldl (*) (((1*2)*3)*4) [5 .. 1000]
= ...

You and I can see that the second method is wasteful, but the language definition provides no guidance as to whether a Haskell implementation will choose the second or the more-efficient first. (In fact, GHC would until recently choose the second for this expression.)

Don't get me wrong. Haskell is, without a doubt, my favorite language. It's what I used for my entry in this year's ICFP Programming Contest, and I consider it the best hope for a truly great mainstream functional programming language. I love Haskell. But its lack of intuitive space-consumption semantics is a serious weakness.

And, regarding your fact example, it doesn't really show off Haskell's semantics as much as its syntax. Why not show the classic Fibonacci Series implementation, which highlights Haskell's non-strict evaluation semantics?

fibs@(_:fibs') = 1 : 1 : zipWith (+) fibs fibs'

The fastest FFT library out there is in C, but the C code itself was generated by Haskell code

Cheers,
Tom

I know a lot of big academic (erstwhile) lisp shops, such as CMU, have transitioned away from lisp to ML and relatives. Some of the reasons we might give are:

- Sophisticated type systems, catching most bugs before your program is run, ensuring safety, etc.
- Much more efficient (http://www.bagley.org/~doug/shootout/craps.shtml) , partly due to compilation strategies using types
- Increased modularity and abstraction
- Pattern matching, (subjectively) more natural syntax

In fact, I'm one of those people. I've been scoffed at by lisp fans, but most had never used ML. But I have an open mind, so, in the face of more "modern" languages, what advantages do lisp and scheme offer? Do you think that these advantages are fundamentally impossible to achieve in a typed setting?

Actually the question should be: Do we really need another C compiler? Besides the fact that C is a poor language to optimize (weak typing, crappy calling conventions, broken arrays, you name it), it's about as close to assembly as a "high level" language gets and assembly is not a very good way to write quick and easily maintained code. Better to work on smarter compilers for languages that allow one to work on a higher level of abstraction. Projects such as CMUCL, SBCL, and OCaML could always use some help.

It's true that perl is getting more and more of the capabilities of Lisp (as has Python) recently, but while it is becomeing *possible* to do many things, it's rather ugly. Perl doesn't even have a decent syntax for naming the arguments of a function, and Lisp programming is *full* of functions.

Perl datastructures (arrays and hashes) also aren't very well suited to implementing lists, which are likely to turn up in your tasks. Of course you r can *do* it, but it's likely to be more ugly in than in a proper Lisp.

But you before you despair in a maze of twisty little parens, you should realise that there is more than one language in the Lisp family. Common Lisp and Scheme do have lots of parens, but take a look at Dylan. It's a true member of the Lisp family, but looks and feels like a conventional langauge such as C or Pascal.

The link above is to an Open Source command-line compiler for Dylan which workes primarily on Un*x but also has ports to Mac and Windows.

If you happen to be using Windows then also check out Functional Developer, a compiler with a nice IDE and debugger and so forth. It's commercial but the basic edition (whcih is all you'll need) is free.

Dylan is quick to develop in and the programs run fast. A team using Dylan got second place in the recent ICFP Programming Contest.

• Opera
• Konqueror
• Mozilla
• Galeon
• Skipstone
• Netscape

The article did not review a number of browsers. Here are a some more that you may want to try:

• Arena
• Amaya
• Chimera
• MMM
• Emacs/W3
• Lynx (text based)
• Links (text based)
• Debris (text based)
• w3m (text based)
• Libwww (text/line based)
• HowJava
• Express
• Armadillo (was Gzilla)
• Mnemonic
• Kde (file manager with builtin browser)
• mMosaic
• QtMozilla
• QWeb
• Mosaic
• Arachne
• Beest
• Beonex
• BrowseX
• Grail
• Dillo
• NetRaider

And how the disclaimers: The list above by no means complete. The browers above were listed in j-random order. Some browsers are in early alpha stage, some in Beta and others are in full release. Some of the browsers may suck, some are OK and some are good. Your mileage may vary. Sorry If I left out your favorite browser. IE was left off the list for obvious reasons. Good while supply lasts or until Bill Gates takes over. I'm not a member of the FCIA. Void where cast as (void).

There are some benchmarks at Ace's hardware (search for binaries vs. bytecodes) that aren't perfect, but make some very valid points.

I happen to disagree. Like statistics, benchmarks can be massaged to say anything a person likes. I prefer real world results, preferably doing tasks similar to those I'm planning on using the language for.

Perhaps a /. based C++ vs. Java coding contest would be interesting. Any interesting problems come to mind? I'm sure we have the talent around here to get close to max performance with both languages.

We could also just wait for the results of this year's ICFP. It's not purely a speed test, but I really don't much see the point into going so far as to do some sort of double-blind study of programming language productivity at both the machine and human levels.

I'd expect Objective-C to be a bit slower than C++ in general, given the method lookup overhead, and lack of generic types.

It would possibly be slower than C++, but probably not for a parity task (I've converted C++ code that had to hack out runtime concepts of its own and the ObjC version was faster and cleaner). I don't know what you mean by "lack of generic types". In proper OO languages like ObjC, we just call them "objects".

I do like Objective-C, but I really don't think it'll ever gain mainstream acceptance.

Who gives a damn? I use languages to get jobs done, to to get some warm fuzzy feeling of belonging. Even the oh-so-clever naming conventions that played off the Java name make me queasy ("We'll call them BEANS!! HAHAHA. Get it? Java beans!" ugh).

Garbage collection is stronger than reference counting as well.

Neither are specified as part of the ObjC language, and you can drop in something like Bohem GC if you like even if you happen to be using the frameworks of a vendor like Apple that likes reference counting.

Plus (assuming you're talking about a traditional compiler like gcc) you lose the advantages of bytecode like dynamic compilation tuned for the exact CPU (say Athlon for instance) that you're using.

Yeah, big loss by using a native binary instead. If I wanted to thow away RAM and CPU on an emulator (aka, a VM without a marketing department), I'd buy one.

I didn't make that claim, so I'm not sure why I'd want to do that. I'll stand by my claim WRT C++ (used as an OOL).

And I said you could even use ObjC (which you believe to be even slower than C++) if you wanted to compare a C-based OO language to Java. You essentially claim is that Java emulation can be done at near-native speeds. I've never seen such a thing outside of slanted, non-parity benchmark comparisons. What I do see in real world apps like Apple's TextEdit that comes with OS X, both Java and ObjC versions, is that the Java version is a real dog. Make whatever excuse you like for that, but as a user I don't give a damn why the app sucks, I just know I won't be using the Java version if I want to be productive.

Do you honestly feel C is as productive as Java? I certainly don't.

If Java works best for you in the things you do, by all means use it. To make a blanket statement that C cannot be as productive as Java is downright foolish. Every language has a particular area where it shines, and C has been shining in many more productive areas for far longer than Java has been around shining in the marketing department.

To a large extent they were right. Have you checked the ratio of C++ to C jobs lately?

You completely missed my point. It has always been that way. Languages come and go and leave greater or lesser footprints on the computing landscape. The footprint Java has left has not been due to any technical innovation, but because Sun marketing has somehow convinced people that emulation is a great idea.

The G'Caml web site is http://pauillac.inria.fr/~furuse/generics/

So when are we going to see this at ICFP? Oh wait, we already did, all the ruby entries failed.

So when are we going to see this at ICFP? Oh wait, we already did, all the ruby entries failed.

Why not?
One can at least easily do lossy whitespace compression. For more ideas relevant to markup languages, see the ICFP 2001 contest.
I'm sure you can't get that 200 byte XML document from the "2 bits + a few bits" ASN.1 representation ... but it doesn't really matter.

1. PLClub submitted two separate entries using OCaml, either of which would have won the contest.
2. Camls 'R Us took second place.
3. Galois Connections took third with their Haskell entry.
4. The Merry Mercurians took fourth with their Mercury entry.

1. Camls 'R Us mopped up the competition with their 3585-line OCaml entry
2. The 1250-line Haskell Entry that took 2nd place was written in a mere 24 hours.

1. First prize was a Cilk entry. Winning the contest doesn't seem to have made the language take off in popularity.
2. Second prize: an OCaml entry ``beat out 23 C and C++ entries, many of these being highly tuned programs produced by extremely competent programmers skilled in game-playing algorithms.''

1. PLClub submitted two separate entries using OCaml, either of which would have won the contest.
2. Camls 'R Us took second place.
3. Galois Connections took third with their Haskell entry.
4. The Merry Mercurians took fourth with their Mercury entry.

1. Camls 'R Us mopped up the competition with their 3585-line OCaml entry
2. The 1250-line Haskell Entry that took 2nd place was written in a mere 24 hours.

1. First prize was a Cilk entry. Winning the contest doesn't seem to have made the language take off in popularity.
2. Second prize: an OCaml entry ``beat out 23 C and C++ entries, many of these being highly tuned programs produced by extremely competent programmers skilled in game-playing algorithms.''

After all, ICFP is tommorow, and I can't work on both at the same time. Oh well, I guess I'll have to wait until sunday afternoon to start cranking on this one. Or I could just say screw ICFP since this one has potentially higher rewards :).

Then, let the contest do the work for you. Watch as your prima donna gets functionally mauled and then garbage collected into oblivion by some of the most talented programmers in the world. Most likely, your elite coder boy won't even understand the challenge task. (Anybody remember the '99 task? Ouch.)

From that point on, subtle reminders of his contest performance will keep your boy in check. "Gee, I thought you would have managed to finish the first part of the challenge task, at least. You must have been sick or something. Well, there's always next year's contest!"

Try not to chuckle aloud when he mentions that he won't be entering next year because of vacation plans.

http://pauillac.inria.fr/~furuse/generics/

Yes, it is frustating in programming in Ocaml. It has a lousy GUI except if you have the emacs binding (which is pretty cool). Debugging it can be very frustating since the error message is vague. The documentation is erroneous. Learning Ocaml can take a lot of time, especially if you have never touched functional language realm. But...

In Ocaml you can do a lot of nice things: throwing out functions of functions. Which can simplify a lot of things. This is a significant feature of functional language. It supports a pattern matching like Perl (although not as sophisticated). You can build AST, trees, hashtables, and other ADTs effortlessly using the language's basic construct (unlike C/C++ or Java which supports that in the library). Thus, this is very ideal for theoretical and compiler researches.

I think that you guys C/C++ gurus should try to both reverse engineer the binary output of OCAML and look the code generation phase why it is so fast. Try here for further reference on Ocaml.

There are a couple of systems that already exist. XwingML builds Java Swing interfaces from an XML specification. XUL is a similar XML-based markup supported by Mozilla. XForms is the W3C's draft standard for the next generation of web forms.

Most particularly you may want to look at UIML, which is intended as a cross-(viewing-)platform markup, supporting PCs, PDAs, etc. There is a Java viewer, and the new version seems to have some renderers for WML and HTML, but a text renderer should be possibe (if not already available).

There are several other lesser-known XML-to-GUI toolkits, such as KUIL and AUIT. Most of these are implemented in Java and map the Java Swing classes into XML (as with XwingML).

But ML turned out to be great! It functions like Lisp, but has some additional interesting features:

• Strong type checking: Most of my Lisp errors were type errors. ML is the most strongly typed language I have heard of (its often used by language theoriticians). When you run the program it is first fully type checked, very few runtime errors are even possible. What makes it different from C is that type checking is implicit (although you can specify types if you want). The compiler/interpreter will figure out which types a function can accept, so you can have a function that accepts many different types for some argument, yet you get the safety of full type checking.
• Its simpler than Lisp. Lisp has too much crap thrown in. ML is more understandable (like Scheme).
• Few parenthesis. Although your programs are structured similar to Lisp, most parenthesis are not needed, which IMO really helps readability and makes it easier to change (no more counting parenthesis when you add something).
• More powerful functions. When you call a function the arguements are actually matched against a pattern in the function declaration. The function with that name which has a pattern that matches the closest is used. You can write interesting recursive functions where one version of the function gets called normally, and another gets called when the argument is a 1, for example. This only scratches the surface of how powerful this feature is.
• There is even an object oriented version: Caml

Or why not learn Caml? It's fast! Yay.

High-level languages don't always result in slow code. Probably the strongest counterexample is Objective Caml. Functional (1st class functions; lexical closures), OO, exceptions, strictly typed, type inferencing, parameterized modules (and classes), a macro system that lets you extend and modify syntax (in camlp4) and more. The language is probably 10x as expressive as C (e.g. it takes, on average, 1/10 the space to say the same thing in OCaml as C), but it compiles to near-C speeds and sizes (sometimes beats it). This is a 15-year old project with a liberal license (LGPL) that works on UNIX, Windows and Mac OS! An older version (Caml Light) works on Palm OS. More people should be considering languages like this for complicated problems where performance is an issue!

GeneWeb has a web interface (usable with or without HTTP server). It has its own database, and as the example database has 70,000 people (try looking up a member of royalty), capacity should not be a problem. You'll have to decide if the features match your needs.

GeneWeb has a web interface (usable with or without HTTP server). It has its own database, and as the example database has 70,000 people (try looking up a member of royalty), capacity should not be a problem. You'll have to decide if the features match your needs.

This browser is somewhat obsolete now (was not maintained) ... but local CGIs were really nice, providing cheap and sophisticated MM interfaces for applications.

Don't get me wrong: those systems had their own share of problems, not the least of which was that they required expensive hardware to run well. They also lacked some of the niceties and safety check of modern programming languages (by which I mean languages like ML, not C++).

So, what can you do? Don't blindly use C/C++ for everything. Those languages have their place, but they require you to spend a lot of time on stuff that isn't related to getting the job done. Learn something new, and learn about the history of all this. Here are some suggestions:

• Learn about functional programming with Haskell and OCAML, and SML/NJ
• Learn about logic programming with one of the Prolog implementations.
• Read up on CommonLisp, Flavors, CLOS, and the Lisp Machine Window System. You can get CommonLisp implemenations at cons.org
• Read up on Scheme and get a Scheme programming environment. PLT Scheme looks pretty good.
• Read up on Smalltalk-80 and its programming environment (you can get a so-so Smalltalk-80 implementation at Squeak).

While those systems may or may not help you in your day-to-day work, they teach a lot about what programming can be.

For your day-to-day work, consider using languages and environments like Python, Perl, and Java. They aren't quite as convenient as the more academic systems I mention above, but they still let you focus much more on the problem rather than the mechanics of programming.

i may be off base here, but if you've been using Slack for over 6 years i should think that you'd be able to interpret the error messages you pasted.

> cc -pthread -D_REENTRANT -DDEBUG -c proxy.c -o proxy.o
> cc: unrecognized option `-pthread'
looks like you either don't have pthread's installed, or you're using a strange version of cc/gcc (not likely, you'd know if you installed it).

glibc2 normally comes with linuxthreads, but you can pick it up at http://pauillac.inria.fr/~xleroy/linuxthreads/.

when you install a new package/compile something, it's important that you at least browse through the documentation to make sure nothing other than 'make;make install' is needed...quite often, packages from freshmeat require other packages installed first, that aren't packaged with Slack.

good luck,
josh

you dont have the pthread library installed. Go get it, install it and try again. This is nothing like the trouble you have getting stuff to compile on *BSD.

This means that the best mode I could get from the second head of the G400 with a vertical refresh > 70Hz would be 1360x1020. The Millenium II can do 1800x1350, giving me 75% more pixels on the screen. Thanks to whoever wrote this modeline calculator.

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

-- Faré @ TUNES.org

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

-- Faré @ TUNES.org

xanim doesn't fully support MPEG-1 - it's not buggy (not that xanim doesn't have bugs in other formats) but just that it only supports MPEG key frames, not intermediate ones.

Try mtv, smpeg, xmovie, LAMP..

If you want decent fullscreen support on a slower speed machine (as you would get in Windows), then you need XFree 4.0 with the Xv extension and a player that supports it. Xv supports shared memory transfer of YUV images (MPEG decoder output) from user space directly to the graphics card memory, and uses the graphics card's hardware YUV-to-RGB conversion and scaling support.

BTW, there's only a few cards (such as Matrox g400) that have Xv driver support yet.

If you don't have Xv support, then second best would be a player like LAMP that supports DGA (direct video memory access under XFree).

xmovie

LAMP

avifile may read divx's, but it certainly doesn't work for all windows video CODECs. Have you ever tried getting it to use one other than those it comes bundled with - I hav't been able to get a single additional one to work - then all fail in different ways.

Still, if you do want to use avifile, aviplay and XMPS are not the best players. Try LAMP or XTheatre instead.

There are better options for MPEG also. SMPEG only works for MPEG-1 (as does mtvp). For MPEG-2, try xmovie, xine, or the VideoLan client.

There's also at least 3 Open Source divx (i.e. MPEG-4) CODEC efforts that I'm aware of - I submitted the story yesterday, but it was rejected.

(To quote myself)
You can in fact write (and compile) code for JVM in Eiffel, Fortran, LISP, Visual Basic, Ada 95, Python, PERL, C, any language that GCC supports, and a whole slew of other languages (170 or so).

See the comments to cid 135 and this page.

BS! You can in fact write (and compile) code for JVM in Eiffel, Fortran, LISP, Visual Basic, Ada 95, Python, PERL, C, any language that GCC supports, and a whole slew of other languages.

In the future, keep your uninformed ramblings to yourself.

See the comments to cid#135this page.

He's right. Learning some things will definitely help the way you think about things. The incredibly strong typing of something like pascal will definitely kick your *ss if you've been doing nothing but C for a while, and I think that's actually a Good Thing. Learning Eiffel if you already know smalltalk is a very different experience.

Even something like Algol will probably change your views and get you closer to the hardware in many respects (not that you can get Algol to run on most machines anymore....;-)

What about Ada? Programming by Contract really will teach you something serious about how you actually interact with the rest of your application, and while you'll curse it ("I KNOW what I'm trying to do and it's correct, dammit!") you'll be happier for learning it. Older, but happier.

And as long as the languages keep coming, there'll pretty much never be a chance to really run out.

My list would include:

• C
• C++
• Pascal& lt;/a>
• Lisp (anything but eLisp)
• Python
• Perl
• Smalltalk
• ML
• prolog&l t;/a>
• Eiffel
• Ada
• a RISC Assembler
• Cobol (those who do not learn from history are doomed to repeat it)
• Java
• BASIC (the non-Visual kind).

It uses Windows DLLs for CODECs and can play AVI, MPEG2, MPEG3, SMPEG, QT...

A nice example of what functional languages can be used for--besides compiler construction is--the current Internatiobal Contest for Functional Programming. The task was to build a ray tracer within 72 hours. The entry of the Objective Caml team is especially impressive.

A nice example of what functional languages can be used for--besides compiler construction is--the current Internatiobal Contest for Functional Programming. The task was to build a ray tracer within 72 hours. The entry of the Objective Caml team is especially impressive.

This is a whole new avenue...taking the process we call evolution and mapping it into technology. If we can harness that ability, and more importantly accelerate it, then haven't we suddenly gained a new resource? Computational devices gave us the power to let something else think for us, but with rigid limits...the instructions must be fixed, so really only repetitive functions can be made autonomous. But this gives us a new power...or does it?

We still can't solve problems autonomously. The original set of instructions has to be fed to the device, and the methods for 'evolving' have to be written. To me, it looks like we've just taken a clue from nature, applied it to a computational device, and watched a faster form of problem solving take place. Genetic algorithms aren't exactly new...here's a short description, or if you like, an example of a massively distributed parallel geneticalgorithm from Carnegie Mellon University Robotics. (Also check out CMU computer science for all sorts of wild projects). For another comment on relating ecological systems to computing, see this string, from an article this week.

Who knows what else can be found in natural systems, that we can apply to computing to gain information resources. I remember hearing that, a few decades ago, biology was the hot interest of the world's greatest thinkers (mostly trade physicists) who were looking for profound answers...wouldn't it be interesting if we could one day mine progress.

-j