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

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

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

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.

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.

All you've said is 100% true, but in addition I'd argue that a big part of reason why no-code tools don't get more traction is also just the simple power of habit and the lack of motivation to invest time into learning it. We already know how to build things the traditional way, and all these no-code solutions require learning a lot of new, proprietary interfaces and stuff, playing with it and figuring it out, learning to work around the limitations. Many other tools and frameworks that we choose to use have similar, probably even worse problems, but they're popular so one feels like it's worth the trouble to learn them - just to stay in the game. No code tools on the other hand are proprietary, not very popular and the benefits they give you are just not that significant to a seasoned programmer. In all honesty, I never even gave them a chance.

I don’t have enough experience with no-code tools either, but I don’t agree it’s motivation that prevents it from taking off.

No-code is used mostly by non-technical founders who do seem quite motivated (enough to do it themselves).

Engineers are more likely to build it themselves (realistically, over-engineer).

Those "non-technical founders" are usually the ones that have "ideas" to build another Facebook and don't want to pay a professional to do it.

The trouble with this analogy is that at some point an ATV comes along that’s much faster both on and off the road, but you’re still clinging to x86 because it’s more powerful than the “high level” languages like C.

I generally agree with you, but I also suspect there’s a lot of room to improve the tools and it’s not always obvious when something is a paradigm shift in productivity or a dead end that will only work in tightly constrained use cases.

This is the perfect metaphor and the one I use.

Just because we can build a Ferrari doesn't mean that a Ferrari is efficient in all situations.

We have race tracks (smooth, evenly surfaced roads), highways (generally smooth roads over long distances), city streets (some potholes), gravel roads, dirt roads, and no-roads.

A tank isn't great for a race track. And a Ferrari isn't great for no-road.

The author muddles up the question to make their point.

What they're really saying is "no-code tools aren't a good fit for general purpose coding" (for all the reasons mentioned).

Which seems fair and accurate. But all coding is not general purpose coding.

Reminds me of a similar situation with my technical manager. He’s very dogmatic in that we should never waste time “re-inventing the wheel” (e.g. there’s already a library/tool out there that does X, don’t waste time remaking it). This makes a lot of sense in many business cases, but not always...

I like using this analogy to demonstrate why:

Say we’re designing a race car, and our race car needs wheels.

“Wait!” says my manager, “don’t waste time designing wheels for our car when we can simply buy these wheels from a vendor and slap it on our car!”

I look at the wheels. “Uh, sure those are wheels, but they’re wheels designed for a shopping cart! I mean sure we could slap these on our racecar but it’s then going to drive like crap!”

If you want a great product, sometimes you’re better off re-inventing the wheel… (and not using a “No Code” solution…)

The problem is sometimes you get the converse where developers have the "not invented here" mentality. I interviewed at a shop one time where they had built their own JS framework. Mind you this was a financial shop not a tech shop. They bellied up about 2 years after I interviewed with them and I cannot help but reason that they had "tech gone wild" as one of the reasons. The CEO fashioned his company as the Google of the financial industry but in the end they where a bunch of developers stroking their ego.

It is a balancing act, a lot of times building on what exists is the best case but when it comes to your core competency and what distinguishes your business, that is where one should focus their development efforts. If you are rewriting Postgres you will just end up with a shittier database.

Totally agree it's a balancing act. Sometimes the existing tool is exactly what you need, in which it would be a waste to re-invent it. Ideally though, things should be evaluated case by case, rather than sticking to a dogma.

I just happen to work at a company that's experienced the flip side of your experience. We ended up wasting millions on software some managers thought fit our needs. However, turns out it really didn't fit our needs after all was said and done, and they said if they had known everything up front (rather than what the salesman had said) they wouldn't have bought the software in the first place.

Most importantly, by the time you need to go off road, it's too late to switch bikes...

We used to make this sort of analogy a lot at a web dev place where I once worked. Eventually it got boiled down to a pithy joke: "Ruby on Rails is great, but only if you stay on the Rails!"

I think this drives your point with incredible wit: “On The Turing Completeness of PowerPoint (SIGBOVIK)” by Tom Wildenhain[1]. (5 minutes video)

[1]: https://youtu.be/uNjxe8ShM-8 (Nerding out should always be hilarious like that!)

[2]: Recording of a guest lecture he gave for the Esoteric Programming Languages course at CMU. (~1h) https://youtu.be/_3loq22TxSc

What you need is a speed bike that lets you switch to a mountain bike when you decide you need/want to go off the trail. That is, a "no code" or graphical or whatever whizz-bang tool that lets you drop into C++ or Python or Lisp or whatever when you need to.

