Slashdot Mirror

http://isl.ira.uka.de/about_us/interact_director/

Sounds like this guy is "quite a bit better than average" when it comes to speech technologies too. I don't see what's so hard to believe, it's a lot more handy having something like this on your phone than it would be on a desktop or even a laptop.

While not many Slashdotters may have to be worried about their Semen Transfer Devices participating in a DDoS attack on (re)productivity, I bet that most, if not all, are quite busy dealing with the consequences of at least one of these STDs.

It's true that dynamic languages have certainly helped in greatly reducing memory-management related errors, which would I suspect reduce the rate of defects over a whole program or application by a significant amount, lets say 50%.

However, the average programmer will still produce the same number of logic errors in their code as before, since dynamic programming languages also increase code density (more work per line of code), the error rate measured as defects per line of code would most likely increase; same number of logic errors, less lines of code.

So taken together: less memory-management errors + higher rate of logic errors per line of code, can only tell you one thing: using defects per line of code as a measure between languages which differ greatly in their level of abstraction will give you statistics that you can pass on to the marketing department, because they will be completely meaningless.

The industry average is estimated to be 10-20 defects per 1000 lines of code. Every non-essential line of code you write risks introducing a bug.

Why do people always quote these useless statistics? When everyone wrote everything in C, these statistics made more sense, but these days of dynamic languages like C#, Python, Perl, Ruby, and Tcl/Tk change the rules significantly. Consider, for instance, this report, this blog post, and this Google search.

The number of lines of code go down significantly and, unlike C, which was designed for ultimate programmer precision, these modern languages are actually designed to increase programmer productivity, though they do it with varying degrees of success (IMHO).

I know as a software developer I can write the same application in Python vs. C much more quickly and with far fewer errors.

I think we need to rethink software development metrics. Badly.

The industry average is estimated to be 10-20 defects per 1000 lines of code. Every non-essential line of code you write risks introducing a bug.

Why do people always quote these useless statistics? When everyone wrote everything in C, these statistics made more sense, but these days of dynamic languages like C#, Python, Perl, Ruby, and Tcl/Tk change the rules significantly. Consider, for instance, this report, this blog post, and this Google search.

The number of lines of code go down significantly and, unlike C, which was designed for ultimate programmer precision, these modern languages are actually designed to increase programmer productivity, though they do it with varying degrees of success (IMHO).

I know as a software developer I can write the same application in Python vs. C much more quickly and with far fewer errors.

I think we need to rethink software development metrics. Badly.

The reputation that they want they can only get within their specific community, though, so most of them don't care as long as they're one of the big names in their field.

google scholar is excellent resource, by the way, I prefer it to CiteSeer. Then I use http://liinwww.ira.uka.de/bibliography/index.html, the computer science bibliography, for the reference if I use the paper. I'm researching something to do with computer science, by the way :)

"as long as they don't support natively SVG"

Google on OO and feetures. Select random feeture. Post I like OO except it doesn't have 'X feeture' on Slashdot.

SVG-ready OpenOffice 2.0

was re Re:Openoffice doesn't deserve cliparts

That is essentially what Apple has done.

No, it isn't. He's talking about a microkernel, like QNX or L4. Mach is also considered a microkernel, but OS X is not based on Mach; it is based on XNU, a hybrid kernel that consists of Mach bolted into the FreeBSD monolithic kernel, with I/O Kit thrown in for good measure.

You give performance arguments, but the speed of OX X does not imply that it uses a microkernel; quite the opposite, microkernels have been known to run significanly slower than monolithic ones, which is presumably why Apple went the hybrid route instead of using pure Mach. To be fair, Mach is rather outdated among microkernels, and "modern" microkernels like the aforementioned L4 have shown that the speed penalty might be as low as 5-10%, but the point still stands. Don't confuse simplicity of code with performance.

He conveniently ignores or chooses to remain ignorant of the fact that L4Linux is typically faster than Linux itself.

I was under the impression that L4Linux has a 5-10% performance overhead versus native Linux. This is still pretty good given that L4Linux is pretty much just Linux running on top of the L4 microkernel, and it's certainly much better than (say) MkLinux, but "faster than Linux itself"? Unlikely.

> Now once at Stanford they changed how they did things entirely and wrote a ton of code to make everything play much nicer than CMU's platform.

This sounds a little bit more like that, what I have heard. I've read, that they throw away most of the code and rewrote a large deal. E.g the classification of driveable terrain by the laser scanner was rewritten and learned. AFAIK, most of what has been published (and to what you pointed) is fairly generic stuff.

