Meet The Startup That's Going To Make Programming A Thing Of The Past | Hacker News Reader

Meet The Startup That's Going To Make Programming A Thing Of The Past

sfgate.com

4 pointsseminatore5 comments

Hasn't "making programming a thing of the past" been the Holy Grail of business managers since the 1970s? And yet, there are now more of us programmers than ever before.

Anyone who's old enough will remember several waves of "eliminate the programmer". What was the first technology aimed to do that? COBOL?

Anyone have a good guess?

In any case, yawn to the eliminate the programmer stuff. Been there, done that, history repeating itself for the n+1 time.

here's what's always happened and what will happen again: the framework being presented as a programmer antidote will come up short to business requirements. then there will be a scripting layer built on top (if not already). And boom, you will need a programmer to implement these scripts for customizations. So in reality you are just adding an abstraction layer to the mix. Those layers are why we don't program in assembly anymore, they are why we don't manage our own memory anymore (yeah lots of unmanaged tech out there, etc). That's also why we don't compile stuff anymore (see previous disclaimer). Etc. Just more of the same stuff, one more abstraction layer.

I really wish them all the best, since I have seen the 4GL movement sputter and grind to a halt and only remaining in enterprise software dedicated to BPM, ERP, etc...

And as greenyoda pointed out, the last time this was done, it was driven by business managers who thought they get get rid of the last link and make it accessible to every employee.

All they did was to make things more complicated and get ensnared into the trap laid by SAP, Oracle, et, al.

Of course, no one got fired for purchasing from big name vendors.

So there is a visual programming language called LabView:

http://www.ni.com/labview/

As a person who really programs, what enevitably happened is systems grew to a complexity (as all systems do that do real work) where real debugging became an issue. So these labview programs made by people who don't program would need debugging...and programmers couldn't really apply 90% of their debugging toolkit to fix the programs, and the non-programmers couldn't fix the programs either.

LabWindows ( a C extention to LabView) was a solution that SOMETIMES allowed programmers to make components that would tie in and work in a fine grained manner for the non-programmers to use in LabView, but in the end, the system usually broke down repeatedly.

Having programmers make the LV programs wasn't any better, it was very slow, and still suffered from inability to easily spot and fix mis-specification errors, or to gently refine processes.

The strangest part about the whole thing is that very small python scripts EASILY replaced all of the LabWindows programs whenever we did that. So we just taught a couple of the engineers a bit of python, had some interns convert the rest, or really moved away from LV as a platform.

"Grump developer reading hacker news sorely wants to make bullshit article headlines a thing of the past."

Reply on news.ycombinator.com