Live data from Hacker News

The “No Code” Delusion

alexhudson.com

301–310 of 334 posts

Re: The “No Code” Delusion

#301
post #223

Earlier quoted context omitted.

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 you…

> "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! :-)

Re: The “No Code” Delusion

#302
We tried building NoCode (used to be hosted at noapp.mobi), I think around January 2017. The project has been abandoned since then, you can find the project at -

1. Docs - https://github.com/veris-pr/v3-docs/wiki

2. Core - https://github.com/veris-pr/v3-core

3. Backend - https://github.com/veris-pr/v3-api/tree/develop

4. Mobile App - https://github.com/veris-pr/v3-app/tree/feat-offline

5. Mobile App - https://github.com/veris-pr/v3-client

Quick demo (forced under 2 minutes time, we tried to take this to TechCrunch), https://www.youtube.com/watch?v=HfZT75rduPg

This was a POC project. It was quite suitable for simple business process management based apps. One of our customer has been using a conference room manager built on this platform, for 3 years now.

Re: The “No Code” Delusion

#303

The "No Code" movement is not a delusion. Most of us in tech are very ego driven and don't think this will happen, the majority is not in tech and want this to happen. It will happen.

I don't mind it happening. Just most of these tools are rehashes of stuff that happened in the 90's and still have the same problems.

Programming has been an evolution higher and higher abstractions. It's not different.

We will probably move to a higher abstraction, but it will probably something like describing the problem with tests, and the computer automatically writing something that passes these tests.

You still need these skills. You will just accomplish more in less time.

Re: The “No Code” Delusion

#304
post #68

Earlier quoted context omitted.

I can train one of my juniors in how zapier works in an afternoon. Teaching them (or myself) a programming language would take years and be more error prone.

I can teach IF, FOR, and the basics of python in a week. I can teach ruby in about the same. For what they are going to need for a low code solution, that's enough. You don't need to teach all of programming - only a subset that would be covered in a low/no code solution. If you don't believe this, look at how many non-CS professionals have learned VBA as their excel-fu reached a limit. Even if it's not clean to star…

> I can teach IF, FOR, and the basics of python in a week. I can teach ruby in about the same. For what they are going to need for a low code solution, that's enough. You don't need to teach all of programming - only a subset that would be covered in a low/no code solution.

OK, now what? Do you teach them deployment of those "low code solutions"? Is it another week?

"Oh, now you want to send a notification to Slack? That's a little above basics. What about another week of learning the concept of libraries?"

Do you see the pattern?

Re: The “No Code” Delusion

#305
post #187

What makes programming difficult isn't the syntax, it's the need to define the problem in an completely unambiguous and consistent manner.

You forgot a couple of things. You need to define the problem in a way that's complete (no missing corner cases) and be able to debug it when it goes wrong.

Good points.

I think it's interesting to compare source code and legal documents.

A similar need for precision, internal consistency, lack of loopholes is needed when drafting a legal contract or legislation.

This is all done in natural language, but it doesn't make it magically easier.

Re: The “No Code” Delusion

#306
The current focus No Code will create a large number of tools a skilled technologist can use to improve productivity. The new tools will open up problem domains where the time and budget wasn't there before. It's clearly not going to replace code, for reasons that everyone has enumerated here.

The reason it's getting VC attention right now, though, is because No Code is a way to discipline the market for programmer salaries. Even if the effect of it is more glue code over more protocols, the goal is to shift jobs from engineers to technicians.

Re: The “No Code” Delusion

#307
post #245

Earlier quoted context omitted.

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 t…

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.

Re: The “No Code” Delusion

#308

I was once at a company (X) that acquired another company (Y), and Y's main product was a graphical programming tool. Y advertised that their tool could speed application development up 10x. My (nontechnical) manager asked me "why don't you use Y's tool to build the project you're currently working on?" I answered with the following metaphor: Imagine you have to pick a bike to go on a trip. You're travelling on a wel…

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 you…

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.

Re: The “No Code” Delusion

#309

My response to "No Code" solutions: If there was a faster and easier way to develop software, we would be doing it. We are already using the easiest to understand tools we can find to develop the best software possible. There is no secret programmer cabal where we are holding hostage the REAL tools we use to develop software, and we keep them secret and hidden while we fuck around every day. For someone to develop a…

It's a bit like the conspiracy that pharma companies suppress cures because ongoing treatments make more money, and it has the same main flaws. First, without a huge amount of collusion, somebody would release the cure to beat everyone else's treatment. (Which totally does happen.) And in software, people constantly build and release tools for free while decrying paid software as evil; if neither Stallman nor Oracle…

>> First, without a huge amount of collusion, somebody would release the cure to beat everyone else's treatment.

Unless the same party owned the treatment and cure. Dont you see this everyday with x-AAS subscriptions? I mean, they could sell you the software once, but instead it is a service. I've already paid for MS Office three times over because of the service cost

Re: The “No Code” Delusion

#310
The idea that you can write software without having to learn to code goes all the way back to COBOL in the fifties. It was a big step forward in abstracting some of the details. As languages have progressed they abstract away details, but you still have to be able to think like a programmer, especially if you want your code to be performant.
Post reply on HN