To the best of my knowledge, it has not been published how they learned the far range vision based on the near range laser scanner, which, to my eyes, is the most interesting part of the project.

> Nice try, I wasn't on CMU either.

Well, the comment on Sebastian Thruns previous affiliation and the code development sounds like something Mr. Whittaker could have said. But from what I've heard, he followed a fully stochastically approach and less reliance on the physical stability of the sensors and GPS, which AFAIK was quite different to the Red Teams approach and resulted in a much smaller code base.

Roland the Plogger strikes again.

Micro-manipulation in our days is either done with an expensive customized systems (chip-manufacturement) or manually (cell-manipulation). The aim of micro-robotic projects is to bring automation to the micro-scale.

At the end of the MiCRoN project at least 3 robots where build and fully assembled. For example there is a list of robots, which were build in the MINIMAN-project already. Only 2 of them were used for the final demonstration. Many prototypes had to be build and discarded, before the design was completed.

It is true, that PCB-soldering is fully automated, but this is done with highly customized systems. On the macro-scale even the industry is interested in making assembly lines more flexible. It is also true, that cell-manipulation has become a common task in research and industry. But it is rarely done in an automated way. If a project requires injecting 10000 cells with a fluid, most probably the project will be dropped.

When researchers are operating a scanning electron microscope, they regularly have to break the vacuum to do a very simple manipulation. A microrobot in the vacuum chamber can save a lot of time here.

The MiCRoN public report has not yet been released. However the MINIMAN-report is here and we have published a lot of pictures and demonstration-videos on our MMVLWiki.

Note, that most of the control- and computer-vision-software is running under Linux. The real-time computer-vision library called Mimas and the computer-vision software of the MiCRoN project is available for free under the terms of the GNU license.

Micro-manipulation in our days is either done with an expensive customized systems (chip-manufacturement) or manually (cell-manipulation). The aim of micro-robotic projects is to bring automation to the micro-scale.

At the end of the MiCRoN project at least 3 robots where build and fully assembled. For example there is a list of robots, which were build in the MINIMAN-project already. Only 2 of them were used for the final demonstration. Many prototypes had to be build and discarded, before the design was completed.

It is true, that PCB-soldering is fully automated, but this is done with highly customized systems. On the macro-scale even the industry is interested in making assembly lines more flexible. It is also true, that cell-manipulation has become a common task in research and industry. But it is rarely done in an automated way. If a project requires injecting 10000 cells with a fluid, most probably the project will be dropped.

When researchers are operating a scanning electron microscope, they regularly have to break the vacuum to do a very simple manipulation. A microrobot in the vacuum chamber can save a lot of time here.

The MiCRoN public report has not yet been released. However the MINIMAN-report is here and we have published a lot of pictures and demonstration-videos on our MMVLWiki.

Note, that most of the control- and computer-vision-software is running under Linux. The real-time computer-vision library called Mimas and the computer-vision software of the MiCRoN project is available for free under the terms of the GNU license.

Micro-manipulation in our days is either done with an expensive customized systems (chip-manufacturement) or manually (cell-manipulation). The aim of micro-robotic projects is to bring automation to the micro-scale.

At the end of the MiCRoN project at least 3 robots where build and fully assembled. For example there is a list of robots, which were build in the MINIMAN-project already. Only 2 of them were used for the final demonstration. Many prototypes had to be build and discarded, before the design was completed.

It is true, that PCB-soldering is fully automated, but this is done with highly customized systems. On the macro-scale even the industry is interested in making assembly lines more flexible. It is also true, that cell-manipulation has become a common task in research and industry. But it is rarely done in an automated way. If a project requires injecting 10000 cells with a fluid, most probably the project will be dropped.

When researchers are operating a scanning electron microscope, they regularly have to break the vacuum to do a very simple manipulation. A microrobot in the vacuum chamber can save a lot of time here.

The MiCRoN public report has not yet been released. However the MINIMAN-report is here and we have published a lot of pictures and demonstration-videos on our MMVLWiki.

Note, that most of the control- and computer-vision-software is running under Linux. The real-time computer-vision library called Mimas and the computer-vision software of the MiCRoN project is available for free under the terms of the GNU license.

Micro-manipulation in our days is either done with an expensive customized systems (chip-manufacturement) or manually (cell-manipulation). The aim of micro-robotic projects is to bring automation to the micro-scale.

At the end of the MiCRoN project at least 3 robots where build and fully assembled. For example there is a list of robots, which were build in the MINIMAN-project already. Only 2 of them were used for the final demonstration. Many prototypes had to be build and discarded, before the design was completed.

It is true, that PCB-soldering is fully automated, but this is done with highly customized systems. On the macro-scale even the industry is interested in making assembly lines more flexible. It is also true, that cell-manipulation has become a common task in research and industry. But it is rarely done in an automated way. If a project requires injecting 10000 cells with a fluid, most probably the project will be dropped.

When researchers are operating a scanning electron microscope, they regularly have to break the vacuum to do a very simple manipulation. A microrobot in the vacuum chamber can save a lot of time here.

The MiCRoN public report has not yet been released. However the MINIMAN-report is here and we have published a lot of pictures and demonstration-videos on our MMVLWiki.

Note, that most of the control- and computer-vision-software is running under Linux. The real-time computer-vision library called Mimas and the computer-vision software of the MiCRoN project is available for free under the terms of the GNU license.

Interactive Systems Laboratories at the University of Karlsruhe and
International Canter for Advanced Communication Technologies.

You can probably also search the university library and search for the dissertations and theses that were result of this project.

Welcome to 10 years ago...

http://i30www.ira.uka.de/research/documents/l4ka/1 995/ukernel-construction.pdf

Will2k_is_here makes an excelent point. I don't have to deal with Joe Six Pack too much, (mostly someone requesting that I help a friend of their's out) but I still see "Blue e == Internet" behavior. Another post in this thread requests that we all remember MS history. I'd imagine that's a reference to the MS getting anything, staking their claim, and getting something almost workable out by the 3.1 release.

So far MS is clearly losing in the UI, and in content freshness. Does it matter? The NO side of me remembers that of the Joe Six Pack contacts I've had in the past couple of months, at least half had never heard of at least one of two major non-MS properties. Specifically, the Google search service, and the Firefox Web browser.

No way am I counting MS out. I might even bet on them, except for one thing: APIs. I'm betting that Google APIs will attract a lot of geek talent. And that Google can capitalize on this in a way that doesn't involve a 'pay to use' model.

Google has hired a lot of talent. It's going to be very interesting to see how this plays out.

And, as a first closing thought, how do we define 'long term'? I'd love to see Google do well, but I haven't drunk all of the Google 'Do No Evil' KoolAid. Google has become a verb. To those who use it a lot, it's become a single point of failure. Redundancy is good. The more good search services that are out there, the better. One dominant engine has also given birth to Googlewashing http://www.theregister.co.uk/2003/04/03/antiwar_sl ogan_coined_repurposed/. Not a Good Thing.

I still use other general services, such as Alta Vista http://www.altavista.com/. Specialized engines also abound, such as The Collection of Computer Science Bibliographies http://liinwww.ira.uka.de/bibliography/.

The second and last closing thought is a question. Referring to Joe Six Pack just sounds demeaning as hell. Slashdotters know who I mean, and probably realize that I don't mean to sound like some elitist prick.

What term do you use?

And while I prefer (x)emacs with auctex for writing the document, that is not for the faint of heart. Use a front end, Kile looks like a good one for Linux (And just install the kde libs if you prefer a gnome frontend) Don't us Lyx, it is not real LaTeX. You may want to try TeXmacs, sounds good, I have not tried it.

For handling bibliographies, bibtex is unbeatable, but UI can be improved. Bibview is my method of choice, even though it does not have all the latest snazy look and feel features, as it is a Xaw Programm and you will probably have to have your packet manager install another lib.

Main adavantage of Bibtex is that you can get ready made entries while searching for sources. If you do computer science for instance there is The Collection of Computer Science Bibliographies with allmost 2 million entries, many of which are linked to CiteSeer.

All of these programs come ready made on my prefered distribution (SuSE), and I gues they will be avaliable on yours as well.

Don't use Word or OpenOffice for anything larger than ~10 Pages. It will not make you happy, and when somebody tells you to change the format you will have to do it by hand. On each page. Repeativly.

Yes, MacOS X is Mach-based. Mach, however, is not really a microkernel in the true sense of the word. Compared to L4's size, Mach is a huge monster. Somebody else already provided a link to an introductory (if old, from 1996) article by the L4 creator Jochen Liedtke.

would it make any sense for Apple to look at L4?

