I don't think that's true, since it takes some deliberate work to give remote users control of your system in safe languages. In languages like O'Caml and Java, for instance, it is just impossible to run machine code that is part of the user's input. This is a property of the languages. In C it is easy.
The kind of bug which gives a remote user the ability to execute arbitrary code is the worst kind. Those are predominantly buffer overflows and format string bugs.
If you can show me a "natural" O'Caml program with a security hole of buffer-overflow magnitude in it (one that is "new" to O'Caml; it wasn't just as natural in C), I will believe you. Speculating that such bugs would exist is not quite convincing enough...
I agree, but buffer overflows and format strings are the most common ones, and the ones which most easily lead to exploits.
Calling shells with untested user-provided parameters (e.g. 'filename; rm -rf/').
Yes, though this is typically only done in interpreted languages, like perl. Compiled languages (Java, O'Caml) are more likely to
use execv-like system calls.
Constructing filenames out of untested user-provided parameters (e.g. '../etc/passwd' - there should be more of '../' but Slashdot does not like that).
True. This one usually doesn't lead to a direct compromise of the host, though.
Not limiting resources (=> DoS Attacks); note that 'secure' languages are much more prone to that error because programmers usually don't care sbout size...
Yeah, this is a good point. In fact, I bet my ftpd is more vulnerable to DOS attacks than wu_ftpd. (I think the user would have to commit as many resources sending data as I commit to receiving it, though.) However, DOS attacks are much less serious than compromises of the host.
Trigger bugs in the environment (interpreter, compiler's RTL).
Scripting languages: Constructing programme code including user-provided data (e.g. with perl's eval statement).
Yes.. for this reason and the first one, I think scripting languages are also inappropriate (though not as inappropriate as C) for network applications and security-critical work.
My overall point is -- if we can *automatically* get rid of the biggest class of security problems, why aren't we doing it? We can use the time we save checking for those bugs (and patching them) securing the programs in other ways, or perhaps optimizing them so that we get the speed some claim is necessary.
The 99 contest was not at all about designing the language or really even about AI-based characters. It was about the famously NP-complete problem of optimizing pattern matching and decision trees. A good heuristic for compiling pattern matching is *not* already solved, and I'll bet the winning programs written for the 99 contest would beat current compilers.
I think this is bullshit. The DMCA is a bad law, but judges aren't stupid enough to fall for that. Next, would you argue that they outlaw crowbars because it is a tool that can be used to break into a bookstore, where copyrighted works are held?
The DMCA is about digital copy protections like CSS and PDF encryption. It is not about reverse-engineering in general, though it dores restrict certain kinds of reverse-engineering.
Let's make sure we're realistic about what this law covers, and fight it on those fronts. It IS a bad law.
I'm all for microsoft-bashing, but linux is no better in the security arena, it just has more security-adept users. (Apache vs. IIS, I might buy that.)
Try installing a fresh 98 box on the internet (with nobody using it), and a fresh redhat box on the internet (also with nobody using it) and see which one gets hacked first!
Redhat, or someone who makes a user-oriented linux distribution, should put together standard internet services which are written in a higher-level language than C. Perhaps they will not be super high-performance, or perhaps they will not have the advanced features of sendmail or bind that most users don't use. But if they're written in a safe language like Java or O'Caml (or, to a lesser extent, scripting languages like Python) we will see the largest class of security holes vanish overnight -- buffer overflows. (Also, format-style bugs, too!)
Though I don't necessarily think this would slow them down -- even if it did, I am guessing that most people would take security over speed any day. I certainly would; hardware is cheap but my time patching and responding to incidents isn't!
I know that C is highly regarded as a systems programming language; it has many useful features in this respect. But it happens to encourage some idioms which are entirely inappropriate for network or security-critical applications. It's really not that hard to do systems programming in other languages. I kept saying this and people kept arguing with me, so I rewrote ftpd in SML. It only took me a few days; maybe a bigger team or better programmers could crank these out even faster. Here is the source code. (Also identd and fingerd). These are not as featureful as their standard counterparts, but they are much much shorter, and buffer-overflow free.
If they can't do that because it seems like too much work (I believe moving to a more modern language would be worth it anyway), why aren't they at least compiling their default installs with stackguard? This is so easy to use, and makes exploiting buffer overflows so much more difficult. The speed loss is imperceptible and existing code carries over.
Let's leave the last 30 years of the last century behind us and move to a world without buffer overflows! If we do this, we can perhaps spend less time worrying about security (our current practices are NOT WORKING, by the way) and start worrying about more important things!
(Yes, it's true that the sshd problem is just dumb coding and is not C's fault. However, most of the rest of this year's, and last year's big security holes come from buffer overflows. Viz: Code Red worm, BIND exploits, wu_ftpd exploits, etc...)
You mean the author's copyright to the work? I would suppose that the owner of the copyright (either the author or the publishing company) would have given permission for the manufacturer to do this.
Well, I don't think that a view of Trademark good, other IP bad is particularly inconsistent. I like to think about it in terms of how it benefits consumers:
Trademarks help companies distinguish real products (ie, physical goods) from each other, which gives the consumer more accurate information about what product she is buying. This is good. Optimally, all trademarks would equally well describe the product in question, so that ownership of one doesn't give a company an advantage. (This isn't true in practice, but it seems there are plenty of "good names" left).
Similarly, "ownership" of ones password or credit card number is justifiable; the information has no real value aside from it being private.
Ownership of other kinds of information typically does not help the consumer. If a corporation "owns" a song, I can't share it with my friends, even if there's no way they could even detect that I did such a thing. etc. etc. You've heard all the arguments here.
For the most part, I agree with your post. Lots of wannabe free software kids have a tough time giving back, particularly when someone else steals their thunder (viz: even RMS!). I think there is a lot of hipocrisy in the community. The press release is totally immature. But that doesn't mean that there isn't a sensible argument in there, somewhere.
You should try entering one of these contests, then. 72 hours really isn't a very long time! In the 99 contest, a large number of the entries were disqualified in the first round (including almost every C entry). Systems stuff really isn't the hardest programming in the world, you know...
See you there!
Re:Object Oriented programming is overrated
on
Why not Ruby?
·
· Score: 1
What I meant with regard to anonymous "classes" is the following.
In C++: (port to your favorite famous OO language)
struct intpair {
int a;
int b;
intpair (int aa, int bb) : a(aa), b(bb) {}
};
That's a win. Being able to do this is great for data handling, since we don't need to create structs or make reference arguments when creating a function which returns multiple values. (The latter is problematic for compiler optimization and a less natural way to write programs.) Anyway, this is beside my point.
I hear Python includes support for tuples; in this case the code would probably be more like the latter. That's good, but it's not because "Python is OO"!
Python incorporates some good features from other paradigms, such as higher-order functions and anonymous tuples. I hear that they screwed up with higher-order-functions, but you are saying that they are fixing it, which will be good.
For the case of the standard library, OO provides modularity, which is also found in any other modern programming language of any paradigm. It is not at all exclusive to OO.
So what I am saying here is, Python has already taken my advice and incorporated some ideas from other paradigms. Why does everyone think these come from Python being "OO"? Is it just a buzzword compliance thing? Are programmers really that gullible?
Re:Object Oriented programming is overrated
on
Why not Ruby?
·
· Score: 1
Often they are the same in OO languages, but they might not be the same in others.
Inheritance is simply a way of getting some code for free; you include all of your parent class's code. In OO languages, inheriting (unless like a private inheritance in C++, perhaps?) induces subtyping.
Subtyping says that you can provide an object of one type where a supertype is required. In OO languages, typically the only subtyping construct people think about is class subtyping due to inheritance. It may or may not be a mistake to think of char being a subtype of int being a subtype of float in Java, C++, and even C, for instance. In other languages, you might have subtyping relationships that have nothing to do with inheritance (perhaps because your language doesn't support/encourage it).
Re:Object Oriented programming is overrated
on
Why not Ruby?
·
· Score: 1
You are still missing the original point of my post. Though exception handling is part of most OO languages, and works well with it, it is by no means a feature that is found only in OO languages. It's found in most modern programming languages, such as SML, which is definitely not OO. The construct is orthogonal.
Since programmers like yourself tend to conflate constructs like exception handling with OOP, I say that many people believe OOP is more than it really is, and therefore it is overrated.
If indeed you have been arguing all along that you use the subtyping hierarchy frequently to catch a set of errors all at once (but not all errors or a list of specific errors, since those would be supported without subtyping), then perhaps you have a claim against my argument. I'm not sure if I'd believe it, but at least we'd be talking about the same thing. What you said here about namespaces would be true of any language (OO or not) with modules.
Re:Object Oriented programming is overrated
on
Why not Ruby?
·
· Score: 1
No -- I would say that procedural programming is obsolete.
OO is just one of the many good modern programming paradigms. It is overrated because there are several others, yet people seem to equate OO with most of the features of modern programming languages which are NOT exclusive to OO.
Re:Object Oriented programming is overrated
on
Why not Ruby?
·
· Score: 1
You are wrong. Subtyping doesn't have anything to do with exception handling.
Re:Object Oriented programming is overrated
on
Why not Ruby?
·
· Score: 1
An AC writes:
> You are also forgetting function languages, such as LISP, Scheme,...
Actually, that is precisely what I had in mind, since my favorite language happens to be in that category.
The fact that everyone seems to think that me saying OOP is overrated implies that I think procedural is the way to go is emphasizing my point (and frustrating me). Read the post again!
Re:Object Oriented programming is overrated
on
Why not Ruby?
·
· Score: 1
My point is that these features (otherwise known as abstract data types) are available in all modern programming languages. SML, for instance, is a decidedly non-OO language, and yet it is easy (easier, I'd say) to do data abstraction and encapsulation.
Most of the things people like about OOP are features of all advanced languages, and that's why I say it is overrated.
Re:Object Oriented programming is overrated
on
Why not Ruby?
·
· Score: 1
My whole point is that it is not just procedural and OO!!! Read it again!
My point was not that there is some sort of advantage of procedural languages over OO languages, but that there are more than just two paradigms! All other modern programming languages support modularity ("namespaces"), many in a nicer way than C++.
Re:Object Oriented programming is overrated
on
Why not Ruby?
·
· Score: 1
Exception handling has nothing to do with OOP; it is an entirely orthogonal feature!
Please god, not C++. Let's pick something type-safe, even Java if we need it to be OO, so that our applications aren't crashing all the time. (Sometimes opening us up to remote exploits.) Who cares if it is a little slower? 1.2 ghz chips are $70, last time I checked...
Anyway, I don't think sticking with one language is good, because it means that innovation will stagnate. There may not be many new ideas in all these scripting languages, but some of us at research institutions think we are coming up with some good stuff...;)
Object Oriented programming is overrated
on
Why not Ruby?
·
· Score: 3
Well, I'll bite.
I say Object Oriented Programming is highly overrated.
Many programmers I know seem to believe there are about 2 ways to program in the world: procedural (uncivilized, messy spaghetti code, no support for large programs, etc.) and object oriented (civilized). The fact is that all modern languages spanning many different paradigms support civilized programming, even if they are not "object oriented". And what I infer from this is that objects are primarily useful only when the data you are processing are neatly expressed as objects, that is, they actually *are* objects. (For instance, if they describe operations, then higher order functions are much handier.)
Every civilized language that I know of supports the features that I believe most people think of as object-oriented. Even languages which are adamantly *not* Object Oriented (such as SML, of which I am a stalwart fan) support them.
Some examples are aggregate data (in the case of SML, aggregate data is supported much more cleanly than OO languages I know of, since one can make anonymous "classes"), abstract data types, exceptions, threads, polymorphism, garbage collection, and type safety. (The advanced languages I'm implicitly referring to also support some really nice features typically not in OO languages, such as higher-order functions, static typing, parameterized modules, and generics or "parametric polymorphism".)
So what really separates Objects from regular old modern programming? I say two things: inheritance and subtyping. Essentially, if you are not making use of subtyping (using it for polymorphism doesn't count, since other modern languages support polymorphism in their own way) in your program, then you aren't using any OO-exclusive features. Do you actually write programs the way that they introduce OO in textbooks? (A motorcycle derives from wheeled_vehicle, which derives from vehicle?)... In scripts??
So I guess what I'm saying is, be sure you know what you mean when you say "OOP", since there is very little which is particularly special about OO languages. In my opinion, there is not much need in scripting language for subtyping. So I say that emulating Java or C++ is not a very worthwile goal, except inasmuch as it might engender comfortable syntax/semantics for those who have only used those kinds of languages. Let's look to some other advanced languages to get us useful features in our scripting languages, and encourage the use of them.
Why are racks so damn expensive?
They're just hunks of metal, and yet the ones I always see cost hundreds and hundreds of dollars. Even those seem unfinished (barbs and sharp bits everywhere); to get a *nice* rack you have to spend even more.
What's the deal? Is the market so small that they can charge this much, or is there some secret process in the manufacturing that makes it so expensive?
Slashdot Mirror
I don't think that's true, since it takes some deliberate work to give remote users control of your system in safe languages. In languages like O'Caml and Java, for instance, it is just impossible to run machine code that is part of the user's input. This is a property of the languages. In C it is easy.
The kind of bug which gives a remote user the ability to execute arbitrary code is the worst kind. Those are predominantly buffer overflows and format string bugs.
If you can show me a "natural" O'Caml program with a security hole of buffer-overflow magnitude in it (one that is "new" to O'Caml; it wasn't just as natural in C), I will believe you. Speculating that such bugs would exist is not quite convincing enough...
An AC rebuts,
> It's not hard to do in C, either; you use strncpy() instead of strcpy() and 90% of overflows go away.
I hear this a lot. If it is true, then why do we still have so many overflows in new programs?
I agree, but buffer overflows and format strings are the most common ones, and the ones which most easily lead to exploits.
Calling shells with untested user-provided parameters (e.g. 'filename; rm -rf /').
Yes, though this is typically only done in interpreted languages, like perl. Compiled languages (Java, O'Caml) are more likely to
use execv-like system calls.
Constructing filenames out of untested user-provided parameters (e.g. ' ../etc/passwd' - there should be more of '../' but Slashdot does not like that).
True. This one usually doesn't lead to a direct compromise of the host, though.
Not limiting resources (=> DoS Attacks); note that 'secure' languages are much more prone to that error because programmers usually don't care sbout size...
Yeah, this is a good point. In fact, I bet my ftpd is more vulnerable to DOS attacks than wu_ftpd. (I think the user would have to commit as many resources sending data as I commit to receiving it, though.) However, DOS attacks are much less serious than compromises of the host.
Trigger bugs in the environment (interpreter, compiler's RTL).
Scripting languages: Constructing programme code including user-provided data (e.g. with perl's eval statement).
Yes.. for this reason and the first one, I think scripting languages are also inappropriate (though not as inappropriate as C) for network applications and security-critical work.
My overall point is -- if we can *automatically* get rid of the biggest class of security problems, why aren't we doing it? We can use the time we save checking for those bugs (and patching them) securing the programs in other ways, or perhaps optimizing them so that we get the speed some claim is necessary.
The 99 contest was not at all about designing the language or really even about AI-based characters. It was about the famously NP-complete problem of optimizing pattern matching and decision trees. A good heuristic for compiling pattern matching is *not* already solved, and I'll bet the winning programs written for the 99 contest would beat current compilers.
I think this is bullshit. The DMCA is a bad law, but judges aren't stupid enough to fall for that. Next, would you argue that they outlaw crowbars because it is a tool that can be used to break into a bookstore, where copyrighted works are held?
The DMCA is about digital copy protections like CSS and PDF encryption. It is not about reverse-engineering in general, though it dores restrict certain kinds of reverse-engineering.
Let's make sure we're realistic about what this law covers, and fight it on those fronts. It IS a bad law.
I'm all for microsoft-bashing, but linux is no better in the security arena, it just has more security-adept users. (Apache vs. IIS, I might buy that.)
Try installing a fresh 98 box on the internet (with nobody using it), and a fresh redhat box on the internet (also with nobody using it) and see which one gets hacked first!
No. The DMCA is about tools for defeating protection schemes to gain access to a copy-protected work.
This is different, though it might also be illegal due to some other silly computer crime law.
Awright, soapbox time!
Redhat, or someone who makes a user-oriented linux distribution, should put together standard internet services which are written in a higher-level language than C. Perhaps they will not be super high-performance, or perhaps they will not have the advanced features of sendmail or bind that most users don't use. But if they're written in a safe language like Java or O'Caml (or, to a lesser extent, scripting languages like Python) we will see the largest class of security holes vanish overnight -- buffer overflows. (Also, format-style bugs, too!)
Though I don't necessarily think this would slow them down -- even if it did, I am guessing that most people would take security over speed any day. I certainly would; hardware is cheap but my time patching and responding to incidents isn't!
I know that C is highly regarded as a systems programming language; it has many useful features in this respect. But it happens to encourage some idioms which are entirely inappropriate for network or security-critical applications. It's really not that hard to do systems programming in other languages. I kept saying this and people kept arguing with me, so I rewrote ftpd in SML . It only took me a few days; maybe a bigger team or better programmers could crank these out even faster. Here is the source code . (Also identd and fingerd ). These are not as featureful as their standard counterparts, but they are much much shorter, and buffer-overflow free.
If they can't do that because it seems like too much work (I believe moving to a more modern language would be worth it anyway), why aren't they at least compiling their default installs with stackguard ? This is so easy to use, and makes exploiting buffer overflows so much more difficult. The speed loss is imperceptible and existing code carries over.
Let's leave the last 30 years of the last century behind us and move to a world without buffer overflows! If we do this, we can perhaps spend less time worrying about security (our current practices are NOT WORKING, by the way) and start worrying about more important things!
(Yes, it's true that the sshd problem is just dumb coding and is not C's fault. However, most of the rest of this year's, and last year's big security holes come from buffer overflows. Viz: Code Red worm, BIND exploits, wu_ftpd exploits, etc...)
What? What the hell does that mean?
You mean the author's copyright to the work? I would suppose that the owner of the copyright (either the author or the publishing company) would have given permission for the manufacturer to do this.
I can't believe this was modded up to 4.
What I use I2 for:
Quake 3 Arena.
Well, I don't think that a view of Trademark good, other IP bad is particularly inconsistent. I like to think about it in terms of how it benefits consumers:
Trademarks help companies distinguish real products (ie, physical goods) from each other, which gives the consumer more accurate information about what product she is buying. This is good. Optimally, all trademarks would equally well describe the product in question, so that ownership of one doesn't give a company an advantage. (This isn't true in practice, but it seems there are plenty of "good names" left).
Similarly, "ownership" of ones password or credit card number is justifiable; the information has no real value aside from it being private.
Ownership of other kinds of information typically does not help the consumer. If a corporation "owns" a song, I can't share it with my friends, even if there's no way they could even detect that I did such a thing. etc. etc. You've heard all the arguments here.
For the most part, I agree with your post. Lots of wannabe free software kids have a tough time giving back, particularly when someone else steals their thunder (viz: even RMS!). I think there is a lot of hipocrisy in the community. The press release is totally immature. But that doesn't mean that there isn't a sensible argument in there, somewhere.
You should try entering one of these contests, then. 72 hours really isn't a very long time! In the 99 contest, a large number of the entries were disqualified in the first round (including almost every C entry). Systems stuff really isn't the hardest programming in the world, you know...
See you there!
What I meant with regard to anonymous "classes" is the following.
In C++: (port to your favorite famous OO language)
struct intpair {
int a;
int b;
intpair (int aa, int bb) : a(aa), b(bb) {}
};
intpair twoxthreex(int x) {
return intpair(2 * x, 3 * x);
}
In SML:
fun twoxthreex x = (2 * x, 3 * x)
That's a win. Being able to do this is great for data handling, since we don't need to create structs or make reference arguments when creating a function which returns multiple values. (The latter is problematic for compiler optimization and a less natural way to write programs.) Anyway, this is beside my point.
I hear Python includes support for tuples; in this case the code would probably be more like the latter. That's good, but it's not because "Python is OO"!
Python incorporates some good features from other paradigms, such as higher-order functions and anonymous tuples. I hear that they screwed up with higher-order-functions, but you are saying that they are fixing it, which will be good.
For the case of the standard library, OO provides modularity, which is also found in any other modern programming language of any paradigm. It is not at all exclusive to OO.
So what I am saying here is, Python has already taken my advice and incorporated some ideas from other paradigms. Why does everyone think these come from Python being "OO"? Is it just a buzzword compliance thing? Are programmers really that gullible?
Often they are the same in OO languages, but they might not be the same in others.
Inheritance is simply a way of getting some code for free; you include all of your parent class's code. In OO languages, inheriting (unless like a private inheritance in C++, perhaps?) induces subtyping.
Subtyping says that you can provide an object of one type where a supertype is required. In OO languages, typically the only subtyping construct people think about is class subtyping due to inheritance. It may or may not be a mistake to think of char being a subtype of int being a subtype of float in Java, C++, and even C, for instance. In other languages, you might have subtyping relationships that have nothing to do with inheritance (perhaps because your language doesn't support/encourage it).
You are still missing the original point of my post. Though exception handling is part of most OO languages, and works well with it, it is by no means a feature that is found only in OO languages. It's found in most modern programming languages, such as SML, which is definitely not OO. The construct is orthogonal.
Since programmers like yourself tend to conflate constructs like exception handling with OOP, I say that many people believe OOP is more than it really is, and therefore it is overrated.
If indeed you have been arguing all along that you use the subtyping hierarchy frequently to catch a set of errors all at once (but not all errors or a list of specific errors, since those would be supported without subtyping), then perhaps you have a claim against my argument. I'm not sure if I'd believe it, but at least we'd be talking about the same thing. What you said here about namespaces would be true of any language (OO or not) with modules.
No -- I would say that procedural programming is obsolete.
OO is just one of the many good modern programming paradigms. It is overrated because there are several others, yet people seem to equate OO with most of the features of modern programming languages which are NOT exclusive to OO.
You are wrong. Subtyping doesn't have anything to do with exception handling.
An AC writes:
...
> You are also forgetting function languages, such as LISP, Scheme,
Actually, that is precisely what I had in mind, since my favorite language happens to be in that category.
The fact that everyone seems to think that me saying OOP is overrated implies that I think procedural is the way to go is emphasizing my point (and frustrating me). Read the post again!
My point is that these features (otherwise known as abstract data types) are available in all modern programming languages. SML, for instance, is a decidedly non-OO language, and yet it is easy (easier, I'd say) to do data abstraction and encapsulation.
Most of the things people like about OOP are features of all advanced languages, and that's why I say it is overrated.
My whole point is that it is not just procedural and OO!!! Read it again!
My point was not that there is some sort of advantage of procedural languages over OO languages, but that there are more than just two paradigms! All other modern programming languages support modularity ("namespaces"), many in a nicer way than C++.
Exception handling has nothing to do with OOP; it is an entirely orthogonal feature!
Please god, not C++. Let's pick something type-safe, even Java if we need it to be OO, so that our applications aren't crashing all the time. (Sometimes opening us up to remote exploits.) Who cares if it is a little slower? 1.2 ghz chips are $70, last time I checked...
;)
Anyway, I don't think sticking with one language is good, because it means that innovation will stagnate. There may not be many new ideas in all these scripting languages, but some of us at research institutions think we are coming up with some good stuff...
Well, I'll bite.
... In scripts??
I say Object Oriented Programming is highly overrated.
Many programmers I know seem to believe there are about 2 ways to program in the world: procedural (uncivilized, messy spaghetti code, no support for large programs, etc.) and object oriented (civilized). The fact is that all modern languages spanning many different paradigms support civilized programming, even if they are not "object oriented". And what I infer from this is that objects are primarily useful only when the data you are processing are neatly expressed as objects, that is, they actually *are* objects. (For instance, if they describe operations, then higher order functions are much handier.)
Every civilized language that I know of supports the features that I believe most people think of as object-oriented. Even languages which are adamantly *not* Object Oriented (such as SML, of which I am a stalwart fan) support them.
Some examples are aggregate data (in the case of SML, aggregate data is supported much more cleanly than OO languages I know of, since one can make anonymous "classes"), abstract data types, exceptions, threads, polymorphism, garbage collection, and type safety. (The advanced languages I'm implicitly referring to also support some really nice features typically not in OO languages, such as higher-order functions, static typing, parameterized modules, and generics or "parametric polymorphism".)
So what really separates Objects from regular old modern programming? I say two things: inheritance and subtyping. Essentially, if you are not making use of subtyping (using it for polymorphism doesn't count, since other modern languages support polymorphism in their own way) in your program, then you aren't using any OO-exclusive features. Do you actually write programs the way that they introduce OO in textbooks? (A motorcycle derives from wheeled_vehicle, which derives from vehicle?)
So I guess what I'm saying is, be sure you know what you mean when you say "OOP", since there is very little which is particularly special about OO languages. In my opinion, there is not much need in scripting language for subtyping. So I say that emulating Java or C++ is not a very worthwile goal, except inasmuch as it might engender comfortable syntax/semantics for those who have only used those kinds of languages. Let's look to some other advanced languages to get us useful features in our scripting languages, and encourage the use of them.
Here's a question for you:
Why are racks so damn expensive?
They're just hunks of metal, and yet the ones I always see cost hundreds and hundreds of dollars. Even those seem unfinished (barbs and sharp bits everywhere); to get a *nice* rack you have to spend even more.
What's the deal? Is the market so small that they can charge this much, or is there some secret process in the manufacturing that makes it so expensive?