Functional languages are nicely parallelizable because they don't have side effects. Unfortunately, real life is full of side effects. So, a pure functional language has to "hack" the side effect by passing it around everywhere as a closure. That gets old really, really quickly. Which is why useful functional languages contain constructs with side-effects (not without accompanying hand-wringing from purists).
Back in the 70's, people like Jack Dennis used to promise the DARPA that they could parallelize the old Fortran code used to do complex military simulations by converting the Fortran code to a pure functional language. It would be wonderful! Well, they couldn't, and it wasn't.
The above notwithstanding, IF you can coerce a problem into a form in which a functional language can be effectively employed, the benefits can be huge. The code tends to be more elegant and more readable; algorithms that would be difficult to write in an applicative language like C become easy; data structure manipulation is trivial; and so on. Arguments that functional languages are "slow" have been debunked. Arguments that functional languages must be interpreted are wrong.
And, all the syntactic nonsense of C++ and the rest of the "object oriented" languages can be (mercifully) shed. Pure functional languages are object oriented by nature. However, functional languages do have their own idiosyncracies, such as the infamous Lisp "quote", and implementation-dependent funarg problems. So there are cobwebs still.
To sum up: If you have a hard algorithmic problem to solve, a functional language will probably be a better choice, even if you end up re-coding the algorithm in an applicative language later. If you have a device driver to write, though, roll up your sleeves and get out the C manual. But first: make sure to put a debug wrapper around your mallocs (and pad your malloc blocks with patterns on both sides) so you can trap double-frees, underwrites, and overwrites. It will pay many dividends.
Let's not forget Shockley's (and Jensen's) reliance on group IQ tests to "prove" that African Americans are not as bright as other "races" -- a point of view resurrected more recently in "The Bell Curve."
As we now know, it turns out that group IQ tests are completely useless -- almost zero correlation with individually-administered tests. Yet those tired old data continue to be trotted out by academics who should know better.
The damage done by Shockley's IQ assertions was immeasurable. Even if it turns out someday that - say - people with large index fingers are smarter than people with small index fingers, on average - is this a useful result? What should we then do, measure index fingers during job interviews? One can draw no conclusion about an individual from an average. "Research" of this nature simply creates prejudice and encourages discrimination.
...You go down to the local Computer-Rama chain...
Forget Vista, the fact that you were at the Computer-Rama in the first place means that you'll definitely end up wanting to sue somebody for something.
Re:Borland has died after Borland Delphi 7
on
Delphi For PHP Released
·
· Score: 2, Insightful
...blistering crotch fires of agony...
Thank you, that's one to file away in the "useful phrases" department. I like it.
...more likely, you are too young to remember the absolute crap that MS churned out...
I remember. I was working on my degree in CS while Gates was dropping out of Harvard, so I know our Microsoft friends quite well.
What I'm told (by people who should know) is that Gates is smart and he's technical. Just because you didn't like DOS (who did?) and you are annoyed at MS and their slow pace of "innovation" (who isn't?) doesn't mean that everyone at MS is stupid, or that Gates is stupid. That's just a stupid inference.
Some good points. However, when you own your own company, you're an integrator by definition -- or you fail. The good news is you're not working for "the man" -- you ARE "the man." And that makes it OK to take a phone call at 10PM from Australia, or get up at oh-dark-hundred for a flight. Most of the time, it's OK. Ah, hell, who am I kidding, it sucks. But at least if you're successful some suit somewhere isn't the beneficiary. You are.
Exactly. You can say what you like about Gates, but dissing him for his IQ, or his technical talent, or his management of what is arguably the most successful business story of all time, is totally off base.
Well, when I was a wee lad taking 6.251 from Donovan & Madnick at MIT, they threw an IBM Assembler H manual at us and wished us good luck on the first programming task (in two weeks).
So suck it up and RTFM. Although, to be fair, the Assembler H manual is probably one of the finest computer manuals ever written, so it wasn't as bad as it sounds.
There are too many counterexamples to your premise that monopolies will break up naturally on their own. The ADL scandal, for example, shows that large companies, when left alone by regulators, conspire among themselves to ensure market dominance, mutual survival, and high prices.
IBM's troubles started when they were slapped upside the head by the government's ultimately unsuccessful antitrust lawsuit. You may be too young to remember the bad old days when IBM refused to share specifications on their equipment, refused to interoperate with foreign peripherals, sued everyone who tried, and so on. They were Really Bad Guys. I remember; I lived through it. Now because of SCO and Linux they are suddenly Good Guys; but be careful, because a tiger can't change his stripes.
However, none of the above impacts your point about government cooperating with industry; certainly that's bad, certainly it contributes to lack of market flexibility, and certainly it needs to stop (although it won't). But government does have a responsibility to step in when anticompetitive behavior becomes extreme, as happened with AT&T. I remember my mom "saving up" for long distance calls -- literally. You really had to think hard before dialing "1". You couldn't buy a phone, except through AT&T, and you had to rent it month by month (by the time you had rented it for years, you had bought it 20 times over). And they had to come out and "install" your phone, and God forbid if they found an "illegal" extension phone (they just shut off your service, period). And so on. It was outrageous. The bastards were swimming in ill-gotten gains, and they deserved to be smashed into paste, as they were.
Yes, this is the classic Libertarian argument. The robber barons of the 19th and early 20th century wouldn't have amassed their monopolies had it not been for government regulations that allowed them to do so, blah blah blah.
Unfortunately for the Libertarians, laissez-faire capitalism is unstable. One company will emerge as the leader; and if it behaves rationally it will ruthlessly eliminate its opponents by out-competing them and out-spending them. Government is often an enabler in this process, but even if it wasn't there at all, the end result would still be the same -- monopoly.
Should AT&T have been broken up? No? Then are you interested in paying $30 for a long-distance call? Don't worry, it may still happen if the FCC continues to rule in favor of putting AT&T back together again, and in favor of locking everyone else out of the "last mile" wires.
The answer is not "less" government regulation, but "better" government regulation. Unfortunately, since government is corruptible, it tends to enable monopolists like Microsoft to persist until the abuses become so apparent that even a suitcase full of cash can't keep the politicians in office. Then, finally, they'll act -- but not before.
Verizon beats them in my neck of the woods (495 belt around Boston) a lot of the time, and especially on Cape Cod -- I've seen side-by-side evidence with my friends' phones (multiple Cingular phones had shitty coverage, not just mine). Sprint was also better, although I eventually had to dump them because they were highway-only.
Problem is, there's no way to test Verizon's coverage here without actually committing to buy a phone (unless this Cingular LG phone can be moved over to Verizon's network).
Ah, I see, you're a cell phone coverage expert. And a psychic one to boot, since apparently you can divine from a great distance just how fantastic my one-bar AT&T coverage is. I'm blown away by your Godly powers.
I guess Tolkien failed, then, because I barely was able to force myself through the books. I slept through the movies, which were even more tiresome. I find the whole miserable mess eminently forgettable -- and that was true in 1972 when I read the books for the first time, as well as several years ago, when I read the books again to see what I must have missed (answer: nothing).
As far as internal realism is concerned, the characters are puerile and their motivations silly; and if you can't buy the motivations of the characters, so much for realism.
But I know I'm a minority voice, so go ahead and "troll" me. Couldn't care less; I have karma to burn.
That the quick and dirty app working now usually trumps the super-duper uber app that may get built in 3 or 4 years.
You bet it does, and I've posted before about this bullshit mil spec argument. "It has to work in Alaska." Um, no it doesn't, actually. It needs to work where you deploy it. So don't deploy it to Alaska. Deploy what works in Alaska, to Alaska, and leave the fancy shit home, the enemy won't have it either. Use some common sense.
Speaking of common sense, why don't we equip US soldiers with AK 47's? They're cheap (you can stamp 'em out with incredibly low tech assembly techniques) and they work when they're filthy. No, instead we equip our guys with weapons that jam if you sneeze on them. Meanwhile Ali Baba is using his gun barrel to mix falafel.
I interviewed a guy once for a HW engineer position. We needed a microprocessor board built, Z80, 32K RAM, 32K ROM, couple of serial ports. We'd already built a half dozen similar boards, but the previous hw guy left. So in comes this guy from a big DoD contractor. Turns out he's a member of a 20-person team building a Z80 board. They've been at it for 18 months. He's responsible for the DRAM circuitry. 18 months. Just the DRAM circuitry. 20 people. 18 months. Unbelievable.
We did what his team was doing in 6 weeks with one guy. And I'll bet our board would have worked just fine in their missile or whatever it was they were building. Hell, fire a few and find out, it's cheaper than paying 20 guys to stand around for a year and a half.
True, but he does make a tangential point -- if you want OS/X, you have to buy their hardware, which (like all mainstream vendors) is pretty much going to suck compared to what you could build yourself. Then again, time = money. If you have time to build it, good for you, because when I collapse at the end of a 10 hour day, weekends included, the last thing I want to do is sit down at a bench and accidentally smear conductive heat sink solution all over the pins of some CPU chip with my shaking caffeinated hands because I'm so damn tired and my eyes are crossing. Can't see building another box myself unless I make a zillion bucks and have time on my hands.
Then why do we need specialized OLAP systems like Essbase, Kx Systems, etc.? So much for OSFA (one size fits all). Any transaction-oriented database of sufficient size, requiring multi-way joins between tables, and requiring sub-second response times to queries, is way out of range of OSFA. Furthermore, it doesn't require petabytes to take a relational database system to its knees. Just a few million transactions, and your DBMS will be on its back waving its arms feebly, along with your server.
Performance IS a factor, a very serious factor indeed, for many applications. Not for Betty or for Icepick Johnny, to be sure; but for almost any business with more than about $200M in sales, I guarantee there's a dataset kicking around that will require specialized tools to analyze properly. Since those specialized tools are typically expensive, and typically difficult to use, that dataset will not get analyzed properly, and the business will be "running blind."
Unfortunately I am old enough to weigh in on this. The most productive COBOL programmers back in the day used secretaries who manually transcribed abbreviations and shortcuts into COBOL syntax, using memorized templates. The programmers themselves operated only with the abbreviations. This practice turned out to be a very significant productivity win.
Less typing is not a "stupid meme" at all, at least as it applies to COBOL. However, the arguments by C bigots that they have to type more in Java or whatever are, I'll agree, silly.
Slashdot Mirror
So what you're saying is, it doesn't make a dime's worth of difference, right?
Functional languages are nicely parallelizable because they don't have side effects. Unfortunately, real life is full of side effects. So, a pure functional language has to "hack" the side effect by passing it around everywhere as a closure. That gets old really, really quickly. Which is why useful functional languages contain constructs with side-effects (not without accompanying hand-wringing from purists).
Back in the 70's, people like Jack Dennis used to promise the DARPA that they could parallelize the old Fortran code used to do complex military simulations by converting the Fortran code to a pure functional language. It would be wonderful! Well, they couldn't, and it wasn't.
The above notwithstanding, IF you can coerce a problem into a form in which a functional language can be effectively employed, the benefits can be huge. The code tends to be more elegant and more readable; algorithms that would be difficult to write in an applicative language like C become easy; data structure manipulation is trivial; and so on. Arguments that functional languages are "slow" have been debunked. Arguments that functional languages must be interpreted are wrong.
And, all the syntactic nonsense of C++ and the rest of the "object oriented" languages can be (mercifully) shed. Pure functional languages are object oriented by nature. However, functional languages do have their own idiosyncracies, such as the infamous Lisp "quote", and implementation-dependent funarg problems. So there are cobwebs still.
To sum up: If you have a hard algorithmic problem to solve, a functional language will probably be a better choice, even if you end up re-coding the algorithm in an applicative language later. If you have a device driver to write, though, roll up your sleeves and get out the C manual. But first: make sure to put a debug wrapper around your mallocs (and pad your malloc blocks with patterns on both sides) so you can trap double-frees, underwrites, and overwrites. It will pay many dividends.
Let's not forget Shockley's (and Jensen's) reliance on group IQ tests to "prove" that African Americans are not as bright as other "races" -- a point of view resurrected more recently in "The Bell Curve."
As we now know, it turns out that group IQ tests are completely useless -- almost zero correlation with individually-administered tests. Yet those tired old data continue to be trotted out by academics who should know better.
The damage done by Shockley's IQ assertions was immeasurable. Even if it turns out someday that - say - people with large index fingers are smarter than people with small index fingers, on average - is this a useful result? What should we then do, measure index fingers during job interviews? One can draw no conclusion about an individual from an average. "Research" of this nature simply creates prejudice and encourages discrimination.
...You go down to the local Computer-Rama chain...
Forget Vista, the fact that you were at the Computer-Rama in the first place means that you'll definitely end up wanting to sue somebody for something.
...blistering crotch fires of agony...
Thank you, that's one to file away in the "useful phrases" department. I like it.
Totally agree. Lalalalalalalalalalalala.
...more likely, you are too young to remember the absolute crap that MS churned out...
I remember. I was working on my degree in CS while Gates was dropping out of Harvard, so I know our Microsoft friends quite well.
What I'm told (by people who should know) is that Gates is smart and he's technical. Just because you didn't like DOS (who did?) and you are annoyed at MS and their slow pace of "innovation" (who isn't?) doesn't mean that everyone at MS is stupid, or that Gates is stupid. That's just a stupid inference.
Some good points. However, when you own your own company, you're an integrator by definition -- or you fail. The good news is you're not working for "the man" -- you ARE "the man." And that makes it OK to take a phone call at 10PM from Australia, or get up at oh-dark-hundred for a flight. Most of the time, it's OK. Ah, hell, who am I kidding, it sucks. But at least if you're successful some suit somewhere isn't the beneficiary. You are.
Exactly. You can say what you like about Gates, but dissing him for his IQ, or his technical talent, or his management of what is arguably the most successful business story of all time, is totally off base.
How is someone going to learn assembly?
Well, when I was a wee lad taking 6.251 from Donovan & Madnick at MIT, they threw an IBM Assembler H manual at us and wished us good luck on the first programming task (in two weeks).
So suck it up and RTFM. Although, to be fair, the Assembler H manual is probably one of the finest computer manuals ever written, so it wasn't as bad as it sounds.
I'm not referring to you in particular, just a large portion of the slashbot crowd.
Hey, this is slashdot. Best to refer to him in particular, get with the program.
Brilliant post.
There are too many counterexamples to your premise that monopolies will break up naturally on their own. The ADL scandal, for example, shows that large companies, when left alone by regulators, conspire among themselves to ensure market dominance, mutual survival, and high prices.
IBM's troubles started when they were slapped upside the head by the government's ultimately unsuccessful antitrust lawsuit. You may be too young to remember the bad old days when IBM refused to share specifications on their equipment, refused to interoperate with foreign peripherals, sued everyone who tried, and so on. They were Really Bad Guys. I remember; I lived through it. Now because of SCO and Linux they are suddenly Good Guys; but be careful, because a tiger can't change his stripes.
However, none of the above impacts your point about government cooperating with industry; certainly that's bad, certainly it contributes to lack of market flexibility, and certainly it needs to stop (although it won't). But government does have a responsibility to step in when anticompetitive behavior becomes extreme, as happened with AT&T. I remember my mom "saving up" for long distance calls -- literally. You really had to think hard before dialing "1". You couldn't buy a phone, except through AT&T, and you had to rent it month by month (by the time you had rented it for years, you had bought it 20 times over). And they had to come out and "install" your phone, and God forbid if they found an "illegal" extension phone (they just shut off your service, period). And so on. It was outrageous. The bastards were swimming in ill-gotten gains, and they deserved to be smashed into paste, as they were.
Yes, this is the classic Libertarian argument. The robber barons of the 19th and early 20th century wouldn't have amassed their monopolies had it not been for government regulations that allowed them to do so, blah blah blah.
Unfortunately for the Libertarians, laissez-faire capitalism is unstable. One company will emerge as the leader; and if it behaves rationally it will ruthlessly eliminate its opponents by out-competing them and out-spending them. Government is often an enabler in this process, but even if it wasn't there at all, the end result would still be the same -- monopoly.
Should AT&T have been broken up? No? Then are you interested in paying $30 for a long-distance call? Don't worry, it may still happen if the FCC continues to rule in favor of putting AT&T back together again, and in favor of locking everyone else out of the "last mile" wires.
The answer is not "less" government regulation, but "better" government regulation. Unfortunately, since government is corruptible, it tends to enable monopolists like Microsoft to persist until the abuses become so apparent that even a suitcase full of cash can't keep the politicians in office. Then, finally, they'll act -- but not before.
Verizon beats them in my neck of the woods (495 belt around Boston) a lot of the time, and especially on Cape Cod -- I've seen side-by-side evidence with my friends' phones (multiple Cingular phones had shitty coverage, not just mine). Sprint was also better, although I eventually had to dump them because they were highway-only.
Problem is, there's no way to test Verizon's coverage here without actually committing to buy a phone (unless this Cingular LG phone can be moved over to Verizon's network).
Ah, I see, you're a cell phone coverage expert. And a psychic one to boot, since apparently you can divine from a great distance just how fantastic my one-bar AT&T coverage is. I'm blown away by your Godly powers.
Actually, yelling into the phone seems to help with my shitty Cingular/AT&T coverage. "Sherman, set the Way Back Machine to 1923."
I guess Tolkien failed, then, because I barely was able to force myself through the books. I slept through the movies, which were even more tiresome. I find the whole miserable mess eminently forgettable -- and that was true in 1972 when I read the books for the first time, as well as several years ago, when I read the books again to see what I must have missed (answer: nothing).
As far as internal realism is concerned, the characters are puerile and their motivations silly; and if you can't buy the motivations of the characters, so much for realism.
But I know I'm a minority voice, so go ahead and "troll" me. Couldn't care less; I have karma to burn.
So that's why my calzone had a VHS tape inside. But the laugh's on you, buddy. I finished the calzone AND kept the video.
Damn, I ate my video by mistake.
Yes! You've outlined the basic problem with sociobiology. It's pure guesswork, and typically not very good guesswork at that.
That the quick and dirty app working now usually trumps the super-duper uber app that may get built in 3 or 4 years.
You bet it does, and I've posted before about this bullshit mil spec argument. "It has to work in Alaska." Um, no it doesn't, actually. It needs to work where you deploy it. So don't deploy it to Alaska. Deploy what works in Alaska, to Alaska, and leave the fancy shit home, the enemy won't have it either. Use some common sense.
Speaking of common sense, why don't we equip US soldiers with AK 47's? They're cheap (you can stamp 'em out with incredibly low tech assembly techniques) and they work when they're filthy. No, instead we equip our guys with weapons that jam if you sneeze on them. Meanwhile Ali Baba is using his gun barrel to mix falafel.
I interviewed a guy once for a HW engineer position. We needed a microprocessor board built, Z80, 32K RAM, 32K ROM, couple of serial ports. We'd already built a half dozen similar boards, but the previous hw guy left. So in comes this guy from a big DoD contractor. Turns out he's a member of a 20-person team building a Z80 board. They've been at it for 18 months. He's responsible for the DRAM circuitry. 18 months. Just the DRAM circuitry. 20 people. 18 months. Unbelievable.
We did what his team was doing in 6 weeks with one guy. And I'll bet our board would have worked just fine in their missile or whatever it was they were building. Hell, fire a few and find out, it's cheaper than paying 20 guys to stand around for a year and a half.
True, but he does make a tangential point -- if you want OS/X, you have to buy their hardware, which (like all mainstream vendors) is pretty much going to suck compared to what you could build yourself. Then again, time = money. If you have time to build it, good for you, because when I collapse at the end of a 10 hour day, weekends included, the last thing I want to do is sit down at a bench and accidentally smear conductive heat sink solution all over the pins of some CPU chip with my shaking caffeinated hands because I'm so damn tired and my eyes are crossing. Can't see building another box myself unless I make a zillion bucks and have time on my hands.
You missed his point completely. Check out the "Milgram Experiments" (http://en.wikipedia.org/wiki/Milgram_experiment).
Then why do we need specialized OLAP systems like Essbase, Kx Systems, etc.? So much for OSFA (one size fits all). Any transaction-oriented database of sufficient size, requiring multi-way joins between tables, and requiring sub-second response times to queries, is way out of range of OSFA. Furthermore, it doesn't require petabytes to take a relational database system to its knees. Just a few million transactions, and your DBMS will be on its back waving its arms feebly, along with your server.
Performance IS a factor, a very serious factor indeed, for many applications. Not for Betty or for Icepick Johnny, to be sure; but for almost any business with more than about $200M in sales, I guarantee there's a dataset kicking around that will require specialized tools to analyze properly. Since those specialized tools are typically expensive, and typically difficult to use, that dataset will not get analyzed properly, and the business will be "running blind."
Unfortunately I am old enough to weigh in on this. The most productive COBOL programmers back in the day used secretaries who manually transcribed abbreviations and shortcuts into COBOL syntax, using memorized templates. The programmers themselves operated only with the abbreviations. This practice turned out to be a very significant productivity win.
Less typing is not a "stupid meme" at all, at least as it applies to COBOL. However, the arguments by C bigots that they have to type more in Java or whatever are, I'll agree, silly.