And to do this, it needs to be better than JNI in Java. It needs to be able to have something better than a gouge-your-eyeballs-out-ugly syntax for interfacing to the "real" programming language.

I’ve found that most no code environments that I’ve tried advocate that they have this capability but in practice it’s still nearly impossible to get what I need because their abstractions aren’t at the right level. Not saying this is impossible just that my personal experiences have made me skeptical of this approach.

I mean, that's pretty much how I program things. I start new web apps with an MVC framework that auto-generates new pages. When I want to do something, I try to use someone else's code as much as possible. If I'm doing a simple, well contained task, someone else has already thought of it and made a library for it. If I need to send an email, I just do something like calling _emailSender.SendEmail(message). Easy peasy.

But processing data is complicated and nothing can completely abstract it away.

I am a lazy programmer in that way. I'd rather autogenerate and use robust libraries as much as possible.

It's not lazy, it's just smart. The less code you write, the better it is.

I think the abstraction layers are important, they should not be leaky. You shouldn't have to go up/down the stack. If you can't build what you want with one tool, then choose another tool.

This is appealing, but I think it's important to recognize just how hard that is.

Abstractions by definition lose information. If that information becomes important, to any user, at any time in the tool's lifespan, somebody has to go and claw the thing open to find it.

Picking an abstraction that never leaks essentially means correctly predicting the entire scope of your problem. There are ways to improve on this, good abstractions try to offer contained 'leaks' that you can enable or access if needed, but that still means predicting the set of possible use cases.

(For a code-adjacent example, Excel is popular as an abstraction on an RDBMS, but it's low-level and even Turing complete. Higher-level tools which don't permit arbitrary data association constantly get scrapped or exported down to Excel because they don't cover every interesting relationship, and Excel data semi-regularly gets pushed back down to databases.)

In school, I learned a lot about the wonders of encapsulation, black boxing, and so on. Within a few years out of school, I realized that one of my most valuable skills was being able to move down the stack when those things inevitably break down. When I do have to go and a library's source, and very occasionally find a bug in it, it often feels like something that couldn't realistically have been anticipated.

Breaking abstraction layers will kill productivity. There's one article that gets posted to HN every year but I can't find it atm. It's about how long it would take to do something from scratch. Taking it into the extreme, including growing your own crops. For computers that would be like mining your own silicon in order to build a CPU, so you can build a PC, to build a boot-loader, a OS, a compiler, a web browser. It will take you years to write that "hello world" program. If you find a bug in a compiler, then that's one day of work gone to debug and path it. Same with libraries, having to write pull requests to the libraries will take time away from whatever you where working on. Leaky abstractions are worse then abstractions. If things are hidden, it will take extra time to dig them out, you could just as well have them all in the open.

Couldn't disagree more. Unless your job is unbelievably trivial, you should use a range of tools and use the best one available for the task at hand.

Lets say you call for pizza, but you need to know how to bake in order to use their self help service, then that's a leaky abstraction. As high levels of abstractions it's OK to only know the name of the different pizzas. And the baker doesn't need a master in chemistry or engineering to operate the oven. We humans are very good at abstracting things and take most abstraction layers for granted, even though the world around us is very complicated.

I fail to see at all how that relates to the question.

If I order a pizza, I’m using a communication channel (phone, internet) to place an order; one tool.

I deeply hope the pizza place is using chefs and an oven to make the pizza; completely different tools.

If I demanded the pizza chef make the dough, slice the ingredients, and bake the pizza with just a stand mixer... that’s just dumb.

Use the appropriate tool for the job and use the right level of abstraction at each step.

Yeah while I think one of the hardest parts if a software developer's job (working at multiple levels of abstraction), that's literally the job. You're translating between the business and the sillicon.

By all means restrict yourself to assembly but yhe rest of us will get more done by using things at convenient levels of abstraction for those specific units.

This is what I get from Pure Data (a graphical audio programming language). Once things get too unweildly, I write a C/C++ extension or Lua script.

At certain large tech companies it’s the difference between an all terrain vehicle and laying frikin tracks for a frikin train.

Most commercial software is basically information systems, with very standard architectures, and no complexity whatsoever.

At least not business-related complexity. Most complexity in those systems is accidental, exactly due to us using the wrong tools for the job (namely, 3GLs + frameworks), which do not provide the proper level of abstraction for the problem at hand.

Even for a single system, no one should be forced to use a single level of abstraction everywhere. The game industry has been mixing 3GL code and assembly whenever needed since it moved on from assembly. You don't have to stick to one for everything.

The only problem is, it’s actually not a road bike, but a shopping cart. The advertisement is that you can sit and not pedal (when down hill). And it’s not faster in any case.