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

321–330 of 334 posts

Re: The “No Code” Delusion

#321

Post by z3t4 »

Bartweiss wrote: post #307
z3t4 wrote: post #245

Earlier quoted context omitted.

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, go…

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.

Re: The “No Code” Delusion

#322

Post by yebyen »

rgoulter wrote: post #288
bcrosby95 wrote: post #243

Earlier quoted context omitted.

Kinda, it sounds very similar to the 80/20 rule. The 80/20 rule says 80% of the solution takes 20% of the time. So it's not quite the same. In other words, the 80/20 rule says the last 20% takes 4x as long as the first 80%. In comparison, the above quote says the last 10% takes just as long as the first 90%. So slightly different.

Both this "90-90" and "80-20" indicate that the devil is in the detail. e.g. You can expect surprises as you're almost done, there's an inherent complexity to the solution, etc. But saying "the first 90% takes 90% of the time" blatantly ignores these anticipatable unknowns; so it's a much more tongue-in-cheek thing to say.

The other way to read it, I guess, is that you can correctly anticipate those unknowns. The canonical way I hear is to add 1/3 to your estimates.

Re: The “No Code” Delusion

#323

Post by DonHopkins »

reitzensteinm wrote: post #195
brazzy wrote: post #39

Earlier quoted context omitted.

The pipe dream is far older than that. Around 1960 some people seriously claimed that within about 5 years there would be no more professional programmers because with this new language, everyone could write the software they need themselves, since it was so easy to use. The language was COBOL. Oh, and look, this one still seems to be around: http://www.makeyourownsoftware.com/

Oh my god, I was convinced until the end that it was a top notch joke site... then I got to the credit card form.

There used to be an early ARPAnet mailing list called "INFO-COBOL@MC", that was actually for exchanging jokes and copyrighted Dave Barry articles (which was an officially prohibited abuse of the government sponsored ARPAnet). It was a great stealth name because nobody took COBOL seriously, and we would just laugh at people who posted COBOL questions.

Here are some old INFO-COBOL messages archived in the MIT-AI HUMOR directory:

http://its.svensson.org/HUMOR%3bINFO%20COBOL

Then there was The TTY of Geoffrey S. Goodfellow's spin-off, the specialized "DB-LOVERS" mailing list, just for dead baby jokes.

https://news.ycombinator.com/item?id=8418591

Speaking of COBOL jokes:

https://medium.com/@donhopkins/cobol-forever-1a49f7d28a39

Re: The “No Code” Delusion

#324

Post by xiwenc »

The delusion is thinking "no code" solves all your (classical) problems. It does not. No code is the future riding the waves of simplifying programming. Like going from C -> Java -> Python -> (Low code) -> No code

Re: The “No Code” Delusion

#325

Post by xiwenc »

vsskanth wrote: post #80
swalsh wrote: post #26

I've spent a long time trying to build "No Code" solutions. Probably 3 different products, 3 different companies. But once, I tried something different. I pushed back, instead I proposed we build a domain specific language using Ruby. I already had some trust with my boss... and he was pretty convinced it was going to fail, he had zero faith these smart (but non-technical) users could successfully use it. But he was…

I second this. People can go very, very far with simple and sand boxed Domain Specific Languages that are targeted towards the core function. There are so many commercial successes for this approach: CAD, MATLAB, Simulink, LabVIEW, Dymola, Excel (?) The biggest issue with many of these tools is that they tend to be closed source, proprietary formats, onerous licensing terms, not easily extended and aren't easy to dep…

I mostly agree with you. As an independent professional, I hate complete ecosystem platforms also. We need composable systems. Not more locked down.

Mendix (https://www.mendix.com) does a lot of that well but as you pointed out it's proprietary.

If we look at history, successful predecessors like C, Java and Python (sorted by difficulty) are all open standards.

I think the next low/no code platform to open their specifications wins the race.

Disclaimer: I've worked for Mendix.

Re: The “No Code” Delusion

#326

Post by reitzensteinm »

DonHopkins wrote: post #323
reitzensteinm wrote: post #195

Earlier quoted context omitted.

Oh my god, I was convinced until the end that it was a top notch joke site... then I got to the credit card form.

There used to be an early ARPAnet mailing list called "INFO-COBOL@MC", that was actually for exchanging jokes and copyrighted Dave Barry articles (which was an officially prohibited abuse of the government sponsored ARPAnet). It was a great stealth name because nobody took COBOL seriously, and we would just laugh at people who posted COBOL questions. Here are some old INFO-COBOL messages archived in the MIT-AI HUMOR…

That's pretty funny, thanks for sharing!

Re: The “No Code” Delusion

#327

Post by emilper »

smhenderson wrote: post #301
JadeNB wrote: post #223

Earlier quoted context omitted.

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

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

Re: The “No Code” Delusion

#328

Post by scroot »

jimbokun wrote: post #163
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 ex…

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

I'm not so sure about this. Hypercard was extremely popular among non-programmers in its heyday. It is not their fault that Apple, who had no idea what to really do with the software, let it die on the vine.

Computer companies have inclucated a computing culture that places a sharp perceptual divide between users and programmers, leaving little room for anything in between. My belief is that this has happened for wider structural/economic reasons (contemporary emphasis on consumerism, short term thinking, etc) rather than any general distaste for "real computing" among regular people.

If we do not provide regular people with "Hypercard-like things" and instead give them shrinkwrapped solutions, we will of course have the perception that they have no interest in what we call -- for lack of a better term -- end user programming.

Re: The “No Code” Delusion

#329

Post by markmiro »

hinkley wrote: post #208
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 th…

I think layout is a big hurdle for no-code tools. I also think it's going to get solved. But until then, I think you really gotta dig into HTML and CSS and understand them well to get things to work properly.

"Don't abstract away your problem domain"

I dunno. I tend to think of it as getting good at what you do, then finding the rules, then taking those patterns and making a company out of it where those patterns are built-in to the product.

Re: The “No Code” Delusion

#330

Post by markmiro »

coffee wrote: post #238
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 want some no-code to make me feel for my career a bit. It sounds like your career is software engineering, if so... > My personal feeling is that any no-code tool should be useful enough that I would use it. Someone who's a software engineer is not the litmus test. These tools, from what I've seen so far, are NOT for software engineers. So you wouldn't need to use them. Instead, from what I've seen so far, these…

You're right, most successful no-code tools are for non-programmers, and programmers shouldn't be the ultimate litmus test.

I also believe that if a coding tool will make me more productive, I'll use it, even if it's not a library or a language. Right now the visual tools are limited, but it doesn't have to be that way.

I've used Flash, Windows WPF apps, those visual tools for making apps in xCode, and others. I think there's something to having visual tools for building apps. I think it's clear that UI doesn't need to be in code. Maybe state machine logic shouldn't be written in code either. Maybe high-level software architecture constraints shouldn't be in code.

Post reply on HN