Fucking Slashdot weenie. The original article (I advise everyone to read it, as it is the only decent post on this article) made some extremely good points. Your debating skills are non-existent, and you don't even address anything the guy said, so why don't you just SHUT THE FUCK UP until you get a clue?
Tiny69 isn't the only one that needs to get a life.
Now I shall remember the name Accipiter as a boring self-righteous idiot. Although, given your.sig, you didn't need to even type anything to put that across.
I won't touch C# with a ten-foot barge pole for at least 2 years. That's just common sense. Nothing out of Redmond ever works until at least service pack 4.
Other than that, you're just regurgitating the typical boring Slashdot opinion set in a highly overdramatic style. To call a language dangerous, a corporation evil and to literally identify a real manager with the PHB from Dilbert is at best inaccurate, and at worst displays a shocking seperation between you and reality. The world is not as black and white as you would like it to be.
The ratio is one manager to one employee. This is the true ratio found in most mammoth corporations, and is a perfect match.
That is the diseconomy of scale - half your employees are management - and it's unavoidable. But the "diseconomies of scale" we hear about are vastly worse than a mere 50% drop in productivity.
I spotted that one. It's garbage. If anything has a reference to an object, it won't be collected, and if nothing has a reference to an object, it can't be used. Garbage collecting is 100% robust in this aspect.
Mind you, this is one of Napster's programmers - the company famous for "taking existing filesharing software and making it work with MP3s" - about on a par with Baby's First JavaScript.
No-one knows the future; C# may succeed on the Windows platforms and be a vital line on your resume, or it may flop totally and be rejected by developers, and M$ may drop it in 2 years.
As for C and C++, I find it amusing that the one part of C which you like (pointers) is the one aspect which has taken the most criticism over the past few decades!
You don't really explain why you dislike C/C++ - apart from having someone "watching your back". Well, the solution is to learn to write robust code. Run-time errors are useful, but if you're shipping software it shouldn't have any, so run-time error checking is a waste of the end-user's time.
I mean, I could understand it if you hated the C syntax, or C pointers, or C++ backasswards compatibility with C, or the appalling non-portability of C. But if you dislike C because it reveals your subtle bugs to you, then you should really learn how to write bug-free code. It's a much better thing to have on your resume than knowing ANY specific language. And C/C++ are going to be around for a while.
Diseconomies are persistent, because people try to run organizations today the way they ran them 100 years ago.
The limitations are in human abilities too... well, not so much "human", but there are information-theoretical limits to what any subsystem (human) can achieve - both in terms of understanding (information input) and activity (information output).
Improving communications can help, but it is the structure of the communication systems that is important. If the system is structured badly, nothing can save it, but better and better technology can stave off the day it collapses.
In short, everything you say is true, but I disagree with your conclusion.
For more information on what cybernetics has to say on topics such as these, I suggest the following books:
Stafford Beer: Decision and control
Stafford Beer: The Brain of the Firm
Stafford Beer: The Heart of Enterprise
Your last comment seems true, but isn't necessarily. The diseconomies of scale apply because mankind has absolutely no idea how to organize itself. If mankind could work this one out (rather, if mankind could read the books where this is already worked out) then massive corporations would not only be efficient, but may even be beneficial.
Don't know about Emacs... I hate the damned thing anyway;) After VisualStudio for C++, Emacs for LISP is just so 60s;)
Source-as-data-structure is certainly a principle in LISP... and you're right, this is independent of compiling vs interpreting. But it's not just (eval) - the whole CLOS object model is much more reminiscent of Smalltalk (also originally interpreted) than C++ (always compiled). You should see the amount of code a generic CLOS function takes! It's that sort of design decision I mean... C++ is designed for fast method lookup and execution (which makes is less powerful) while LISP is designed in a milieu where a method lookup through a table is not much slower than a function call (which is true in an interpreted language).
Another good example of this is Java Bytecode. CPU emulators are slow at best, since CPUs are not designed to be emulated (the MIPS does OK; the 68000 is a bitch). The Java virtual CPU is designed for emulation, therefore has features which would be expensive to implement in silicon but cheap to implement in software; it also avoids all the bit twiddling that silicon finds so easy and software finds so hard.
There's always this sort of trade-off in a language design, and LISP definitely (to me) takes the "this will be interpreted" path. And, of course, it did used to be (and still is in ACL until you compile it).
Even compiled LISP still has the equivalent of (eval 'symbol) which is a lookup from a symbol... this is another example of its interpreted legacy. A compiled C++ program doesn't need to keep the symbol table around!
I don't think any of them are... what you would call without flaw.
The judge specifically denies the validity of the evidence claiming Napster harmed record sales; he also denies the validity of the evidence claiming Napster helped record sales. This evidence was not part of his decision.
You're the biased one, my friend. You misread that one quite badly.
I must be missing all these cool LISP IDEs that must be all the rage these days. My environment is Emacs, and it shows me shit except the code, with some less-than-perfect coloring and indentation.
As for + and (eval) - of course (eval) is generally avoided (unless you need it), and of course you shouldn't rebind +, but you're missing the point. LISP's very design, from (eval) up through CLOS, is based on its interpreted nature. You just wouldn't design a language like that if your design brief said "it's intended for compilation".
a lot of natively compiled implementations have to include the compiler
There aren't a lot of natively compiled implementations! We found about six. ACL contains an interpreter. I don't know about other LISP implementations; maybe one of them does JIT compilation for (eval)... somehow I doubt it. It's not much work writing a LISP interpreter on top of a pre-existing runtime.
I don't know the whole history of LISP from way back when, maybe it was interpreted for the first few versions from 20 years ago.:)
Any function with (eval) or equivalent is an interpreted language. The general LISP program contains (eval), therefore the general compiled LISP program still needs to contain a full LISP interpreter! Remember, with (eval) you can do anything - rebind +, for instance...
Splay trees are something I've never come across - I shall have to read up on them!
Variables aren't that difficult to create in LISP. We use the (let) form from Scheme. Having many intermediate variables (rather than complex expressions) definitely helps code readability. But it's more than that. Consider the following form:
(foo bar 2)
Depending on what bar is, and what foo is, this may be any of:
A global function call with bar and 2 as parameters
A call to "foo", a member function of "bar", with parameter 2
Something else entirely - e.g. a macro which creates an entire template class
That's what I mean by LISP being hard to read. In C++ the syntax distinguishes all three cases without you having to know anything a priori about foo and bar.
Now, I know that ACL can optimize function calls nicely, and provides typing (which is a prerequisite for the former). And I know that CLOS member calls are slow. This is what makes C++ so much faster. In OO you want virtually everything to be an object (down to some granularity level). Thanks to fast member invocation and inlining, C++ lets you take that granularity very low indeed. In C++ you can encapsulate single longs and still see no speed loss, provided all the accessors are inlined. You can't do this in CLOS, because the cost of a member call is so heavy. This makes CLOS great for large-scale objects, but useless for small-scale ones. For general OO, therefore, I'd say CLOS is a little useless. It would be great for objects on the scale of COM objects - no doubt Microsoft will make VisualLISP for.NET;) - but no good for many of the design patterns used in C++.
As for the LISP vs C++ comparison - it sounds about right for a procedural task. If you compared large object-oriented LISP applications vs their C++ counterparts I would be amazed if any of the LISP programs beat any of the C++ programs... but it's certainly possible to write clunky C++ code!
Let's take this to email if you have any reply.
I'm loath to do that, since others may be reading this.
C++ is a compiled language - it is designed for compilation. LISP is an interpreted language - it is designed for interpretation. The fact that there are C++ interpreters and LISP compilers does not change this simple fact.
In my experience with Allegro Common LISP, the compiler produces dog-slow code even on the highest "optimization" settings. I laugh at this paper that "shows" LISP to be 50% faster than C++. There are always articles saying Language X is faster than Language Y, no matter what X and Y are. They set out to prove something, and prove it, by ignoring evidence to the contrary and magnitfying supporting evidence. If you're convinced by this paper, and not just wowed by its conclusion (hey, you obviously love LISP) then maybe I should read it.
Just looking at CLOS, the amount of effort the compiler has to make just to dispatch a method invocation makes it seem extremely unlikely to me that a CLOS program is ever going to even approach an equivalent C++ program in speed terms.
Mind you, I only have experience with ACL (Allegro Common LISP) which performs extremely poorly. If you know of a faster compiler which is commercially available, please let me know!!! We have a mission-critical application written in CLOS which needs an order-of-magnitude speed improvement. I was considering recoding it in C++;)
You mention many features of LISP which are useful - and indeed they are. LISP is very good at wrapping things in other things. That's all its syntax does, so it should be;) However, Smalltalk has an equally powerful object model, and it uses the more friendly infix notation (let's face it, prefix notation is unreadable to anyone but Ubergeeks).
As to your obfuscated C function, well wow, I've never seen one of those before;) I can't be bothered decoding that function. It has no comments, no meaningful variable names, and no meaningful function name. If I had to guess I'd say it was doing an operation on a balanced tree.
But my point about syntax is that C's syntax helps you read the code, whereas LISP's syntax gives you no help at all. Sure you can write ugly C and LISP code, but I defy you to show me pretty LISP code! No-one's saying that every C program is readable - many quite famously are not - but we are trying very very hard to make our LISP code readable, and still failing.
LISP is certainly a more powerful language than C++, I'll concede that, but that sort of power scares me. Wait until you work on a bigass project and you'll see why.
LISP is a joke. I use it every day. Not many professionals can say that!
The good things about C and C++ are that they have a syntax. LISP has no syntax. You cannot simply look at a LISP program and read it; you need to understand the functioning of every single macro. You can (and people do) write your own language in LISP. You have to, to get anything useful done. It makes the average LISP program incomprehensible to anyone but the original author.
LISP may have sexy features, but only because the sexy features are easy to add to an interpreted syntax-less language. You can do anything you want in LISP, and that is both its power and its weakness.
It's a great academic language, but for serious work (i.e. big projects with many programmers) LISP is simply not viable.
In my work I have a dire need for a C++-style language which:
Is low-level enough to permit tweaking of memory allocation and can map classes onto hardware register sets (so Java is out)
Has intrinsic vector types so I can write code for vector units which is optimized by the compiler
Doesn't lost all its potential optimizations to pointer aliasing problems
This would be great for writing games! The world may have enough C-like languages, but that doesn't mean that specific sections of it don't need their own.
One crucial thing to ask about is the company's size and their rate of expansion. If a company is increasing size from 10-15 to 25-30 in a matter of months, beware. Such companies are just about to go through adolescence, and it can be a painful process. Especially avoid such companies if they say things like "we've never needed documentation in the past [when we had 5 programmers] so we don't need it now [when we have 20]".
Slashdot Mirror
Fucking Slashdot weenie. The original article (I advise everyone to read it, as it is the only decent post on this article) made some extremely good points. Your debating skills are non-existent, and you don't even address anything the guy said, so why don't you just SHUT THE FUCK UP until you get a clue?
Now I shall remember the name Accipiter as a boring self-righteous idiot. Although, given your .sig, you didn't need to even type anything to put that across.
Other than that, you're just regurgitating the typical boring Slashdot opinion set in a highly overdramatic style. To call a language dangerous, a corporation evil and to literally identify a real manager with the PHB from Dilbert is at best inaccurate, and at worst displays a shocking seperation between you and reality. The world is not as black and white as you would like it to be.
That is the diseconomy of scale - half your employees are management - and it's unavoidable. But the "diseconomies of scale" we hear about are vastly worse than a mere 50% drop in productivity.
Is "corporatism" a buzzword? Most buzzwords are invented and employed in order to sell you stuff; this is quite the opposite!
Mind you, this is one of Napster's programmers - the company famous for "taking existing filesharing software and making it work with MP3s" - about on a par with Baby's First JavaScript.
Er ... don't you mean 12 pounds?
No-one knows the future; C# may succeed on the Windows platforms and be a vital line on your resume, or it may flop totally and be rejected by developers, and M$ may drop it in 2 years.
As for C and C++, I find it amusing that the one part of C which you like (pointers) is the one aspect which has taken the most criticism over the past few decades!
You don't really explain why you dislike C/C++ - apart from having someone "watching your back". Well, the solution is to learn to write robust code. Run-time errors are useful, but if you're shipping software it shouldn't have any, so run-time error checking is a waste of the end-user's time.
I mean, I could understand it if you hated the C syntax, or C pointers, or C++ backasswards compatibility with C, or the appalling non-portability of C. But if you dislike C because it reveals your subtle bugs to you, then you should really learn how to write bug-free code. It's a much better thing to have on your resume than knowing ANY specific language. And C/C++ are going to be around for a while.
[XmlElement("shipTo")]public Address ShipTo;
That'll be changed incorrectly by a developer within a week.
If a language needs specific attributes, they should be built into the language in such a manner as to eliminate this sort of pointless redundancy.
What statistics? I've just heard a load of guff with no substance from the "Napster helps record sales" crowd.
The limitations are in human abilities too ... well, not so much "human", but there are information-theoretical limits to what any subsystem (human) can achieve - both in terms of understanding (information input) and activity (information output).
Improving communications can help, but it is the structure of the communication systems that is important. If the system is structured badly, nothing can save it, but better and better technology can stave off the day it collapses.
In short, everything you say is true, but I disagree with your conclusion.
For more information on what cybernetics has to say on topics such as these, I suggest the following books:
Stafford Beer: Decision and control
Stafford Beer: The Brain of the Firm
Stafford Beer: The Heart of Enterprise
Nicely said, if I may say so.
Your last comment seems true, but isn't necessarily. The diseconomies of scale apply because mankind has absolutely no idea how to organize itself. If mankind could work this one out (rather, if mankind could read the books where this is already worked out) then massive corporations would not only be efficient, but may even be beneficial.
So I presume that the libertarians on Slashdot are against the break-up of Microsoft by the DOJ?
Source-as-data-structure is certainly a principle in LISP ... and you're right, this is independent of compiling vs interpreting. But it's not just (eval) - the whole CLOS object model is much more reminiscent of Smalltalk (also originally interpreted) than C++ (always compiled). You should see the amount of code a generic CLOS function takes! It's that sort of design decision I mean ... C++ is designed for fast method lookup and execution (which makes is less powerful) while LISP is designed in a milieu where a method lookup through a table is not much slower than a function call (which is true in an interpreted language).
Another good example of this is Java Bytecode. CPU emulators are slow at best, since CPUs are not designed to be emulated (the MIPS does OK; the 68000 is a bitch). The Java virtual CPU is designed for emulation, therefore has features which would be expensive to implement in silicon but cheap to implement in software; it also avoids all the bit twiddling that silicon finds so easy and software finds so hard.
There's always this sort of trade-off in a language design, and LISP definitely (to me) takes the "this will be interpreted" path. And, of course, it did used to be (and still is in ACL until you compile it).
Even compiled LISP still has the equivalent of (eval 'symbol) which is a lookup from a symbol ... this is another example of its interpreted legacy. A compiled C++ program doesn't need to keep the symbol table around!
I don't think any of them are ... what you would call without flaw.
The judge specifically denies the validity of the evidence claiming Napster harmed record sales; he also denies the validity of the evidence claiming Napster helped record sales. This evidence was not part of his decision.
You're the biased one, my friend. You misread that one quite badly.
As for + and (eval) - of course (eval) is generally avoided (unless you need it), and of course you shouldn't rebind +, but you're missing the point. LISP's very design, from (eval) up through CLOS, is based on its interpreted nature. You just wouldn't design a language like that if your design brief said "it's intended for compilation".
a lot of natively compiled implementations have to include the compiler
There aren't a lot of natively compiled implementations! We found about six. ACL contains an interpreter. I don't know about other LISP implementations; maybe one of them does JIT compilation for (eval) ... somehow I doubt it. It's not much work writing a LISP interpreter on top of a pre-existing runtime.
Any function with (eval) or equivalent is an interpreted language. The general LISP program contains (eval), therefore the general compiled LISP program still needs to contain a full LISP interpreter! Remember, with (eval) you can do anything - rebind +, for instance ...
Splay trees are something I've never come across - I shall have to read up on them!
Variables aren't that difficult to create in LISP. We use the (let) form from Scheme. Having many intermediate variables (rather than complex expressions) definitely helps code readability. But it's more than that. Consider the following form:
(foo bar 2)
Depending on what bar is, and what foo is, this may be any of:
That's what I mean by LISP being hard to read. In C++ the syntax distinguishes all three cases without you having to know anything a priori about foo and bar.
Now, I know that ACL can optimize function calls nicely, and provides typing (which is a prerequisite for the former). And I know that CLOS member calls are slow. This is what makes C++ so much faster. In OO you want virtually everything to be an object (down to some granularity level). Thanks to fast member invocation and inlining, C++ lets you take that granularity very low indeed. In C++ you can encapsulate single longs and still see no speed loss, provided all the accessors are inlined. You can't do this in CLOS, because the cost of a member call is so heavy. This makes CLOS great for large-scale objects, but useless for small-scale ones. For general OO, therefore, I'd say CLOS is a little useless. It would be great for objects on the scale of COM objects - no doubt Microsoft will make VisualLISP for .NET ;) - but no good for many of the design patterns used in C++.
As for the LISP vs C++ comparison - it sounds about right for a procedural task. If you compared large object-oriented LISP applications vs their C++ counterparts I would be amazed if any of the LISP programs beat any of the C++ programs ... but it's certainly possible to write clunky C++ code!
Let's take this to email if you have any reply.
I'm loath to do that, since others may be reading this.
In my experience with Allegro Common LISP, the compiler produces dog-slow code even on the highest "optimization" settings. I laugh at this paper that "shows" LISP to be 50% faster than C++. There are always articles saying Language X is faster than Language Y, no matter what X and Y are. They set out to prove something, and prove it, by ignoring evidence to the contrary and magnitfying supporting evidence. If you're convinced by this paper, and not just wowed by its conclusion (hey, you obviously love LISP) then maybe I should read it.
Just looking at CLOS, the amount of effort the compiler has to make just to dispatch a method invocation makes it seem extremely unlikely to me that a CLOS program is ever going to even approach an equivalent C++ program in speed terms.
Mind you, I only have experience with ACL (Allegro Common LISP) which performs extremely poorly. If you know of a faster compiler which is commercially available, please let me know!!! We have a mission-critical application written in CLOS which needs an order-of-magnitude speed improvement. I was considering recoding it in C++ ;)
You mention many features of LISP which are useful - and indeed they are. LISP is very good at wrapping things in other things. That's all its syntax does, so it should be ;) However, Smalltalk has an equally powerful object model, and it uses the more friendly infix notation (let's face it, prefix notation is unreadable to anyone but Ubergeeks).
As to your obfuscated C function, well wow, I've never seen one of those before ;) I can't be bothered decoding that function. It has no comments, no meaningful variable names, and no meaningful function name. If I had to guess I'd say it was doing an operation on a balanced tree.
But my point about syntax is that C's syntax helps you read the code, whereas LISP's syntax gives you no help at all. Sure you can write ugly C and LISP code, but I defy you to show me pretty LISP code! No-one's saying that every C program is readable - many quite famously are not - but we are trying very very hard to make our LISP code readable, and still failing.
LISP is certainly a more powerful language than C++, I'll concede that, but that sort of power scares me. Wait until you work on a bigass project and you'll see why.
The good things about C and C++ are that they have a syntax. LISP has no syntax. You cannot simply look at a LISP program and read it; you need to understand the functioning of every single macro. You can (and people do) write your own language in LISP. You have to, to get anything useful done. It makes the average LISP program incomprehensible to anyone but the original author.
LISP may have sexy features, but only because the sexy features are easy to add to an interpreted syntax-less language. You can do anything you want in LISP, and that is both its power and its weakness.
It's a great academic language, but for serious work (i.e. big projects with many programmers) LISP is simply not viable.
- Is low-level enough to permit tweaking of memory allocation and can map classes onto hardware register sets (so Java is out)
- Has intrinsic vector types so I can write code for vector units which is optimized by the compiler
- Doesn't lost all its potential optimizations to pointer aliasing problems
This would be great for writing games! The world may have enough C-like languages, but that doesn't mean that specific sections of it don't need their own.One crucial thing to ask about is the company's size and their rate of expansion. If a company is increasing size from 10-15 to 25-30 in a matter of months, beware. Such companies are just about to go through adolescence, and it can be a painful process. Especially avoid such companies if they say things like "we've never needed documentation in the past [when we had 5 programmers] so we don't need it now [when we have 20]".
Not forgetting that LISP is a very important language in modern industry.