Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
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:FP becomes more popular than OOP? (Score 1) 415

The industry learned the hard way that OOP works well for some things but not others. For example, OOP has mostly failed in domain modeling (modeling real-world "nouns") but is pretty good at packaging API's for computing and networking services.

The industry may also learn the hard way where FP does well and where it chokes. Some understandably don't want to be the guinea pigs.

Comment Re:Functional Programming Considered Harmful (Score 1) 415

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

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

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) 415

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) 223

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.

Submission + - LinkedIn Testing 1970's-Style No-CS-Degree-Required Software Apprenticeships

theodp writes: The Mercury News reports on REACH, a new software apprenticeship program that LinkedIn’s engineering team started piloting this month, which offers people without Computer Science degrees an opportunity to get a foot in the door, as Microsoft-owned LinkedIn searches for ways to help diversify its workforce. For now, the 29 REACH participants are paid, but are only short-term LinkedIn employees (for the duration of the 6-month program). LinkedIn indicated it hopes to learn if tech internships could eventually be made part of the regular hiring process, perhaps unaware that no-CS-degree-required hiring for entry-level permanent positions in software development was standard practice in the 70's and 80's, back when women made up almost 40% of those working as programmers and in software-related fields, nearly double the percentage of women in LinkedIn's global 2016 tech workforce. Hey, even in tech hiring, everything old is new again!

Comment Re:Why?? (Score 1) 223

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) 214

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) 214

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) 415

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.

Slashdot Top Deals

In order to dial out, it is necessary to broaden one's dimension.

Working...