Hacker News Reader

Comment by smhenderson | Hacker News Reader

Reminds me of something Bruce McKinney said about Visual Basic when I was much younger and beginning to learn about computers in general, I'm paraphrasing here but the gist was "Visual Basic makes 95% of your task easy and the other 5% impossible".

Of course Bruce is a hard core programmer so he went on to show you how to do the 5% in VB using some crazy hacks or, better, do it in C/C++ using COM and glue it onto your VB code using the common MS interface of the day (pre .Net that is).

I've forgotten more of it then I remember but I do remember really enjoying reading anything Bruce wrote!

http://www.vb.mvps.org/hardweb/hardbook.htm

View on HN

> "Visual Basic makes 95% of your task easy and the other 5% impossible".

Think what you will of the readability of Perl, but it's hard to beat its motto: "making easy things easy and hard things possible."

VB had access to the entire Win32 API. Nothing was impossible.

Per smhenderson (https://news.ycombinator.com/item?id=22038454), you'll have to take that up with Bruce McKinney, not me; I merely quoted it to compare.

Indeed. When I was finally exposed to Unix (SCO, yuck!) and Linux (Slackware, yay!) it was because I was trying to learn C and wanted free tools because I couldn't afford any commercial stuff at the time. But before I did much with C I became quite proficient with Perl. This really wasn't that long after absorbing all the VB material I could find at the time so it was interesting going from the one to the other, not to mention the OS differences.

I still love using Perl 5 today even though it's totally out of style at this point. VB? Not so much! :-)

> I still love using Perl 5 today even though it's totally out of style at this point.

Same here!

I suspect there's more of us than we think!

:) how is Perl out of style ? ... 20 years ago it had features the more enterpricey languages only got in the last few years

That's often the trade-off of any high-level tool or library. It will make a big chunk of related tasks easier, but won't be able to handle a small subset. Hopefully there are ways to work around the limits.

The limits of tools only expose themselves when they're being stretched in ways the authors did not intend. Good tools have enough escape hatches to get you by those moments, and the bad ones break down entirely.

Such tools should have a degree of "hooks" built in so that work-arounds are easier. For example, a ORM should have an operation to send direct SQL to the database for the times it can't generate SQL as intended. And maybe even modify specific clauses if needed so it's not all native or all raw, but something in between. Of course, if it's too open-ended it becomes a hacker's playground, so a happy medium needs to be found.

Back in the COM days, we were largely a C++ shop. There were times where our business folks did not quite know what they wanted - so we'd prototype the COM component out in VB. It worked a little too well - for about a quarter of the time, you ended up with something that only had a 10% (or less) performance penalty.

I remeber the same argument but it was applied to asp.net webforms, the stateful monster that MS created to usher desktop devs to the web world.. That was a crutch that turned out to be quite bad in the end, lots of new devs that came that route had a problem understanding that the web is a stateless protocol.

Reply on news.ycombinator.com