You seem to be optimistic about startups. New employees also often work those kinds of hours, but it typically takes six months before they they get stock grants. And the sale of the company, especially in economically difficult times, can be a desperation move as it collapses. A lot of startups fail, and get sold off to competitors. I've even helped manage the integration of purchased startups, and a lot of their staff were very unhappy about the sale.
I just tried incredibly hard to get a 64-bit CPU order done via AMD, for anti-monopoly reasons as well as technical ones. I was overruled by a middle manager whose last job was all HP and that's all he'll sign orders for. It's a shame, really, I could have gotten us a lot more capacity and a better price, at the sacrifice of HP integration tools which no one onsite knows how to use.
> And don't get me started on the stability of AIX vs Linux or BSD, please. I have software here that can make any AIX machine cry and call for mommy, when most Linux distributions just suck it up and carry on.
You use awk?
That question is like asking 'how are men hurt by dogs'. There are a legion of ways a corporate purchase can hurt na employee: The stock price of the purchase may be less than the value which the employee expected or otherwise would receive from a better purchaser. The employee's intellectual property can be folded into the purchasing company's business and then discarded, such as is occurring with Oracle and their purchase of Sleepy Cat Software and the Berkeley Database. The purchaser may strip out the asset they consider valuable to their business and discard all other personnel and resources. The employees may be forced to resign or to transfer to another location they don't like. Their medical insurance may decrease incredibly in coverage, which matters a lot to employees with chronical medical conditions. The new company may have short-sighted management who focus only on quarterly profits, or may be so long-minded that they won't reward an eager employee's short-term productivity.
It's not the only reason. Recovering corporate control from other voting members, especially those who disagree with the board about policy, is sometimes a big reason to buy back stock.
Different shareholders have different dreams. And shareholders are hardly the only investors in a company: those who work there have legal rights as well, and may be served better by different corporate strategies. Being purchased by Microsoft, for example, has been the death knell of many companies with valuable products or even profitable businesses.
It's the dream for the investors. Employees who don't live near the new corporate offices, or who liked actually getting anything done, or the latest who weren't there long enough to have received options, often wind up really hurt by such corporate purchases.
"Yes, Dr. Scott. A laser capable of emitting a beam of pure anti-matter."
It looks like we can no longer shout back 'Then it's not a laser!'
Yes, some of us are old enough to remember going to the Rocky Horror Picture Show before it was a cult classic.
Did the book have any mice in it? You can't get copyright altered without Disney involved, and they've certainly modified copyright law to protect their franchise on Mickey Mouse.
Then there's the wonderful claim that the Christian bread and wine sacrifice as the 'body and blood of Christ' is actually an even older Egyptian ceremony involving the 'death cookie'. This was described in hysterically funny illustrations in one of the tracts by Jack Chick, which are great entertainment.
But you're not the one who said technological superiority doesn't matter. I suspect you underestimate its power. But if Lisp is so amazingly technologically superior, as many of its proponents claim, where is the long-term technical success? It remains a pretty minor set of tools in the computing world, despite its elegance.
1. Bwa-ha-ha! You've never actually studied statistics, I take it, or gone digging through a sales presentation to see what the real specifications of a system are under normal use?
2. There, you have a point. But it's hard to judge a slide rule from a web site. It's like judging a computer from the ads in magazines: it's very helpful to lay your hands on it and see its physical action and its scales. The last time I ordered one, it turned out to be awful. (It was a gift for a teenager learning logarithms: I was actually embarassed at it, and instead gave him my old circular one.)
I still have a pair of my good slide rules. One I use, one I have saved for any grandchildren. They don't need batteries, and they're very handy for teaching engineers that the last few digits of their calculator produced numbers are often a bold-faced lie compared to the real world. But they have gotten tough to get.
Sales and marketing do not need to rely on technological supriority. It's one of many features to market, but genuine technological superiority can provide useful features, lower production costs, reduce maintenance, etc. Now Lisp made a lot of promises to elevate computing. Its great promises to understand the human mind, to deal with ever larger and more complex problems, seems to have not been borne out.
You present a cogent analysis of the issues, thank you. But you've missed a critical point. They were taught, very firmly, to treat each layer of abstraction as entirely unique and unrelated to the other layers. You cannot know that the data structure has a particular order, (one that they were reversing, which was the problem I tried to explain to them!), without stepping to a lower level than the project was originally described at. For example, under heavy load, reading a data file backwards is a nasty performance hit on disk I/O because you still have to often spin the disk to get back around to the previous block. Yet they were either not taught to, or specifically enjoined not to, think or program in such terms. They were apparently graded on 'elegance' in the sense of doing subtle recursions, rather than on understanding and being willing to go down or up a level of abstraction to address a problem.
It made cleanup a mess. There were some useful and subtle things they did that were valuable, but oveall, the systems were terrible until I went through and did things like unrolling loops, switch various styles to iterative rather than recursive operation to gain control of necessary resources, and generally think in lower terms than they'd learned. I'd love to hear that such courses have improved, but it seemed built into the basic text they learned from. (And yes, it was Jerry Sussman's book.)
Oh, my. Oh, dear. You're giving me flashbacks of dealing with those MIT trained clowns. Not this particular issue, but similar ones of using the examples they must have learned in the first half of the term to deal with problems beyond the scope of the course material, and relearning lessons learned the very hard way in other fields. My favorite fun with them involved the fact that people make keyboard errors, and you *must* verify that their arguments are valid before proceeding to implement their typos.
> I have several goals with the language but the most specific one is to create a language that combines the things I like about Ruby and Lisp together.
That sounds perilously close to yet another verson of Lisp. But I accept the concept that a new language might merge the best features of the languages. But let's hope that he avoids the worst features, in the process, because those worst features were absolutely terrible, at least when I had to explain the harsh realities that a layer of abstraction is often poked through by the magician's swords of hardware and data structures.
Where do you see these benefits? If the C-like languages are already implementing the desirable features, then what do we need new implementations of Lisp for?
It's hardly sophistry, it's the whole point of the patent system and of how I get paid. Technological superiority has market value: while market failure is not proof of technological inferiority, it's proof that the features are not so stunning and useful that they've demonstrated their value other than in the ivory tower. I like the ivory tower: a great deal of fascinating work occurs there, and the lessons of a Lisp expert like Jerry Sussman are fascinating. But the language and its teaching propagate real errors.
I'm afraid that my experience was in cleaning up after some of your peers, or possibly even students of yours. The people I had to clean up after were taught by Jerry Sussman at MIT, and they learned extremely bad habits of completely ignoring the higher and lower levels of the problems. I've read Jerry Sussman's 'koans' of Lisp programming, and agree with them overall. It's a shame that the lessons of those koans didn't seem to show up in the programmers _I_ met out of that course.
The result was the _excessive_ use of abstraction, to such extents that I had to go in and violate the abstractions to explain 'You are presenting the data in the wrong order: if you present it in the correct order, which you have been taught not to think about, you eliminate 95% of the load that you are seeing. You need to think about what the system is doing with the numbers, not ignore the underlying hardware or infrastructure.'
A compiled language, like C or even Java, can also try to deal with this by unrolling loops and transforming structures to avoid such classic problems. An interpreted language cannot, and the programmer must understand the limitations, which these gentlemen were never taught.
That's not being a 'lousy programmer'. The problem results from following the most elementary paradigms of Lisp programming: ignore what is happening at the higher and lower levels, and avoid specifying the interfaces to those other details in detail. The results are very painful to clean up.
Then, if market performance and superior technology have nothing to do with each other, why should anyone invest their money in research? Or are you saying that all technology is performance art, and we may as well paint our bodies paisley and recite poetry from lightposts, because it's just as useful?
Let's look at it again: if Lisp were that superior in solving big problems, it would have solved some of them. As it is, Lisp faces real problems in garbage collection and system resource management, or at least it has traditionally faced such problems. If combining it with Ruby helps address those, great. But I'll believe it when I see it performing well. Even theoretically addressable problems like the traveling salesman problem, or chess playing, break down badly in Lisp until you ignore its 'layers of abstraction' approach and pay attention to the lower levels of the problem.
Yes, I've had to program in Lisp, and it's wonderful for writing an exciting few lines of demoware. But I've also cleaned up after people taught awful, awful habits of ignoring the interface between those 'layers of abstraction' and leaving the problem of formatting data or I/O to someone else entirely.
Slashdot Mirror
You seem to be optimistic about startups. New employees also often work those kinds of hours, but it typically takes six months before they they get stock grants. And the sale of the company, especially in economically difficult times, can be a desperation move as it collapses. A lot of startups fail, and get sold off to competitors. I've even helped manage the integration of purchased startups, and a lot of their staff were very unhappy about the sale.
Oh, I was thinking you could crash it with only 3 lines of awk as a non-root users.
'Hairy back ends' can conceal some major jumps of system constipation. Are you sure it was the AIX that was the issue?
I just tried incredibly hard to get a 64-bit CPU order done via AMD, for anti-monopoly reasons as well as technical ones. I was overruled by a middle manager whose last job was all HP and that's all he'll sign orders for. It's a shame, really, I could have gotten us a lot more capacity and a better price, at the sacrifice of HP integration tools which no one onsite knows how to use.
> And don't get me started on the stability of AIX vs Linux or BSD, please. I have software here that can make any AIX machine cry and call for mommy, when most Linux distributions just suck it up and carry on. You use awk?
That question is like asking 'how are men hurt by dogs'. There are a legion of ways a corporate purchase can hurt na employee: The stock price of the purchase may be less than the value which the employee expected or otherwise would receive from a better purchaser. The employee's intellectual property can be folded into the purchasing company's business and then discarded, such as is occurring with Oracle and their purchase of Sleepy Cat Software and the Berkeley Database. The purchaser may strip out the asset they consider valuable to their business and discard all other personnel and resources. The employees may be forced to resign or to transfer to another location they don't like. Their medical insurance may decrease incredibly in coverage, which matters a lot to employees with chronical medical conditions. The new company may have short-sighted management who focus only on quarterly profits, or may be so long-minded that they won't reward an eager employee's short-term productivity.
The list goes on and on.
It's not the only reason. Recovering corporate control from other voting members, especially those who disagree with the board about policy, is sometimes a big reason to buy back stock.
Different shareholders have different dreams. And shareholders are hardly the only investors in a company: those who work there have legal rights as well, and may be served better by different corporate strategies. Being purchased by Microsoft, for example, has been the death knell of many companies with valuable products or even profitable businesses.
It's the dream for the investors. Employees who don't live near the new corporate offices, or who liked actually getting anything done, or the latest who weren't there long enough to have received options, often wind up really hurt by such corporate purchases.
"Yes, Dr. Scott. A laser capable of emitting a beam of pure anti-matter." It looks like we can no longer shout back 'Then it's not a laser!' Yes, some of us are old enough to remember going to the Rocky Horror Picture Show before it was a cult classic.
Did the book have any mice in it? You can't get copyright altered without Disney involved, and they've certainly modified copyright law to protect their franchise on Mickey Mouse.
Then there's the wonderful claim that the Christian bread and wine sacrifice as the 'body and blood of Christ' is actually an even older Egyptian ceremony involving the 'death cookie'. This was described in hysterically funny illustrations in one of the tracts by Jack Chick, which are great entertainment.
But you're not the one who said technological superiority doesn't matter. I suspect you underestimate its power. But if Lisp is so amazingly technologically superior, as many of its proponents claim, where is the long-term technical success? It remains a pretty minor set of tools in the computing world, despite its elegance.
Oh, I dunno. Don't you think she wore this outfit both then and now? [Somewhat adult URL below]
http://www.topcosales.us/product_detail.asp?PID=0231-7
1. Bwa-ha-ha! You've never actually studied statistics, I take it, or gone digging through a sales presentation to see what the real specifications of a system are under normal use? 2. There, you have a point. But it's hard to judge a slide rule from a web site. It's like judging a computer from the ads in magazines: it's very helpful to lay your hands on it and see its physical action and its scales. The last time I ordered one, it turned out to be awful. (It was a gift for a teenager learning logarithms: I was actually embarassed at it, and instead gave him my old circular one.)
Oh, my. I'd laugh the thermometer out of my mouth if I heard that in a hospital: I remember that children's song about 'Bananaphone'.
I still have a pair of my good slide rules. One I use, one I have saved for any grandchildren. They don't need batteries, and they're very handy for teaching engineers that the last few digits of their calculator produced numbers are often a bold-faced lie compared to the real world. But they have gotten tough to get.
Sales and marketing do not need to rely on technological supriority. It's one of many features to market, but genuine technological superiority can provide useful features, lower production costs, reduce maintenance, etc. Now Lisp made a lot of promises to elevate computing. Its great promises to understand the human mind, to deal with ever larger and more complex problems, seems to have not been borne out.
You present a cogent analysis of the issues, thank you. But you've missed a critical point. They were taught, very firmly, to treat each layer of abstraction as entirely unique and unrelated to the other layers. You cannot know that the data structure has a particular order, (one that they were reversing, which was the problem I tried to explain to them!), without stepping to a lower level than the project was originally described at. For example, under heavy load, reading a data file backwards is a nasty performance hit on disk I/O because you still have to often spin the disk to get back around to the previous block. Yet they were either not taught to, or specifically enjoined not to, think or program in such terms. They were apparently graded on 'elegance' in the sense of doing subtle recursions, rather than on understanding and being willing to go down or up a level of abstraction to address a problem.
It made cleanup a mess. There were some useful and subtle things they did that were valuable, but oveall, the systems were terrible until I went through and did things like unrolling loops, switch various styles to iterative rather than recursive operation to gain control of necessary resources, and generally think in lower terms than they'd learned. I'd love to hear that such courses have improved, but it seemed built into the basic text they learned from. (And yes, it was Jerry Sussman's book.)
Oh, my. Oh, dear. You're giving me flashbacks of dealing with those MIT trained clowns. Not this particular issue, but similar ones of using the examples they must have learned in the first half of the term to deal with problems beyond the scope of the course material, and relearning lessons learned the very hard way in other fields. My favorite fun with them involved the fact that people make keyboard errors, and you *must* verify that their arguments are valid before proceeding to implement their typos.
Now go read the fine article where it says:
> I have several goals with the language but the most specific one is to create a language that combines the things I like about Ruby and Lisp together.
That sounds perilously close to yet another verson of Lisp. But I accept the concept that a new language might merge the best features of the languages. But let's hope that he avoids the worst features, in the process, because those worst features were absolutely terrible, at least when I had to explain the harsh realities that a layer of abstraction is often poked through by the magician's swords of hardware and data structures.
Where do you see these benefits? If the C-like languages are already implementing the desirable features, then what do we need new implementations of Lisp for?
It's hardly sophistry, it's the whole point of the patent system and of how I get paid. Technological superiority has market value: while market failure is not proof of technological inferiority, it's proof that the features are not so stunning and useful that they've demonstrated their value other than in the ivory tower. I like the ivory tower: a great deal of fascinating work occurs there, and the lessons of a Lisp expert like Jerry Sussman are fascinating. But the language and its teaching propagate real errors.
I'm afraid that my experience was in cleaning up after some of your peers, or possibly even students of yours. The people I had to clean up after were taught by Jerry Sussman at MIT, and they learned extremely bad habits of completely ignoring the higher and lower levels of the problems. I've read Jerry Sussman's 'koans' of Lisp programming, and agree with them overall. It's a shame that the lessons of those koans didn't seem to show up in the programmers _I_ met out of that course.
The result was the _excessive_ use of abstraction, to such extents that I had to go in and violate the abstractions to explain 'You are presenting the data in the wrong order: if you present it in the correct order, which you have been taught not to think about, you eliminate 95% of the load that you are seeing. You need to think about what the system is doing with the numbers, not ignore the underlying hardware or infrastructure.'
A compiled language, like C or even Java, can also try to deal with this by unrolling loops and transforming structures to avoid such classic problems. An interpreted language cannot, and the programmer must understand the limitations, which these gentlemen were never taught.
That's not being a 'lousy programmer'. The problem results from following the most elementary paradigms of Lisp programming: ignore what is happening at the higher and lower levels, and avoid specifying the interfaces to those other details in detail. The results are very painful to clean up.
Then, if market performance and superior technology have nothing to do with each other, why should anyone invest their money in research? Or are you saying that all technology is performance art, and we may as well paint our bodies paisley and recite poetry from lightposts, because it's just as useful?
Let's look at it again: if Lisp were that superior in solving big problems, it would have solved some of them. As it is, Lisp faces real problems in garbage collection and system resource management, or at least it has traditionally faced such problems. If combining it with Ruby helps address those, great. But I'll believe it when I see it performing well. Even theoretically addressable problems like the traveling salesman problem, or chess playing, break down badly in Lisp until you ignore its 'layers of abstraction' approach and pay attention to the lower levels of the problem.
Yes, I've had to program in Lisp, and it's wonderful for writing an exciting few lines of demoware. But I've also cleaned up after people taught awful, awful habits of ignoring the interface between those 'layers of abstraction' and leaving the problem of formatting data or I/O to someone else entirely.