If you work on Chevies when everyone else is working on Fords, then you may have difficulty finding mechanics for your customized Chevies. I've yet to see evidence FP is objectively "better" in enough circumstances and niches to justify narrowing staffing options except for certain specialties. (I've complained about lack of practical demonstrations elsewhere on this story.)
The "actor model" seems pretty close to event driven programming. I don't know the official or exact difference. But my key point is that the event handling programming and interface is procedural. The only non-procedural aspect may be that requests for further actions may need a priority value (rank) and to be submitted to a request queue. For example, a game character may request a "shoot arrow" event on their part as a follow-up. But the event handler writer doesn't have to concern themselves with the direct management of the event-request-queue.
"Any more than...query writers...don't have to know..." should be "Any more than...query writers...have to know...". Remove "don't"
is more important now because of the trend towards more and more cores
But the bottleneck is not CPU itself for a good many applications. And specialized languages or sub-languages can handle much of the parallelism. If I ask a database to do a sort, it may use parallelism under the hood, but I don't have to micromanage that in most cases: I don't care if the sort algorithm uses FP or gerbils on treadmills. Similar with 3D rendering: the designer submits a 3D model with polygons and texture maps, and a rendering engine micromanages the parallelism under the hood. That "root engine" may indeed use FP, but the model maker doesn't have to know or care.
And event-driven programming can hide that fact that parallelism is going on, or at least provide a non-FP interface. For example, in a game, a character may be programmed by how they respond to various events. There may be 10 events going on at once, but the app dev is only focusing on one at a time per character or character type. Granted, it may take better languages or API's to abstract parallelism well. The "root engines" may make heavy use of FP, such as the database, rendering, and event handling engines, but the 2nd level, typically called "application developers", probably won't need that any more than SQL query writers (usually) don't have to know how the database engine was written. But only time will tell...
who invented flight thing over again, they will just keep on redefining what flight is until they are first.
Not comparable to this situation per sister message, but as far as the first manned plane flight, the definition matters because it was relatively trivial to attach a motor to a propeller and then to a thing with wings and lunge sky-ward for a short period of time. After all, gliders, as in hang-gliders, were already common by then.
One could argue it was really an evolution, but the Wright Brothers were way ahead of the others in terms of control for several years regardless of who made the first lunge into the air. They were doing figure-8's when others could barely turn.
They finally lost that distinction when others moved and perfected the "tail" on the back instead of the front, which made planes safer.
Why are Americans so desperate to prove that everything happened there first...[such as] who invented flight...
What is "first" in this bone case in terms of competitor nations? I don't see any relationship between that and planes. If the claim were that Americans reached America before Europeans did, then it may be comparable, but then its meaningless. I-dont-geddit
Another problem is the new date is almost an order of magnitude older than all prior evidence. One isolated sample set is not sufficient evidence to revise the estimate that much. We'd need more samples from the likes of say 40k and 90k to give more credence to the 130k date.
I've done many project plans for clients, and when I give them the results, they always bitch. But, when the project is actually delivered, they finally agree that I was right in the first place. After that, it gets easier...[with] THOSE clients.
The product was finished as described in the requirement documents, but generally didn't work 100% like the customer expected.
Yip, generally it's easy to make an estimate for a clear specification. But, customers rarely know what they REALLY want until they see something in production. This is a very common problem. I don't know any easy solution to that: mind-reading machines don't exist.
One partial solution is for the technical analyst to become a domain expert first. But obviously this is often not practical. Further, sometimes the main customer/manager wants something rather odd that is a quirk of their personality. You may build something that fits the domain, but they want to see their domain in peculiar quirky way.
Another partial solution is "RAD": Rapid application development tools. Someone who knows the tool well can usually spit out something pretty quick and change it fairly quick.
However, RAD tools are not known to be very flexible in the longer run, such as when UI styles and expectations change. They achieve RAD in part by marrying business logic to the UI. This marriage makes less "marshaling" code between the database, biz logic, and the UI; BUT also hard-wires it to UI assumptions. Keeping up with the UI Kardashians can be a major PITA. Just when GUI's were maturing, web came along. Just when web was maturing, multi-device-handling needs came along. The current "in" thing is going to be klunky because it's not mature yet.
For now, it looks like we are stuck with some degree of organic meandering to get something the customer is actually happy with; but organic meandering takes more time and money and is hard to estimate up front.
That's true. But it's hard to know what will be "mainstream" in a decade or so. I'm not convinced FP will "trickle down" to mainstream (4-yr-degree staff), at least as a primary technique. It's been around for roughly 60 years (at least as Lisp). If it doesn't go mainstream within 60 years, it probably won't by 70 either.
Thus, it may not match or be part of the evolution pattern you outlined.
Even when GUI's first came out, I couldn't predict they'd go mainstream. While I thought it was "cool", I thought it may stay limited to graphical applications because for non-graphical applications they don't make one more productive than a well-designed command and/or character-based interface. (And still don't.) What I didn't count on was that most found they are easier to learn (pick up). I didn't know that issue would override others in users/manangers' minds.
There's specific things they did poorly, like Solyndra, but overall the Recovery Act investments in solar etc. played a notable part in making solar competitive by creating solar demand and funding R&D.
there aren't obvious patterns in criminal activity. Sometimes they use code words, but the code words are different for every criminal.
I heavily used code-words at one place simply because the office politics were so intense that little things created drama storms.
Bob: "How's the hopper rider and the green peas?"
Me: "Oh, the Flanagan popped a rabbit, which agitated the mountaineer again."
Bob: "Yeah, their fiddle-sticks pack a punch. Good thing the Flux Whopper can plug the hole, otherwise Mr. Owl's tree branch would hang the cheese and us with it."
Me: "I know what you mean. Hammerheadding almost always beats painted planetariums."
Bob: "At least Spiderman didn't frisk the Joker's tentacle."
Me: "Indeed, I hate it when that happens. Take care, see ya tomorrow."
Bob: "Sure, don't let the plaid horse-bugs bite."
People thought we were on LSD, but at least we avoided trouble.
By "merely", I meant C (and HLL's) didn't originate the idea.
I'm not sure what you mean by "less good". You seemed to agree there's a trade-off between optimizing for "machine" resources/time, and abstraction/discipline/consistency/clarity. "Good" would then be relative to needs, such as business requirements/goals.
Literally any first world news source outside of the US is going to appear "left wing biased"
Most of the developed world is progressive compared to the USA. The USA right-wing is an isolated curiosity to most of the world. The only comparable nation I can think of would be Australia, because it still has open areas comparable to our mid-west, and thus an independent streak, as in, "We ain't need no pesky national government nosin' around in our business. We do better on our own."
Because the idea that there are alternate facts and all viewpoints are equally valid needs to die.
If a claim starts gathering eyeballs, you have to address it head on. It's going to happen whether it "should" or not.
That's where a quick-acting debunking service would help. Debunking sites exist, but are usually late to the party. If a given fake article or fake meme pops up, then a debunking service can pop into action to check it out. Stick some ads on the side of the site to pay for it.
Like if you see a claim that "Obama eats puppies" floating around, you could check the site and see what the quick-fact-checkers have on it when it's fresh. In some cases it may be a work-in-progress, such as "we have not been able to confirm the rumor but are still sifting. Stay tuned." After a while, they post a thorough debunking of it.... Oh wait, he did eat puppies when he lived in Asia growing up.
Crappy interface for finding what you want packaged together nicely and compactly. I don't see any serious attempt to group by a given event. Maybe I missed a magic button somewhere?
Tornadoes, hurricanes, earthquakes, tsunamis, floods, 10 ft. snow, volcanoes, etc., I wonder what places have the least risk? It seems every place can be bleeped by Acts of God in roughly the same proportion.
Slashdot Mirror
If you work on Chevies when everyone else is working on Fords, then you may have difficulty finding mechanics for your customized Chevies. I've yet to see evidence FP is objectively "better" in enough circumstances and niches to justify narrowing staffing options except for certain specialties. (I've complained about lack of practical demonstrations elsewhere on this story.)
Example near the ranges I mentioned?
Addendum and corrections:
The "actor model" seems pretty close to event driven programming. I don't know the official or exact difference. But my key point is that the event handling programming and interface is procedural. The only non-procedural aspect may be that requests for further actions may need a priority value (rank) and to be submitted to a request queue. For example, a game character may request a "shoot arrow" event on their part as a follow-up. But the event handler writer doesn't have to concern themselves with the direct management of the event-request-queue.
"Any more than...query writers...don't have to know..." should be "Any more than...query writers...have to know...". Remove "don't"
But the bottleneck is not CPU itself for a good many applications. And specialized languages or sub-languages can handle much of the parallelism. If I ask a database to do a sort, it may use parallelism under the hood, but I don't have to micromanage that in most cases: I don't care if the sort algorithm uses FP or gerbils on treadmills. Similar with 3D rendering: the designer submits a 3D model with polygons and texture maps, and a rendering engine micromanages the parallelism under the hood. That "root engine" may indeed use FP, but the model maker doesn't have to know or care.
And event-driven programming can hide that fact that parallelism is going on, or at least provide a non-FP interface. For example, in a game, a character may be programmed by how they respond to various events. There may be 10 events going on at once, but the app dev is only focusing on one at a time per character or character type. Granted, it may take better languages or API's to abstract parallelism well. The "root engines" may make heavy use of FP, such as the database, rendering, and event handling engines, but the 2nd level, typically called "application developers", probably won't need that any more than SQL query writers (usually) don't have to know how the database engine was written. But only time will tell...
That's true of pretty much anything. Typically we want multiple projects going on at the same time.
Not comparable to this situation per sister message, but as far as the first manned plane flight, the definition matters because it was relatively trivial to attach a motor to a propeller and then to a thing with wings and lunge sky-ward for a short period of time. After all, gliders, as in hang-gliders, were already common by then.
One could argue it was really an evolution, but the Wright Brothers were way ahead of the others in terms of control for several years regardless of who made the first lunge into the air. They were doing figure-8's when others could barely turn.
They finally lost that distinction when others moved and perfected the "tail" on the back instead of the front, which made planes safer.
What is "first" in this bone case in terms of competitor nations? I don't see any relationship between that and planes. If the claim were that Americans reached America before Europeans did, then it may be comparable, but then its meaningless. I-dont-geddit
Another problem is the new date is almost an order of magnitude older than all prior evidence. One isolated sample set is not sufficient evidence to revise the estimate that much. We'd need more samples from the likes of say 40k and 90k to give more credence to the 130k date.
Indeed. Many PHB's have to learn the hard way:
"Who knew healthcare would be so difficult?"
Yip, generally it's easy to make an estimate for a clear specification. But, customers rarely know what they REALLY want until they see something in production. This is a very common problem. I don't know any easy solution to that: mind-reading machines don't exist.
One partial solution is for the technical analyst to become a domain expert first. But obviously this is often not practical. Further, sometimes the main customer/manager wants something rather odd that is a quirk of their personality. You may build something that fits the domain, but they want to see their domain in peculiar quirky way.
Another partial solution is "RAD": Rapid application development tools. Someone who knows the tool well can usually spit out something pretty quick and change it fairly quick.
However, RAD tools are not known to be very flexible in the longer run, such as when UI styles and expectations change. They achieve RAD in part by marrying business logic to the UI. This marriage makes less "marshaling" code between the database, biz logic, and the UI; BUT also hard-wires it to UI assumptions. Keeping up with the UI Kardashians can be a major PITA. Just when GUI's were maturing, web came along. Just when web was maturing, multi-device-handling needs came along. The current "in" thing is going to be klunky because it's not mature yet.
For now, it looks like we are stuck with some degree of organic meandering to get something the customer is actually happy with; but organic meandering takes more time and money and is hard to estimate up front.
That's true. But it's hard to know what will be "mainstream" in a decade or so. I'm not convinced FP will "trickle down" to mainstream (4-yr-degree staff), at least as a primary technique. It's been around for roughly 60 years (at least as Lisp). If it doesn't go mainstream within 60 years, it probably won't by 70 either.
Thus, it may not match or be part of the evolution pattern you outlined.
Even when GUI's first came out, I couldn't predict they'd go mainstream. While I thought it was "cool", I thought it may stay limited to graphical applications because for non-graphical applications they don't make one more productive than a well-designed command and/or character-based interface. (And still don't.) What I didn't count on was that most found they are easier to learn (pick up). I didn't know that issue would override others in users/manangers' minds.
Just have somebody pummel your face so it swells all funny. I'll volunteer to assist. You might even look better after.
I'm going, but since I'm not a fan, I won't be scanned.
-1 Literal Pandemic
There's specific things they did poorly, like Solyndra, but overall the Recovery Act investments in solar etc. played a notable part in making solar competitive by creating solar demand and funding R&D.
"Dammit, Jim, I'm a...
I heavily used code-words at one place simply because the office politics were so intense that little things created drama storms.
Bob: "How's the hopper rider and the green peas?"
Me: "Oh, the Flanagan popped a rabbit, which agitated the mountaineer again."
Bob: "Yeah, their fiddle-sticks pack a punch. Good thing the Flux Whopper can plug the hole, otherwise Mr. Owl's tree branch would hang the cheese and us with it."
Me: "I know what you mean. Hammerheadding almost always beats painted planetariums."
Bob: "At least Spiderman didn't frisk the Joker's tentacle."
Me: "Indeed, I hate it when that happens. Take care, see ya tomorrow."
Bob: "Sure, don't let the plaid horse-bugs bite."
People thought we were on LSD, but at least we avoided trouble.
Is the DSL at least reliable? If so, I'll take it!
DSL versus fiber versus gerbils carrying pebbles with 1's and 0's on them make diddly squat difference if it's not reliable.
Damn oligopolies make one have to choose between Dumb and Dumber.
http://phenomena.nationalgeogr...
Okay, the number is a bit off.
And you can have all my base while you are at it.
By "merely", I meant C (and HLL's) didn't originate the idea.
I'm not sure what you mean by "less good". You seemed to agree there's a trade-off between optimizing for "machine" resources/time, and abstraction/discipline/consistency/clarity. "Good" would then be relative to needs, such as business requirements/goals.
Fake News! It was Photoshopped in a Kenyan Sharia lab!
Most of the developed world is progressive compared to the USA. The USA right-wing is an isolated curiosity to most of the world. The only comparable nation I can think of would be Australia, because it still has open areas comparable to our mid-west, and thus an independent streak, as in, "We ain't need no pesky national government nosin' around in our business. We do better on our own."
If a claim starts gathering eyeballs, you have to address it head on. It's going to happen whether it "should" or not.
That's where a quick-acting debunking service would help. Debunking sites exist, but are usually late to the party. If a given fake article or fake meme pops up, then a debunking service can pop into action to check it out. Stick some ads on the side of the site to pay for it.
Like if you see a claim that "Obama eats puppies" floating around, you could check the site and see what the quick-fact-checkers have on it when it's fresh. In some cases it may be a work-in-progress, such as "we have not been able to confirm the rumor but are still sifting. Stay tuned." After a while, they post a thorough debunking of it. ... Oh wait, he did eat puppies when he lived in Asia growing up.
Crappy interface for finding what you want packaged together nicely and compactly. I don't see any serious attempt to group by a given event. Maybe I missed a magic button somewhere?
Tornadoes, hurricanes, earthquakes, tsunamis, floods, 10 ft. snow, volcanoes, etc., I wonder what places have the least risk? It seems every place can be bleeped by Acts of God in roughly the same proportion.