REGISTER | LOGIN
Breaking News
Blog

React to the Software Shift

NO RATINGS
View Comments: Newest First | Oldest First | Threaded View
alex_m1
User Rank
Author
Re: Silver bullets (see Brooks[1])
alex_m1   6/23/2017 5:35:47 PM
NO RATINGS
Rick, few interesting software tools/trends i heard about: "application enablement platforms" to develop the server and site/app side of the IOT , the go language for programming fpga's (in the cloud), the low-code development trend for biz apps(may be relevant to EE's), verum dezyne software for complex and reliable embedded sw, spiralgen to create highly optimized numerical code straight from the math, and scala is great tool for relatively easily creating new computer  languages("internal dsl") ,like Chisel, the secret weapon  of rex computing, an old eetimes story and a lot more in the academic literature. 

name99
User Rank
Rookie
Re: Silver bullets (see Brooks[1])
name99   6/23/2017 1:49:13 PM
NO RATINGS
"Tools and techniques take time and effort to learn, and the more features they have, the greater the burden they impose. If you don't know any tools, then there may be no difference between the effort/reward ratio of learning whatever is currently fashionable vs the old way, but the new shiny is unlikely to repay the cost if you already know how to do something."

I hear what you are saying, but, if I might paraphrase in a mean way, what you are saying is, essentially, "Software that's still built the way it was in the 80s remains as flawed as software was in the 80s". This is, unsurprisingly, substantially true...
(Not completely true --- there ARE tools available, like the various LLVM sanitizers, that can impose some small quality control over even ancient-style code, but there are severe limits to what they can do.)

I get frustrated by these dismissals of new SW technology because they create exactly the type of self-fulfilling prophecy I described above. It may be true that there's a lot of hype around new technologies, and it's almost certainly true that some of that hype is nonsense. But that's not the point. The goal is not to dismiss a technology because some idiot lied about it; the goal is to use the best technology available for a particular purpose at any given time.This goal is not served by blanket dismissals. Neither is it served by having people skilled in one domain (eg writing drivers or writing HPC numerical software) assuming that their skills and knowledge automaticaly make them qualified to judge the correct way to engineer code in very different domains like writing UI code for non-keyboard-centric devices. 

In my experience there are two rather diametrically opposed sorts of engineering personalities. There's the person who insists on backward-comatibility forever, and there's the person who insists on dropping the burden of the past for a better architected future. Taken to extremes, both are infeasible, and so a good engineer understands this aspect of personality and tries to override it through intellectual rigor rather than simply letting it run wild. 

 

perl_geek
User Rank
Author
Re: Silver bullets (see Brooks[1])
perl_geek   6/23/2017 12:46:42 PM
NO RATINGS
I'm going to answer two responses at once.

'"Curing the software shortage problem" is a meaningless metric. What would it possibly mean? Software that writes itself?'

Paraphrasing the slogan of the 1968 NATO conference on "software engineering" http://homepages.cs.ncl.ac.uk/brian.randell/NATO/NATOReports/index.html "self-writing software" is not far off what keeps being promised. If you're a snake-oil sales droid, an impressive but meaningless slogan is a perfect element of your presentation.

There is no doubt that there's a bootstrapping effect at work, making it easier to produce software as time passes. As soon as you have a good file system, it's easier to keep source code organised. Then it's possible to keep track of maintenance.

An online editor, even one as evil as "ed", makes it easier to produce ed, vi, and then Vim. Unix made the Internet practical. Lower levels of the software stack get laid down and levelled, so the next level has more powerful units to organise, Exponential declines in hardware costs make it economic to use the tools.

"I'm staying interested in what is HOT and NOT in programming languages, frameworks and techniques."

Where is there something I can hurl, hard?  "Hot or not" is a concept that belongs in gossip columns, dating sites, and similar ephemeral nonsense. There are no free lunches. Promotion or accidental mention by someone influential gets software development thundering off in some random direction, until it becomes obvious that there's a cliff-edge in that direction. The survivors then mill around bleating until someone yells "The promised land's that way", and the process repeats.

