Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:High-brow fails [Re:It depends on the use] (Score 1) 411

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"

Comment Re:High-brow fails [Re:It depends on the use] (Score 1) 411

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...

Comment Plane Truth [Re:Why??] (Score 1) 181

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.

Comment Re:Why?? (Score 1) 181

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

Comment Re:I Have No Trouble Making Accurate and Precise.. (Score 1) 186

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.

Indeed. Many PHB's have to learn the hard way:

"Who knew healthcare would be so difficult?"

Comment Re:No, but they require planning (Score 3, Insightful) 186

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.

Comment Re:High-brow fails [Re:It depends on the use] (Score 1) 411

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.

Comment Re:Finding Patterns in Crime (Score 1) 60

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.

Slashdot Top Deals

In the realm of scientific observation, luck is granted only to those who are prepared. - Louis Pasteur