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

161–170 of 334 posts

Re: The “No Code” Delusion

#161

Post by dragonwriter »

sgslo wrote: post #157
UserIsUnused wrote: post #19

Earlier quoted context omitted.

Thank god trends like Pulumi and the new AWS sdk is emerging. General purpose programing languages are getting more expressive by the day, why do we use data serialization languages instead for configs? it doesn't make any sense. Configuration is code not data.

> new AWS SDK Could you share some details on that? A quick Google search didn't reveal anything about major changes to the SDK.

Probably referring to the CDK (Cloud Development Kit), a newish SDK for developing Cloudformation infrastructure-as-code in general-purpose programming languages.

https://aws.amazon.com/cdk/

Re: The “No Code” Delusion

#162

Post by satyrnein »

Wowfunhappy wrote: post #121

There's no such thing as "no code". There's just interfaces which are more-or-less capable, and more-or-less intuitive. Any time you define a set of instructions for a computer to execute, you are creating code. We use Scratch at my Girls Who Code club. It requires students to consider branching paths, and data types, and asynchronous execution. It does not require the students to type , but thank god for that, becau…

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?

Re: The “No Code” Delusion

#163

Post by jimbokun »

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…

I don't think your career is any danger from better tools. (At least short of full-AI, which would put every career in danger.)

All kinds of amazing visual interface building tools have been created, that are very easy to use, easy to teach, easy to get started, and are very powerful. I'm still not sure that a better UI development tool than Hypercard has been invented yet.

So why do professional programmers still exist? Because most people don't want to do even that level of software development. Either they find it beneath them, find it boring, get frustrated when they want to do something that stretches the tool's capabilities, don't want to be responsible for fixing bugs and maintenance, etc. etc. etc.

It's not that most professionals are not smart enough to be programmers. It's that they dislike it enough to pay someone else to do it for them, or would just rather focus their time doing other things they enjoy more or believe to provide more value.

Re: The “No Code” Delusion

#164

Post by jordanbeiber »

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 of course the ones having a blockchain project plodding along), but only a few will go down the “software company” route. It’s kind of tragic.

Re: The “No Code” Delusion

#165

Post by jimbokun »

cr0sh wrote: post #156
detaro wrote: post #55

Earlier quoted context omitted.

Did you do anything special presentation/interface-wise? My impression is that a good part of it for many is not making them realize that they are "programming" until they've already accepted that they can do it, because otherwise they "know" that it is too difficult.

> because otherwise they "know" that it is too difficult. This is something that frustrates me in general, and I'm sure others, too: That there seems to be among a certain population of people a mindset that declares failure before they've even tried. Or, they try, but at the first hint of failure or trouble, they declare that they can't do it, and stop. So what is different about those people who don't do this? Why…

My suspicion is that it's not really that they aren't capable of programming, they just find it boring and would rather be doing something else.

Re: The “No Code” Delusion

#166

Post by yters »

Why does the common non programmer need a visual UI? Why so allergic to typing text? The rest of the average office worker's job takes place through the traditional CLI known as English (or other language).

Re: The “No Code” Delusion

#167

Post by bitwize »

I keep saying it. Whatever non-code representation you may have for your logic -- dataflow diagrams, interpretive dance, Minecraft redstone, whatever -- you need to make it unambiguous enough that a machine can act on it in a well-defined way, and once you do that what you have is isomorphic to a construct in some textual programming language. And lines of text are going to be easier to input, edit, and maintain than your chosen representation, barring some major UI revolution.

Re: The “No Code” Delusion

#168

Post by yebyen »

lucasverra wrote: post #139
yebyen wrote: post #50

Earlier quoted context omitted.

I'm compelled to invoke the "Ninety-Ninety" rule when I hear about solutions like that, although I'm sure it works sometimes, in my experience it usually turns out more like this. The first 90% of the work takes 90% of the time, and the remaining 10% of the work takes the other 90% of the time!

Isn't the majority of software following this rule ? This is not specific of low/no code environment

Yes, absolutely.

But to hear it explained that way, it just seems like wishful thinking based on a circular reasoning, that invites an invocation of the rule... "We spend too much on our developer staff, so in the future we have adopted a strategy where we will avoid most of the things that we need a team of developers for, so that our developers have less work to do, so that we can have fewer expensive devs (of which we know we cannot dispose entirely, [because we are subconsciously aware without them, there is no innovation to speak of at all.])"

The problem that "Low Code" or "No Code" addresses is a real one, where devs like myself, (surely not myself, but someone more junior...) confuse poorly architected slipshod solutions for innovative ones.

If we could reliably keep our code as simple as it ought to be, the market for tools like this would probably not be as large as it is.

Re: The “No Code” Delusion

#170

Post by AnimalMuppet »

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 to the "real" programming language.

Post reply on HN