As a matter of fact, the L4KA group is looking into this. See, for example, this thesis currently in progress.

The main benefit is that L4 is actually a true microkernel. It has something like seven system calls that basically handle interprocess communication and address spaces. Everything else needs to be done by user-level processes. L4 separates policy from mechanism, that is, it provides the basic mechanisms and leaves it to the actual OS implementation what policies to implement. It has a very tiny memory footprint and about every optimization possible to operate extremely fast. This is important as in a microkernel environment, much more IPC takes place. Mach sucks here as their IPC operations are terribly slow. L4's IPC speed and its general size show that it's actually feasible to write a real microkernel without taking a non-negligible performance hit. L4Ka::Pistachio is an L4 implementation done completely in C++, which makes code maintenance much nicer, and goes to prove that it is in fact possible to create an efficient microkernel implementation in C++.

It would probably make sense for Apple to look at L4 (as it does for the Hurd), but of course L4 provides much, much less than Mach does (which is good! It's a microkernel after all) and therefore Apple (or, maybe, my friend working on that thesis I mentioned above) would have to reimplement all low-level system services besides address space handling and IPC around L4, in user-level processes. It is probably feasible, but still a long way away.

How about a microkernel Linux?

Take the time to read their paper about performance and issues related to linux on L4 - interesting stats like a 5% penalty for L4, as compared to a 25% for Mach...

Are there any good benchmarks out there comparing Xen to VMWare? this PDF contains benchmarks for very specific operations, not entire programs, but indicates that Xen is much faster for those operations. Though it also notes that VMWare's license prevents people from publishing benchmarks. So... This might mean that VMWare itself realizes that they have severe performance problems in places?

1. Create a Grub boot disk: http://i30www.ira.uka.de/~ud3/mkgrubdisk/
2. Download the installer .iso and put it in an EXT2, EXT3, or (V)FAT partition. Remember where it is.
3. Extract the initrd and vmlinuz files from the CD iso (mount -t iso9660 netboot.iso /mnt/cd -o loop) to this partition (again... remember the location)
4. Create a menu.lst on the Grub floopy with the following:

   title New Install
   kernel (hd0,0)/boot/newinstall/vmlinuz root=/dev/ram devfs=mount,dall ramdisk_size=17000
   initrd (hd0,0)/boot/newinstall/initrd.gz

   Or just type the relevant info into the grub prompt. Of course, edit these values to reflect your real file locations.
5. Reboot
6. Start the install... Woohoo!!!

True. I'd be for an upward one, and without the tic-tac-toe raster. Maybe a little more dynamic as well. Maybe a little bit like this.

But, in any case, by branding yourself with a single logo you promote stereotypes and generalizations. Which I'm not so sure we'd want. You'd have to fight one hell of a fight to get people to associate the right things with your logo (i.e., with You)... that may work for, say, Nike and the Swoosh (unfortunately), but Hackers just don't have a marketing department. By the time we'd all be equipped with that logo somewhere, it might already have been picked up by the media the wrong way, marking us all with an image we don't want.

this paper it's "objective" >>

In my case, SpamAssassin run at my University's CS department has been working extremely well for me, even better since they updated to use Bayesian filtering. My statistics since 2003-03-05, i.e. for the last 174 days:

• 3324 True positives
• 88 False negatives
• 0 False positives
• Somewhere around 2500 "True negatives"; though some mailing lists I receive are effectively whitelisted since mails are sorted in their respective IMAP folders by their mailing list affiliation before being filtered by their Spam status.

That gives me a 97.42% ratio of correctly classified Spam, i.e. true positives vs. false negatives.

Maybe, if such a comparison is done, they should rather configure and train each filter to the best of its abilities, using the same reference data, and then compare the results... that would be a little more real-world usable. Additionally, one could of course also look at different use cases, such as the Office worker case or the Programmer case, where the latter one is subscribed to more mailing lists, for example.

Studies that compare programming languages are hard to find (not to mention hard to do!). The best example I know is Lutz Prechelt, who did a comparison of C,C++,Java,Perl,Python, Rexx and TCL for one particular text-processing application. He tried to measure different things like productivity, number of bugs, memory consumption, speed, etc.

Studies that compare programming languages are hard to find (not to mention hard to do!). The best example I know is Lutz Prechelt, who did a comparison of C,C++,Java,Perl,Python, Rexx and TCL for one particular text-processing application. He tried to measure different things like productivity, number of bugs, memory consumption, speed, etc.

I have little doubt the "metrics you've seen" are in fact very unrepresentative of real world apps. You should be looking at papers like this:

http://www.ipd.uka.de/~prechelt/Biblio/jccpprtTR.p df

Now, the interesting thing about your post is that it sounds like (notice I say "sounds", not "is") you're a Java person, and you're more than a little threatened by Python. Sure, Python is faster for most things, requires less code to accomplish the same task, and is much easier to maintain, but Java still has it's place. You're safe.

The best reference I have seen is the oft-quoted empirical comparison of C....

That gives about a factor of 3 between a typical scripting language and a non-scripting one. But the worst Java/C++ programmers were much worse.

I can easily imagine an unskilled C++ programmer, taking much longer then an talented script programmer. As any fule know, the best programmers are much better than the mean.

God, the Amiga was so fucking cool.

What made it work so well was:

• Amiga Exec made adding virtual devices pretty simple. It wasn't a hack, and didn't require any serious wizardry.
• XPK. XPK was a defacto-standard interface for compressing and/or encrypting. Write your app to that interface, and you instantly get to take advantage of a whole bunch of bit twiddler's work. Write a new compression method or cipher, and instantly a thousand apps know how to use it.

It's a shame, I don't see anything like XPK popping up on other platforms. Linux's crypto API is sorta about halfway there, I guess?

OTOH, maybe it's not that big of a deal. Back in the 1990s (esp the early 1990s) there was still a lot of algorithmic competition and research, and it made sense that people would want to try out different compression algorithms. These days, zlib's "deflation" is pretty much the only thing most people need, and there's only a small handfull of block ciphers (3DES, *fish, AES, and maybe IDEA (though probably not, thanks to the patent)) that people should be using. Between AES and Deflation, I guess all the bases are covered so a general-purpose plugin system isn't all that necessary.

Still, it had a great coolness factor.

Take a look at Python. It is as powerful as Perl, if not more so, and excels where Perl is lacking: syntactical clarity. I often wish C++ was as clear as Python.

Recently I was faced with a little programming job: Recursively parse a directory tree, examine all the files in said tree and do a complex search and replace operation that required some smarts that couldn't be implemented easily with regular expressions. I dreaded to hack that up in C. Even though I had programmed some perl a while back, the syntax was so convoluted that I couldn't remember any of it. Fortunately, I had recently bought a couple books on Python (but hadn't looked at them yet). After one hour of reading and coding, I was done with the little project! Granted, the code did not utilize a lot of powerful features, but it worked like a charm and got the job done. Since then, I've been using Python with ever increasing pleasure.

The only issue with Python is the "grouping of statements by indentation" which may take you about 10 minutes to get used to unless you hate it so much that you can't get over it. But before you condemm it, read Guido van Rossum's comments on the matter.

An interesting comparison of the major scripting languages with C++ and Java can be found here.

IMHO, one of the major factors of increased programming productivity is the spreading use of powerful, interpreted languages like perl, python and Ruby.

Sorry I mangled the above link. An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a search/string-processing program

"lost interest," yes...

It looks like the "i486 or better" asm versions all have Prof. Dr. Jochen Liedtke as maintainer. Unfortunately (quite so, since he designed L4), he is deceased. (as of June 10, 2001)

But I think it's safe to say that an L4-based kernel would be better than Mach, even if written in C++. A well-optimized design is more important than well-optimized code.

2) Take your best estimate , and double it and add 5 or something....

The standard multiplier used is PI.

There are also some interesting results of programming speed in the Prechelt's comparison of different programming languages: an article, a tech report.

One of the conclusions is that script languages such as Python or Perl are about 2-3 times as fast to program with than Java or C/C++, at least in the small projects. The script programs were also about half as long in lines. There were also some differences in the reliability of the solutions - Python and Tcl had a very good score compared to C, although the small sample size for C may give misleading results.

I'd personally be very interested to see better data for differences between C and C++. I've recently been involved in C again after a long pause, and it seems like an awfully risky language to program with. However, it may be faster than C++, on average, and the Prechelt's results agree with this conception.

2) Take your best estimate , and double it and add 5 or something....

