Everyone is run through those "programs", and only some come out as high achievers and well-paid professionals. If the program were the cause, then everyone would come out the same.
Flawed logic. Take a group, and give them all the benefit of a socialist program, like government financed education. Some will do better than others, which is at least closer to a meritocracy than would otherwise be the case. Eliminate that socialist program, and only the well off will be able to afford a decent education for their children. You now have a system that is based more on your parent's wealth than your merit. Hence people who believe they've done well because of their merit, and believe that's what success should be based on, should be in favor of such a socialist program.
Should we be banning or restricting activities because they aren't "necessary" to a hostile observer?
In the case of the finance industry? Yes. How many times do you have to be screwed before you decide something isn't trustworthy? Regulate, regulate, regulate. That's what gave us the longest period of financial stability in the country's history (post-GD to late 20th/early 21st century). If you can convince somebody without a vested interest that that regulation was a bad idea, then compared to them Charlie Brown looks downright worldly for trusting Lucy not to pull the ball away again.
Didn't they say that about CDO's, CDS's, and all those other TLA's that blew up the world economy? Rule #1 of the finance industry: don't trust it. Please don't give me a "silly prejudice" argument, because that rule is based on history. If the last ten times you dealt with somebody they screwed you over, would you do business with them another time just because you couldn't prove that they'd screw you over again? The longest period of relative financial stability (no big crashes) we had in this country's history is from the end of the Great Depression to the early part of this century. I don't think it's a coincidence that that was also the period when finance was most heavily regulated.
Obviously none of those is essential, but given their enormous markets, it's also obvious that plenty of people desire them. By contrast, how many actual people (not those with a vested interest in arbitrage) were unsatisfied with trades or transactions that took seconds? None. To the extent that social media, smart phones, big houses and cars have become a larger part of our economy, it's because people want them. They are all a part of the productive economy. By contrast, the only thing that the finance industry can do is allocate capital better. Given the not so distant financial crash, do you think they lived up to that promise? Yet in the last few decades, the finance industry (not the capital they move around) has gone from 4% to 8%/GDP, and their profits sometimes count for as much as 40% of corporate profits. In other words, an enormous increase in cost for a product that's inferior to what it used to be. That's called gross inefficiency, though of course the industry that wants to squeeze every last nickel of "inefficiency" out of the productive economy doesn't recognize that.
What does it matter if you specify railroad transport? Transport is transport. What matters to people is how much it costs and how fast it is. Railroads (and steamships) revolutionized the world because they turned trips of weeks into days or hours, and lowered the cost (eventually).
Is that what you're claiming HFT does? Seconds weren't fast enough; it's advantageous to do it in microseconds? I don't think so. That's like saying that, if we had a technology that could take you from NY to Tokyo in 1 minute, it would be an important improvement to reduce that to 1 second. It'd take me longer than that to find the app that translates English to Japanese.
"Functions without side effects"...funny that they don't mention Haskell. Haskell is the *only* pure language (meaning without side effects) out there today with significant adoption.
You can have functions without side effects in other languages. Best if the language allows you to enforce that with a "pure" qualifier, which several do (I actually think the default is backward, and you should have to qualify any function that isn't pure). A language can have mutable local variables, and still have pure functions.
I love Haskell - it's fun to learn and a great way to learn functional programming, because it forces you to do everything functionally. The ADT's should be a must have for any language. Still, I can't see Haskell as a true general purpose real world language. It's great for some things, but there are types of programming (particularly number crunching) where having mutable variables (particularly arrays), is almost indispensable (at least if you want any efficiency). Haskell has tacitly acknowledged this by creating monads that allow you to cheat in that respect. Suddenly you have a purely functional language that isn't purely functional, but pretends to be because the naughty bits are wrapped in monads. The monadic implementation of mutable vars can also be a real pain (I know how to do it, but it isn't worth it).
This isn't really a criticism of Haskell. It was originally designed as a purely functional language w/ non-strict evaluation, for the purpose of research and teaching. It's great for that, but I think the attempts of some enthusiasts to promote it as a general purpose language is going too far. There are more "realistic" alternatives that let you mix functional and non-functional paradigms (e.g. O'Caml, F#, Scala, Scheme, etc.).
You can also transform the HDL to a schematic for the times you *want* to see a schematic.
Usually that's done only for small blocks to see what the synthesizer hath wrought, and whether you can tweak the HDL for more optimal synthesis. Reading the resultant automatically generated schematics is an exercise in deciphering a puzzle. Usually easier than reading the equivalent structural HDL, but not by much.
Flow-Based Programming has *both* a visual and textual representation.
As does the example I mentioned (schematic is only required at the top level). For anything non-trivial, it isn't worth it. If flow based programming is easier, it's probably only for a small class of applications.
AFAIK PLC's run pretty simple programs, or at least very special purpose. I don't mean that pejoratively, just that your concerns when setting up PLC's are rather different than traditional software. I'd think they'd have to be to be describable using ladder logic (they were using it as recently as 10 years ago? Wow. Wasn't it designed for relays?)
Bottom line: would that approach extend well to other types of programming? I'm skeptical.
I'm a hardware/software engineer (i.e. I do both). By analogy to logic design (ASIC's, FPGA's), this is a big step backwards. Once upon a time logic was designed using schematics. Everybody gave that up about 20 years ago, and switched to HDL's (VHDL, Verilog). For those unfamiliar with them, HDL's are text based hardware description languages which get compiled and then synthesized into gates, flip-flops, etc.
Despite this change 20 years ago, there are those who cling to a love of schematics. You can draw a schematic and have it automatically transformed into HDL, and from then on it follows the same design flow. It's a mistake to do things that way. As recently as 5 years ago (and perhaps still) I had a customer who insisted that the top level of the design be a schematic (with the boxes in the top-level schematic implemented however you wanted). It sounds nice, with a pictorial representation (which is especially well suited to hardware), but it turns into a mess for any non-trivial project. Top level diagrams are a great form of documentation, but when you try to use it for actual implementation, it gets so cluttered with detail that it becomes unreadable. Better to look at the text. I can't see how this would be any different for a non-trivial program.
I agree that Fortran is still the champ for fast number crunching, but I was specifically refuting your point that C++ necessarily carried the overhead of OO.
Slashdot Mirror
some sarcasm is indeed satire
Your logic is flawed. Satire may employ sarcasm, but that is not the same as saying that sarcasm is satire.
Give it a rest. It's Friday night, I'm working late and I'm tired. Any excuse to argue is a pleasant diversion, but now back to work ...
News anchors and columnists still think anyone that isn't in the Democratic Party is a bible thumping, gun clinging, racist hillbilly.
Does that apply to Fox news?
Then money taken by threat of force could legitimately be used for what? If you say nothing, you're an anarchist.
The Soviets had a similar problem - except the lefties were in control and imprisoned or murdered the "deniers".
I won't mince words. Anyone who conflates what's widely considered a "leftie" in America with Stalinists, is a clown.
Learn to use the English lexicon correctly - sarcasm is not satire.
Everyone is run through those "programs", and only some come out as high achievers and well-paid professionals. If the program were the cause, then everyone would come out the same.
Flawed logic. Take a group, and give them all the benefit of a socialist program, like government financed education. Some will do better than others, which is at least closer to a meritocracy than would otherwise be the case. Eliminate that socialist program, and only the well off will be able to afford a decent education for their children. You now have a system that is based more on your parent's wealth than your merit. Hence people who believe they've done well because of their merit, and believe that's what success should be based on, should be in favor of such a socialist program.
Actually his strong point was math - his bombs weren't all that impressive.
Obama ... (praise be his name)
And you complain about stereotypes and bias against the Tea Party?
What other variables were controlled for or tested?
What type of transistor?
Should we be banning or restricting activities because they aren't "necessary" to a hostile observer?
In the case of the finance industry? Yes. How many times do you have to be screwed before you decide something isn't trustworthy? Regulate, regulate, regulate. That's what gave us the longest period of financial stability in the country's history (post-GD to late 20th/early 21st century). If you can convince somebody without a vested interest that that regulation was a bad idea, then compared to them Charlie Brown looks downright worldly for trusting Lucy not to pull the ball away again.
By frowns you mean they start criminal proceedings.
What century are you living in?
Good luck finding a clause in the constitution that gives the government the power to regulate this.
Interstate and foreign commerce.
Because there's no reason to make it illegal.
Didn't they say that about CDO's, CDS's, and all those other TLA's that blew up the world economy? Rule #1 of the finance industry: don't trust it. Please don't give me a "silly prejudice" argument, because that rule is based on history. If the last ten times you dealt with somebody they screwed you over, would you do business with them another time just because you couldn't prove that they'd screw you over again? The longest period of relative financial stability (no big crashes) we had in this country's history is from the end of the Great Depression to the early part of this century. I don't think it's a coincidence that that was also the period when finance was most heavily regulated.
What ISN'T a self serving leech on our economy?
Facebook, iPhones, McMansions and cars.
Obviously none of those is essential, but given their enormous markets, it's also obvious that plenty of people desire them. By contrast, how many actual people (not those with a vested interest in arbitrage) were unsatisfied with trades or transactions that took seconds? None. To the extent that social media, smart phones, big houses and cars have become a larger part of our economy, it's because people want them. They are all a part of the productive economy. By contrast, the only thing that the finance industry can do is allocate capital better. Given the not so distant financial crash, do you think they lived up to that promise? Yet in the last few decades, the finance industry (not the capital they move around) has gone from 4% to 8%/GDP, and their profits sometimes count for as much as 40% of corporate profits. In other words, an enormous increase in cost for a product that's inferior to what it used to be. That's called gross inefficiency, though of course the industry that wants to squeeze every last nickel of "inefficiency" out of the productive economy doesn't recognize that.
I meant to say the rail transportation industry.
What does it matter if you specify railroad transport? Transport is transport. What matters to people is how much it costs and how fast it is. Railroads (and steamships) revolutionized the world because they turned trips of weeks into days or hours, and lowered the cost (eventually).
Is that what you're claiming HFT does? Seconds weren't fast enough; it's advantageous to do it in microseconds? I don't think so. That's like saying that, if we had a technology that could take you from NY to Tokyo in 1 minute, it would be an important improvement to reduce that to 1 second. It'd take me longer than that to find the app that translates English to Japanese.
A common argument was that they did not do anything – that they just shipped the work of other people.
Cite? I've heard the railroads of yore criticized for many things, but never that.
"Functions without side effects"...funny that they don't mention Haskell. Haskell is the *only* pure language (meaning without side effects) out there today with significant adoption.
You can have functions without side effects in other languages. Best if the language allows you to enforce that with a "pure" qualifier, which several do (I actually think the default is backward, and you should have to qualify any function that isn't pure). A language can have mutable local variables, and still have pure functions.
I love Haskell - it's fun to learn and a great way to learn functional programming, because it forces you to do everything functionally. The ADT's should be a must have for any language. Still, I can't see Haskell as a true general purpose real world language. It's great for some things, but there are types of programming (particularly number crunching) where having mutable variables (particularly arrays), is almost indispensable (at least if you want any efficiency). Haskell has tacitly acknowledged this by creating monads that allow you to cheat in that respect. Suddenly you have a purely functional language that isn't purely functional, but pretends to be because the naughty bits are wrapped in monads. The monadic implementation of mutable vars can also be a real pain (I know how to do it, but it isn't worth it).
This isn't really a criticism of Haskell. It was originally designed as a purely functional language w/ non-strict evaluation, for the purpose of research and teaching. It's great for that, but I think the attempts of some enthusiasts to promote it as a general purpose language is going too far. There are more "realistic" alternatives that let you mix functional and non-functional paradigms (e.g. O'Caml, F#, Scala, Scheme, etc.).
You can also transform the HDL to a schematic for the times you *want* to see a schematic.
Usually that's done only for small blocks to see what the synthesizer hath wrought, and whether you can tweak the HDL for more optimal synthesis. Reading the resultant automatically generated schematics is an exercise in deciphering a puzzle. Usually easier than reading the equivalent structural HDL, but not by much.
Flow-Based Programming has *both* a visual and textual representation.
As does the example I mentioned (schematic is only required at the top level). For anything non-trivial, it isn't worth it. If flow based programming is easier, it's probably only for a small class of applications.
AFAIK PLC's run pretty simple programs, or at least very special purpose. I don't mean that pejoratively, just that your concerns when setting up PLC's are rather different than traditional software. I'd think they'd have to be to be describable using ladder logic (they were using it as recently as 10 years ago? Wow. Wasn't it designed for relays?)
Bottom line: would that approach extend well to other types of programming? I'm skeptical.
I'm a hardware/software engineer (i.e. I do both). By analogy to logic design (ASIC's, FPGA's), this is a big step backwards. Once upon a time logic was designed using schematics. Everybody gave that up about 20 years ago, and switched to HDL's (VHDL, Verilog). For those unfamiliar with them, HDL's are text based hardware description languages which get compiled and then synthesized into gates, flip-flops, etc.
Despite this change 20 years ago, there are those who cling to a love of schematics. You can draw a schematic and have it automatically transformed into HDL, and from then on it follows the same design flow. It's a mistake to do things that way. As recently as 5 years ago (and perhaps still) I had a customer who insisted that the top level of the design be a schematic (with the boxes in the top-level schematic implemented however you wanted). It sounds nice, with a pictorial representation (which is especially well suited to hardware), but it turns into a mess for any non-trivial project. Top level diagrams are a great form of documentation, but when you try to use it for actual implementation, it gets so cluttered with detail that it becomes unreadable. Better to look at the text. I can't see how this would be any different for a non-trivial program.
I agree that Fortran is still the champ for fast number crunching, but I was specifically refuting your point that C++ necessarily carried the overhead of OO.
for a scientific computing problem C++ has all that OO overhead
Only if you choose to use the OO part of it. C++ is very flexible in that regard. Looking for speed? Templates can be very helpful.
It means some people finally figured out Ohm's Law. If they get the hang of complex numbers, capacitor and inductor sales will go up too.