Tools and techniques take time and effort to learn, and the more features they have, the greater the burden they impose. If you don't know any tools, then there may be no difference between the effort/reward ratio of learning whatever is currently fashionable vs the old way, but the new shiny is unlikely to repay the cost if you already know how to do something.  

 

rick merritt
User Rank
Author
Re: Silver bullets (see Brooks[1])
rick merritt   6/23/2017 11:35:31 AM
NO RATINGS
Good perspective, thanks.

I'm staying interested in what is HOT and NOT in programming languages, frameworks and techniques. So if you have a story to tell about something that needs to get adopted more widely--or tossed into the waste bin of history--let me hear it.

name99
User Rank
Rookie
Re: Silver bullets (see Brooks[1])
name99   6/22/2017 4:16:28 PM
NO RATINGS
<< "This (product/tool/rain dance ritual) will finally cure the software shortage problem". Has it happened? No. >>

"Curing the software shortage problem" is a meaningless metric. What would it possibly mean? Software that writes itself? 

Let's consider an actually realistic metric: is it easier than ten years ago to write "quality" software? ("Quality" software is another problematic metric, but let's leave vague and assume it means things like reasonably performant, pleasant UI, somewhat capable, mostly bug-free, and so on.) And was it easier ten years ago than ten years before that? And so on?

And I think it's clear to any reasonable observer that the answer to the questions is yes. Modern frameworks and languages (C# or Swift, React or Apple's high level frameworks) make it ever easier to avoid the sorts of routine errors that were common in the past, provide at least some measure of automatic access to the improved hardware of today (some parts of your UI get parallelization and GPU graphics and compute acceleration for free), simplify the tast of network programming and so on. 

There isn't (and hasn't been) ONE single change responsible for all of this. But there has been a constant slow improvement of our SW technology, and to refuse to accept this is to promote an agenda rather than facing the truth. (Just like the people who insist that computers today feel as slow as they did ten years ago generally either 

- are still USING the same software and hardware as ten years ago OR 

- are using modern SW&HW and imagine [incorrectly] that they have an accurate recollection of how fast things were ten years ago.)

 

Our phones run a remarkable range of software, much of it written just by single individuals or small companies, and those apps and the phones themselves almost NEVER crash. In the 80s it was just routine that occasionally your floppy disk would be corrupted by something or other. In the 90's we could expect somewhat reliable persistent storage, but machines (the entire OS) still crashed a few times a week. In the 2000's OS crashes became rare, but app crashes still happened at a problematic rate.


But nowadays (especally on the new platforms that aren't forced to retain legacy bad ideas) our primary complaints are about UI --- bug reports consist of "this app sux because it doesn't do something the iOS or Android way" --- not "app crashes if you press the home button at the same time that it's playing a movie", the sort of thing we used to report about constantly in the past. 

perl_geek
User Rank
Author
Silver bullets (see Brooks[1])
perl_geek   6/22/2017 12:45:46 PM
NO RATINGS
While the right choice of environments and tools can make dramatic (order-of-magnitude) differences in programmer productivity, over the last 50 years, the world has been repeatedly subjected to claims that "This (product/tool/rain dance ritual) will finally cure the software shortage problem". Has it happened? No.

Frameworks (e.g. Ruby on Rails) usually trade speed for flexibility, If you want to do what it allows, in the preferred way, great. If not, don't let the handcuffs chafe. A lot of products pile the Pelion of editor complexity on the Ossa of design incoherence. If you know which cute icon to pick, you can produce the wrong idea faster. (At least that gets it killed sooner.)

Don't misunderstand. If you can identify the essence of your problem class (e.g. report writing or packet switching) and make it easy to change the variable parts, dramatic productivity is possible. Doing that usually takes an intelligently lazy individual immersed in the problem long enough to see the patterns.

[1] Brooks, Fred "The Mythical Man-Month", of course.

Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed