Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The “No Code” Delusion

alexhudson.com

Post reply on HN
Print view View original

201–210 of 334 posts

Re: The “No Code” Delusion

#201

Post by shadowgovt »

pwinnski wrote: post #192
shadowgovt wrote: post #144

Earlier quoted context omitted.

Not without an IDE. It's still extremely possible (in all text-based languages I'm familiar with) to write the program with a typecheck error; the typechecker will gleefully catch it for you. At typecheck time. Often (depending on my toolchain) minutes after I've written the offending code and mounds of code depending on it. It's possible, with many languages, to write IDEs that will make this hard, but I've yet to f…

Are you suggesting that you can do visual development without anything more than a text editor? Apples to apples would mean comparing your Scratch experience with a nice IDE for a typed language.

"It's possible, with many languages, to write IDEs that will make this hard, but I've yet to find one that makes it impossible."

Re: The “No Code” Delusion

#202

Post by rchaud »

I think those with a programming background take terms like "no code" far too literally. For those who've worked in finance IT, you may know of staff who've build incredibly elaborate models in Excel, and then have come to you when they need something that can't be done in Excel.

"No code platforms" will likely work the same way. These platforms provide just enough interactive/dynamic functionality for non-programmers to build a decent prototype of what they're trying to create. They can then take this to their dev team (if they have one) and ask for refinements.

Even if the end result requires a full rebuild, I'd wager the devs would be happier because they wouldn't waste time building something based on vague specifications communicated by a non-technical staff member. They'd have a prototype to work off of, and can ask clarifying questions that will be easier for the stakeholder to answer because they can see where the devs are coming from, instead of simply speaking in abstractions about something that doesn't yet exist.

Re: The “No Code” Delusion

#203

Post by _asummers »

tabtab wrote: post #188
smhenderson wrote: post #149

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…

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.

Re: The “No Code” Delusion

#204

Post by satyrnein »

Wowfunhappy wrote: post #181
satyrnein wrote: post #162

Earlier quoted context omitted.

This made me wonder: which side would other activities fall on, if event handling was the defining characteristic of "code"? Not code - Excel, SQL, HTML, CSS Code - Email inbox rules, IFTTT. Alarm clock?

Hmm, y'know what, I'm now reconsidering that part of my post. Setting an alarm clock is definitely not coding. All the instructions are built into the clock: if (currentTime == alarmTime) { soundAlarm(); } All the user does is set the value of alarmTime, a single variable. But, what if the user can choose from a set of alarm sounds? I feel like that's still not coding, but I also can't describe how it's different fro…

Yeah, I was thinking of the alarm clock app on your phone rather than a hardware clock by the bedside, so you're practically hitting "add rule, set trigger, define action" much like IFTTT or email inbox rules.

When I've taught (adults) some basic coding, it's typically been state that's the challenging concept. You have a bunch of logic, but what was the state of your program (or the world) when the logic executed? If it's not what you expected, how did it get into that state? These questions seems fundamentally different to me compared to working on an Excel spreadsheet (which of course can still be complicated and have bugs).

Re: The “No Code” Delusion

#205

Post by cuhpajo »

Everyone seems to want to make an analogy for why no-code tools are bad, or will end badly.

But I've watched countless numbers of individuals start & build full web apps, websites, mobile apps, and more - all without code.

No-code tools are viable to use to build a product or business, and they're here to stay.

They're not here to "take dev jobs", but they are here to empower the 99.5% of people that don't know how to code.

Imagine what features more advanced no-code tool platforms like Webflow.com & Bubble.io will have in 5 years.

While y'all discuss pros/cons, we'll be busy building.

Re: The “No Code” Delusion

#206

Post by blowski »

jordanbeiber wrote: post #164
slumdev wrote: post #148

Robotic Process Automation (RPA) is the new "No Code". And it will fail the same way every other "No Code" fad has failed over the years, no matter how successfully McKinsey sells it for the next few years. It will never completely disappear, but there is no future where a BA with an overhyped macro suite replaces the whole of software engineering.

RPA just seems crazy... I mean, I see the golden shimmer, but why do so many enterprises refuse to actually, you know, solve the problem? I have, btw, just finished reading “the phoenix project”. Brilliant book! Having lived through pretty much that story a couple of times, the solution is just that simple. Not easy, but simple. Been around a while, at several big companies, I know most of them will do RPA (they are…

Because they can’t go straight from A to B, because there are so many audited processes that are tightly coupled to A. So they replace A with B one step at a time, and keep A in sync with B using RPA. When the whole of A is replaced, you turn it off along with the RPA.

The problem comes when RPA stops being a short-term tactic, and starts being a long-term cottage industry. Unfortunately, RPA vendors have a vested interest in keeping A around as long as possible in order to maintain the necessity of their solution.

Re: The “No Code” Delusion

#207

Post by tabtab »

_asummers wrote: post #203
tabtab wrote: post #188

Earlier quoted context omitted.

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.

Re: The “No Code” Delusion

#208

Post by hinkley »

markmiro wrote: post #155

I like to think of the no-code stuff like this: - People who are into this stuff know there's something to it, but as a movement, we don't know exactly what it is. - My personal feeling is that any no-code tool should be useful enough that I would use it. I want some no-code to make me feel for my career a bit. - The "threat", I think, is very real. For example, whenever I see myself following a set of rules to write…

We had a lead who wanted to do front-end code but hated HTML. He really, really wanted us to use something where he could pretend he wasn't writing HTML. But AJAX was the big thing, our app required a lot of interactive HTML, and CSS3 was just on the radar.

He would mark stories as done that had tons of layout problems. He just couldn't be arsed to dig into it, because you actually had to stick your whole arm into the guts to get things to work. Between me and another guy who were doing 60% of the interactions and north of 80% of the bugfixes we finally browbeat him into going back to real HTML templates. He retreated to writing mostly backend code from then on, which honestly reduced our workload by itself.

Pretending you have a different set of core problems than you actually have has never ended well for me, and I'm convinced it has never ended well for anyone else either. Don't abstract away your problem domain, and don't kid yourself about what your problem domain is.

Re: The “No Code” Delusion

#209

Post by weiluen »

AnimalMuppet wrote: post #170
sequoia wrote: post #140

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…

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

Re: The “No Code” Delusion

#210

Post by dlwdlw »

sequoia wrote: post #140

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…

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