Live data from Hacker News

The “No Code” Delusion

alexhudson.com

61–70 of 334 posts

Re: The “No Code” Delusion

#61
post #24
post #9

This delusion is especially visible in the DevOps space. For some reason we have decided as an industry that instead of writing some code in whatever 'real' language we will base operational work on YAML with ad-hoc templating and stringly-typed programming constructs. The main culprits are Ansible/Salt and all the string-templating based tools for Kubernetes (Helm/Kustomize/...). Especially with tools like Helm I be…

To play devils advocate, isn't the idea with Ansible at least that it's idempotent. The YAML should describe the final state and should be concerned with branching or lower level features like that. (It's the same with SQL, you describe what you want back rather than how its achieved. A declarative approach works fairly well there.)

What's needed is an internal data-structure that defines the state needed -- YAML declares the structure directly, but an alternative is to use either a DSL or even a general-purpose language to build that data-structure.

Of course, you could write code to generate your YAML, but the tooling is _not_ going to help you with that today.

Maven and Gradle are examples of each of these methods -- both build up an internal model of the build, but while Maven uses XML, Gradle uses a Groozy DSL.

Re: The “No Code” Delusion

#62
post #55
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…

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.

I actually wrote a plugin for sublime, which allowed them to write the script then directly upload to our service, it also had some code snippets in it so they could right click, then quickly add and modify what they needed while they were learning (this feature was not used as much though, watching them, they seemed to prefer looking at scripts that did something similar and just copy and pasting from it). But other than that, it was just sublime.

Re: The “No Code” Delusion

#63
post #5

While I agree with the author, it's only true when speaking of software that requires custom logic. For instance, "no-code" website creation offering has done wonders in replacing the "install wordpress on a very crappy cheap host and let it rot with vulnerable plugins" paradigm.

Is that very different from the websites of the 90s? I distinctly remember creating a somewhat-dynamic site in FrontPage, then rendering it into static HTML and FTPing it to the webserver.

Perhaps this was an impedance mismatch: "web requires coding" - it mostly doesn't, most people would be okay with a better HTML editor, and providing that via WP was a historical quirk.

Re: The “No Code” Delusion

#64
post #51
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…

That is really cool. How did you go about designing the language. Did you go for a full lexer and parser ? or it was more functional. Curious to understand how you built it.

Ruby's super power is it's meta programming ability. So they were really just writing Ruby. If you google, I think there's a bunch of tutorials out there for creating a DSL in Ruby... but I learned from a book called "Metaprogramming Ruby"

Re: The “No Code” Delusion

#65
post #9

This delusion is especially visible in the DevOps space. For some reason we have decided as an industry that instead of writing some code in whatever 'real' language we will base operational work on YAML with ad-hoc templating and stringly-typed programming constructs. The main culprits are Ansible/Salt and all the string-templating based tools for Kubernetes (Helm/Kustomize/...). Especially with tools like Helm I be…

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.

I still have my reservations against Pulumi in particular, though.

I've only really skimmed their documentation, but the idea that calling 'new' against a VM class instantiates a VM in production seems to be to magical for my taste, and might be an indication that it's yet another product that targets the happy path more than what we tend to experience in production: failures.

Re: The “No Code” Delusion

#66
post #54

As a marketer, I always look for no code solutions first. API integrations? Use Zapier. Email form integration? Sumo or similar. Triggers? Google tag manager. Etc. The reason being that the dev team at any company never has time for new projects.

So, instead of "learning a new language", they're "configuring a new integration"? Guess how much these differ...spoiler: two marketing labels for the same thing.

Re: The “No Code” Delusion

#67
post #5

While I agree with the author, it's only true when speaking of software that requires custom logic. For instance, "no-code" website creation offering has done wonders in replacing the "install wordpress on a very crappy cheap host and let it rot with vulnerable plugins" paradigm.

Is that very different from the websites of the 90s? I distinctly remember creating a somewhat-dynamic site in FrontPage, then rendering it into static HTML and FTPing it to the webserver. Perhaps this was an impedance mismatch: "web requires coding" - it mostly doesn't, most people would be okay with a better HTML editor, and providing that via WP was a historical quirk.

The no code websites are so much better now. Shopify powers a ton of big eCommerce now, for instance.

Re: The “No Code” Delusion

#68
post #54

As a marketer, I always look for no code solutions first. API integrations? Use Zapier. Email form integration? Sumo or similar. Triggers? Google tag manager. Etc. The reason being that the dev team at any company never has time for new projects.

So, instead of "learning a new language", they're "configuring a new integration"? Guess how much these differ...spoiler: two marketing labels for the same thing.

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.

Re: The “No Code” Delusion

#69
post #9

This delusion is especially visible in the DevOps space. For some reason we have decided as an industry that instead of writing some code in whatever 'real' language we will base operational work on YAML with ad-hoc templating and stringly-typed programming constructs. The main culprits are Ansible/Salt and all the string-templating based tools for Kubernetes (Helm/Kustomize/...). Especially with tools like Helm I be…

The ironic thing is that—specifically in the cloud space—we call this no-code abomination “infrastructure as code”.

But at least there is the AWS CDK and Pulumi now to enable “infrastructure as code” as code.

Post reply on HN