You still seem to think that runtime type checking is a feature of interpreters. It is not. Common Lisp is compiled, Dylan is compiled, yet they provide runtime type checking. And of course, CL and Dylan compilers are written in CL and Dylan, respectively.
In precise terms, this is an issue of strong typing (Lisp, Dylan, ML, Java) vs. weak typing (C/C++).
Oh, we have some pseudo-scientific measurements in this regard. Gwydion Dylan comes with a Dylan-to-C-translator. Average performance loss when compared wo writing directly in C is between 10 and 30%, and that's mainly due to garbage collection overhead and some register lossage (we have to pass an extra stack pointer to the generated C functions).
Bounds checking is nearly free on modern CPUs. Branch prediction and superscalar execution buys us that. Measurements show the overhead to be less than 0.1%, for sieve of Erathostenes, which does array access all of the time.
And OCaml shows that you can even beat C in terms of performance once you can do global optimizations like deciding which registers to save and which not on a per-function basis.
Last, but not least, having a real high-level language available means it is easier to implement funky algorithms that reduce algorithmic complexity. It's most often the brain and not the muscle that makes software run fast.
Re:We really need a different language
on
Secure Programming
·
· Score: 1
I tend to repeat myself on this: Lisp (and Dylan, which is Lisp with an easier syntax) are not interpreted languages. There are compilers available that match C in terms of speed.
Unfortunately, the same isn't true for Python, which makes it inattractive for a number of applications.
I'm not trolling. You're very own words further up in the thread make it sound like the security win with different languages isn't that big, and probably not big enough to warrant a switch.
I am sorry if I am mis-reading you, but that is probably what most people see when reading your words. I think it is essential to tell people that using C/C++ is a huge security risk, and that they should only use it when there are no alternatives. Often enough, there are.
And I haven't seen a convincing argument yet why operating systems have to be written in C. In fact, I have a proof-of-concept OS written in Dylan.
I fail to see how Ada would prevent algorithmic optimizations. Your claim is outright ridiculous. Maybe you can come up with an example?
And I think that doing tedious bookkeeping is something the computer should do for me. In case you haven't noticed, your average PC is between 10 to 100 times faster than needed for most applications, such as web and mail servers, file servers etc. But building a secure computer seems to be too hard for most people.
Point in fact: history has shown that all programmers, even the best ones, make mistakes. With C/C++, you end up with maximum penalty: remotely exploitable overflow.
Sure, even Ada-controlled rockets blow up. That's because it is hard enough to cope with the real problems. Being forced to think about buffer bounds, memory management etc. all of the time just distracts from the real problems.
Oh, your very own web page cites 5 bugs per 1000 LOC for C/C++, and 1 for Java. That's a factor of 5!
The biggest problem that makes C/C++ less secure than other languages is the fact that errors are not contained locally. Every single line of C/C++ in your project can break any other line of your code, violating all security assumptions.
Sure, you have STL. And what does that buy you when there is a buffer overflow in a third party library you're using?
Right, nothing.
Besides, readable and maintainable code is a security feature in itself, which C/C++ just doesn't have. It lacks a lot of abstraction facilities.
Not seeing C/C++ as a source of many of our security problems is a state of denial.
Re:Interepreted languages help, but aren't a cure-
on
Secure Programming
·
· Score: 1
It amazes me that all people can think of when talking about "alternatives to C" is interpreted languages.
Folks, compilers for real languages have been available for ages. Dylan, Common Lisp, OCaml is probably the top of tools these days.
Re:We already HAVE the different language.
on
Secure Programming
·
· Score: 1
In fact, GNU Emacs is a weak clone of the Lisp Machine operating system. You might have meant that as a joke, but it isn't.
There are two advantages with the Lisp syntax: it is easy to write parsers for, and is easy to write powerful macros that make the syntax extensible.
Now we don't have 1958 anymore, and writing parsers for high-level languages is no black art anymore. A proper syntax makes code easier to read and to maintain, and laziness on the side of the compiler writer cannot be held up as an argument to make usage of the language harder to the user.
And Dylan introduces a macro system that works much like the Lisp macros used to, only with an Algol-like syntax. Basically, the macros work on the parse tree instead of the string representation, and thus can be used to extend the syntax of the language, If you want, you can think about it as adding productions to the grammar.
Dylan definitely is a dialect of Lisp, with another syntax. And it has been cleaned up in a lot of places, too (OO from the ground up, for instance).
Hey, we've been doing this since before slashdot existed. And the point of an open-air gathering is that you actually get some sun and oxygen, without getting Internet withdrawal symptoms after a day.
The Chaos Communication Camp will also host the Gimp Developers Conference, and a meeting of the Discordian Section of the Knights of the Lambda Calculus (that's Lisp hackers, for the uninitiated).
I'll bring my Lisp Machine, complete with Space Cadet keyboard.
Well, Lisp Machines not only have a better UI, they have a better operating system. If your job forces you to eat feces, that's sad, but doesn't make observations about good and bad OSes wrong.
And here is the master thesis of Tom Knight, describing the architecture of the Lisp Machine. If you want to see one in action, visit me on the Chaos Communication Camp.
And yes, UNIX royally sucks. It plays in the same suckage leage as Windows, of course, but still it sucks. It's a clone of technologies of the early 70ies, and a bad one.
It's indeed a little more complicated than that. One of our slogan says "Öffentliche Daten nützen, private Daten schützen"; which roughly translates to: "utilize public information, protect private information".
Regarding lists of single women living alone, that's a premium membership service. Platinum members even get access to the list of single women hacking kernel code.
I am holding in my hands a document from the European patent office on the registration of the mark "convergence".
Since we're not the 52nd state of the US (yet, see http://www.cptech.org/ecom/jurisdiction/hague.html ), they can sue as all day long, it won't help:).
DirectFB was originally developed for set-top-box applications, i.e., for systems that have neither 3D-acceleration, nor the extra megabyte of RAM that X eats up. So OpenGL-on-X was no option (and yes, we did consider that, we're not stupid, you know).
And DirectFB is a userland library.
You better check your facts before flaming like that.
Slashdot Mirror
You still seem to think that runtime type checking is a feature of interpreters. It is not. Common Lisp is compiled, Dylan is compiled, yet they provide runtime type checking. And of course, CL and Dylan compilers are written in CL and Dylan, respectively.
In precise terms, this is an issue of strong typing (Lisp, Dylan, ML, Java) vs. weak typing (C/C++).
Weak typing is dangerous.
Oh, we have some pseudo-scientific measurements in this regard. Gwydion Dylan comes with a Dylan-to-C-translator. Average performance loss when compared wo writing directly in C is between 10 and 30%, and that's mainly due to garbage collection overhead and some register lossage (we have to pass an extra stack pointer to the generated C functions).
Bounds checking is nearly free on modern CPUs. Branch prediction and superscalar execution buys us that. Measurements show the overhead to be less than 0.1%, for sieve of Erathostenes, which does array access all of the time.
And OCaml shows that you can even beat C in terms of performance once you can do global optimizations like deciding which registers to save and which not on a per-function basis.
Last, but not least, having a real high-level language available means it is easier to implement funky algorithms that reduce algorithmic complexity. It's most often the brain and not the muscle that makes software run fast.
I tend to repeat myself on this: Lisp (and Dylan, which is Lisp with an easier syntax) are not interpreted languages. There are compilers available that match C in terms of speed.
Unfortunately, the same isn't true for Python, which makes it inattractive for a number of applications.
I'm not trolling. You're very own words further up in the thread make it sound like the security win with different languages isn't that big, and probably not big enough to warrant a switch.
I am sorry if I am mis-reading you, but that is probably what most people see when reading your words. I think it is essential to tell people that using C/C++ is a huge security risk, and that they should only use it when there are no alternatives. Often enough, there are.
And I haven't seen a convincing argument yet why operating systems have to be written in C. In fact, I have a proof-of-concept OS written in Dylan.
So, you don't believe in secure languages, eh?
I fail to see how Ada would prevent algorithmic optimizations. Your claim is outright ridiculous. Maybe you can come up with an example?
And I think that doing tedious bookkeeping is something the computer should do for me. In case you haven't noticed, your average PC is between 10 to 100 times faster than needed for most applications, such as web and mail servers, file servers etc. But building a secure computer seems to be too hard for most people.
Point in fact: history has shown that all programmers, even the best ones, make mistakes. With C/C++, you end up with maximum penalty: remotely exploitable overflow.
Sure, even Ada-controlled rockets blow up. That's because it is hard enough to cope with the real problems. Being forced to think about buffer bounds, memory management etc. all of the time just distracts from the real problems.
Worse, you're not getting any benefit in return!
Oh, your very own web page cites 5 bugs per 1000 LOC for C/C++, and 1 for Java. That's a factor of 5!
The biggest problem that makes C/C++ less secure than other languages is the fact that errors are not contained locally. Every single line of C/C++ in your project can break any other line of your code, violating all security assumptions.
Sure, you have STL. And what does that buy you when there is a buffer overflow in a third party library you're using?
Right, nothing.
Besides, readable and maintainable code is a security feature in itself, which C/C++ just doesn't have. It lacks a lot of abstraction facilities.
Not seeing C/C++ as a source of many of our security problems is a state of denial.
It amazes me that all people can think of when talking about "alternatives to C" is interpreted languages.
Folks, compilers for real languages have been available for ages. Dylan, Common Lisp, OCaml is probably the top of tools these days.
In fact, GNU Emacs is a weak clone of the Lisp Machine operating system. You might have meant that as a joke, but it isn't.
There are two advantages with the Lisp syntax: it is easy to write parsers for, and is easy to write powerful macros that make the syntax extensible.
Now we don't have 1958 anymore, and writing parsers for high-level languages is no black art anymore. A proper syntax makes code easier to read and to maintain, and laziness on the side of the compiler writer cannot be held up as an argument to make usage of the language harder to the user.
And Dylan introduces a macro system that works much like the Lisp macros used to, only with an Algol-like syntax. Basically, the macros work on the parse tree instead of the string representation, and thus can be used to extend the syntax of the language, If you want, you can think about it as adding productions to the grammar.
Dylan definitely is a dialect of Lisp, with another syntax. And it has been cleaned up in a lot of places, too (OO from the ground up, for instance).
Somewhere in the main hack tent. I'll try to bring a Lambda flag.
Hey, we've been doing this since before slashdot existed. And the point of an open-air gathering is that you actually get some sun and oxygen, without getting Internet withdrawal symptoms after a day.
The Chaos Communication Camp will also host the Gimp Developers Conference, and a meeting of the Discordian Section of the Knights of the Lambda Calculus (that's Lisp hackers, for the uninitiated).
I'll bring my Lisp Machine, complete with Space Cadet keyboard.
Well, Lisp Machines not only have a better UI, they have a better operating system. If your job forces you to eat feces, that's sad, but doesn't make observations about good and bad OSes wrong.
Hey, the fact that Windows sucks too does *not* make UNIX any better!
And the book was written before one of the authors started to work for Microsoft.
A mirror of the document is here.
And here is the master thesis of Tom Knight, describing the architecture of the Lisp Machine. If you want to see one in action, visit me on the Chaos Communication Camp.
One online Symbolics Lisp Machine museum is here.
And yes, UNIX royally sucks. It plays in the same suckage leage as Windows, of course, but still it sucks. It's a clone of technologies of the early 70ies, and a bad one.
Because nobody would know which corner of the world Paulshof, Altlandsberg actually is.
p Overview">here</a>.
A photo of the site is <a href="https://wiki.camp.ccc.de/Camp/view/Main/Cam
It's indeed a little more complicated than that. One of our slogan says "Öffentliche Daten nützen, private Daten schützen"; which roughly translates to: "utilize public information, protect private information".
Regarding lists of single women living alone, that's a premium membership service. Platinum members even get access to the list of single women hacking kernel code.
The Chaos Computer Club was founded in 1981. So there you go :).
Oh the pain!
This reminds me of when I've heard about an 8-processor Alpha machine with a gigabyte of RAM and a lot of fast SCSI busses being thrown out...
Those guys have bought all of the spare parts and machinery from IBM/Lexmark:
http://www.pckeyboard.com
The IBM Buckling Spring is by far the best keyboard I have ever used. And the noise is a feature, once you start typing 10-20 cps.
Go get one, while they still make them.
I am holding in my hands a document from the European patent office on the registration of the mark "convergence".
l ), they can sue as all day long, it won't help :).
Since we're not the 52nd state of the US (yet, see http://www.cptech.org/ecom/jurisdiction/hague.htm
DirectFB was originally developed for set-top-box applications, i.e., for systems that have neither 3D-acceleration, nor the extra megabyte of RAM that X eats up. So OpenGL-on-X was no option (and yes, we did consider that, we're not stupid, you know).
And DirectFB is a userland library.
You better check your facts before flaming like that.
This is mostly true, except for acceleration functions, and input driver abstraction.
Framebuffer acceleration under Linux still means mmapping the chipset registers and massaging them. DirectFB does this for you.
And how many of them have support for hardware acceleration and alpha transparency?
Right, none.
The company's name is "convergence integrated media GmbH", and we actually own the trademark in Europe.
So there's no risk that they sue us...