Hacker News new | ask | show | jobs
by monstermonster 4269 days ago
This, a million times. I'm a bit further down the abstraction chain but I am thoroughly glad I sit there all day writing C/C++ for Windows native (win32) GUI applications.

I know once I've tested it on one machine it's going to work fine on all the other ones. It's the most stable API and platform I've ever seen. Code we wrote for Windows NT4 works fine on Windows 8.1 and behaves exactly the same.

Compare that to our poor web guy who spends at least 50% of his time trying to get everything working on a selection of browsers going from IE6 to the latest Chrome while necking red bull, using the F word a lot, smoking and going bright purple.

3 comments

I completely agree with you guys. The tone deafness in this thread with regards to why VB6 appealed to beginners is striking.

No, beginners don't want to layout things in CSS, a declarative XML language, or any other 'text' way. They want to drag and drop components with the sort of ease of use that Visual Studio or Interface Builder offer. And they want a language coupled with that which features the simplicity of Python.

I too did some of my first serious programming in a VB like language in the 90s (RealBasic for Mac). I now develop beginner training materials in web development as a side gig and while we have fun - it's definitely not as satisfying as laying out a form in VB and having a real GUI in a matter of minutes that "Just Works."

Which makes you wonder, could you bolt a language like Python onto an interface builder a la Xcode IB, Visual Studio Forms designer, etc?

I agree with you, I think the bigger picture here is how well the IDE, GUI, and code hang together as a complete unit; focusing on any in isolation (e.g. "VB sucks, use Python") misses the point.

I agree, but if your coworkers is anything like mine and you asked him if there is a fundamental problem with web development as a platform choice for internal apps, I expect he would suddenly forget all the pain he goes through on a regular basis. I've watched my company burn about a million dollars unnecessarily in the last two years because of choosing a 100% web interface for an entirely internal project (of dubious value in the first place).

The zealotry in this field is getting close to unsustainable in my opinion. Companies thought the proliferation of ms access apps was bad, wait until they try to do something with the proliferation of overarchitected web apps based on a wide assortment of fashionable at the time but now unpopular languages and frameworks that hardly anyone has experience on and is most certainly not interested in working on.

The frameworks are the problem. There is no such thing as a "JavaScript guy" really, everything is about the framework, every app is some dev's first in that framework before it drops out of fashion, and knowing framework X doesn't give you any leg up onto framework Y. Experience counts for nothing.

In the old days, you could learn C or SQL and for every hour of learning get a hundred or a thousand hours of real use, and you have at least a fighting chance of picking up some other guys code, or vice versa.

I couldn't agree more. I really don't think very many people in management understand how the programming world has changed and what is happening at a code level in their companies and how big of a maintenance problem they are going to have on their hands.
I used to work at Microsoft (SQL Server). It goes without saying, but getting here is an intentional, conscious thing Microsoft spends billions of dollars to achieve.

Working in SF in earlier-stage companies, I've never seen anything even close to the rigor with which Microsoft approached testing. Definitely consider working there if you want to learn from some of the best QA/QE/verification engineers in the industry.

Sadly many of the recent layoffs from MS have been in their QA and SDET/test engineering teams. The days of a strong testing discipline might be over for the company.
Reminds me of the great talk by Joel Spolsky[1].

Perhaps automated systems have become much better since Joel wrote this, but something from the talk I really liked -

"The old testers at Microsoft checked lots of things: they checked if fonts were consistent and legible, they checked that the location of controls on dialog boxes was reasonable and neatly aligned, they checked whether the screen flickered when you did things, they looked at how the UI flowed, they considered how easy the software was to use, how consistent the wording was, they worried about performance, they checked the spelling and grammar of all the error messages, and they spent a lot of time making sure that the user interface was consistent from one part of the product to another, because a consistent user interface is easier to use than an inconsistent one."

[1] http://www.joelonsoftware.com/items/2007/12/03.html