The standard multiplier used is PI.

There are also some interesting results of programming speed in the Prechelt's comparison of different programming languages: an article, a tech report.

One of the conclusions is that script languages such as Python or Perl are about 2-3 times as fast to program with than Java or C/C++, at least in the small projects. The script programs were also about half as long in lines. There were also some differences in the reliability of the solutions - Python and Tcl had a very good score compared to C, although the small sample size for C may give misleading results.

I'd personally be very interested to see better data for differences between C and C++. I've recently been involved in C again after a long pause, and it seems like an awfully risky language to program with. However, it may be faster than C++, on average, and the Prechelt's results agree with this conception.

Yeah, INTERCAL. Do you have to resort to such hyperbole?

Actually it's probably worth pointing out that you can compile INTERCAL to Java bytecode already. See the J-INTERCAL page. Looks like .NET already has some catching up to do.
I, for one, am hoping that I can move my Malbolge code to .NET where it belongs!

The Nanowalker project

The MINIMAN project

However there is more data now, as, Prechelt itself widdened the study, and published in 2000 An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl (a detailed technical report is here).

If you look, from the developer point of view, Python and Perl work times are similar to those of Lisp, along with program sizes.
Of course, from the speed point of view, in the test, none of the scripting language could compete with Lisp.

Anyway some articles by Prechelt are interesting too (as many other research papers ; found via citeseer for instance)

However there is more data now, as, Prechelt itself widdened the study, and published in 2000 An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl (a detailed technical report is here).

If you look, from the developer point of view, Python and Perl work times are similar to those of Lisp, along with program sizes.
Of course, from the speed point of view, in the test, none of the scripting language could compete with Lisp.

Anyway some articles by Prechelt are interesting too (as many other research papers ; found via citeseer for instance)

However there is more data now, as, Prechelt itself widdened the study, and published in 2000 An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl (a detailed technical report is here).

If you look, from the developer point of view, Python and Perl work times are similar to those of Lisp, along with program sizes.
Of course, from the speed point of view, in the test, none of the scripting language could compete with Lisp.

Anyway some articles by Prechelt are interesting too (as many other research papers ; found via citeseer for instance)

However there is more data now, as, Prechelt itself widdened the study, and published in 2000 An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl (a detailed technical report is here).

If you look, from the developer point of view, Python and Perl work times are similar to those of Lisp, along with program sizes.
Of course, from the speed point of view, in the test, none of the scripting language could compete with Lisp.

Anyway some articles by Prechelt are interesting too (as many other research papers ; found via citeseer for instance)

You might write a faster program in C.

You will program faster in Perl (or Python, or Rexx, or Ruby, etc..etc..etc...)

See this for an interesting study.

The following link is to an empirical comparison of a number of scripting and compiled languages. Interesting reading as it takes into account issues such as program lenght, reliability, memory consumption amongst other metrics:

• Language comparison

See:

"An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl"

Kernighan and Pike's The Practice of Programming (reviewed here), especially chapter 7 on performance

This comparison (just popped up from a Google search).

Obvious advice: Measure your current system, find out where it's really spending it's time.

If programmer productivity is irrelevant, you'll be hard pressed to beat well-written C. (And if wishes were horses, beggars would fly.-)

Here is a link to a pdf that has real performance comparisons between scripting languages and c/c++. It has productivity figures as well.

If they can physicially get to your servers, you're fucked in so many ways that it doesn't matter.

Unless your filesystem uses encryption, or can run on top of an encrypted device.

It's based on a book published by G Spencer Brown, the mathematical logician (Laws of Form).

It's called OCL: Object Constraint Language, and it can be used to model formal limitations on methods accessing your objects. A usefull site might be: OCL Home

This language could be fit not only to specify your goals, but also to 'prove' in a mathematical way, that your implementation is following the specification. At the Univ of Karlsrühe, the Key project is specifically aimed at developing software while always checking the specs automatically.

Maybe that is the direction that secure software should take, whether it's Open Source or not: first specify a formal "Security Constraint" in OCL and then start programming.

--Grey

Lutz Prechelt's preprint An Empirical Comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a Search/String-Processing Program (available in ps and pdf only)

See http://python.org/doc/Comparisons.html for a refreshingly unbiased, given that the source is one of the languages in question, selection of similar papers.

I would be interested in knowing the relative effort of creation for each of the languages.

Of course, this is a much more difficult question - but i, for one, think it is a much *much* more interesting one. For a rare and satisfyingly substantial example of a study concerned with just this question, see (postscript) "An Empirical Comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a Search/String-Processing Program". It involves much more than lines-of-code and wild-assed guessing - it's an extensive and rational empirical study that examines programming practice and productivity, and the way that different languages facilititate it. Cool!