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

101–110 of 334 posts

Re: The “No Code” Delusion

#101

Post by toyg »

nnq wrote: post #99
q3k wrote: 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…

Maybe because we've chosen such rigid, inexpressive and DSL-hostile programming languages for devops... I mean, Python, Go... ofc you'd rather write your DSL in YAML instead and forego any checking the language might provide since everything else would be too awkward. Something like a "statically typed Ruby" would probably shine here.

TL;DR: "your language sucks, my language would shine"

Language doesn't matter. What matters is the attitude of tool builders that everything should "simply" be described as data. When that turns out to be insufficient, as it inevitably does, hacks are introduced and sooner or later you end up with crippled and idiosyncratic pseudo-languages.

Re: The “No Code” Delusion

#102

Post by toyg »

solatic wrote: post #88
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.

> General purpose programing languages are getting more expressive by the day You know, once upon a time, we understood that declarative approaches to software engineering were superior to imperative approaches, when declarative approaches are feasible. Declarative approaches are much safer and easier to test, at a cost of only being able to express what the tool accepting the declarative approach can understand. Imp…

That's a bit of a no-true-scotsman there. If the problem is just the markup of choice, we should see an alternative markup emerging any time now. If we see imperative-focused tools instead, maybe it's not just about the markup.

Re: The “No Code” Delusion

#103

Post by toyg »

reallydontask wrote: post #25
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.

The main problem is that, in my experience, the majority of DevOps teams are Ops teams that have been renamed and refocused towards automation. These are people that by and large don't want to code, not saying that they can't or won't. To be fair this has been in Windows shops, where scripting has only recently (last 5-10 years) taken off, so you've got a lot of windows admins that the closest they've been to code is…

> These are people that by and large don't want to code

I disagree. That's the stereotype that tool builders have of such people. Good ops people have always loved coding, or we wouldn't be living on the mountains of Bash scripts also known as "Linux distributions".

(Besides, people who don't like to code won't like writing tons of declarative markup either. So there is little point in the current approach either way.)

Re: The “No Code” Delusion

#104

Post by reallydontask »

toyg wrote: post #103
reallydontask wrote: post #25

Earlier quoted context omitted.

The main problem is that, in my experience, the majority of DevOps teams are Ops teams that have been renamed and refocused towards automation. These are people that by and large don't want to code, not saying that they can't or won't. To be fair this has been in Windows shops, where scripting has only recently (last 5-10 years) taken off, so you've got a lot of windows admins that the closest they've been to code is…

> These are people that by and large don't want to code I disagree. That's the stereotype that tool builders have of such people. Good ops people have always loved coding, or we wouldn't be living on the mountains of Bash scripts also known as "Linux distributions". (Besides, people who don't like to code won't like writing tons of declarative markup either. So there is little point in the current approach either way…

It might be a stereotype but it's also my experience, which granted is limited and Windows based, which as I pointed out in the previous comment hasn't been really onboard with the scripting experience until relatively recently

As to the declarative markup, for instance Azure Devops still doesn't have feature parity between YAML pipelines and classic pipelines, so while you could well be right about the same resistance to yaml, it's not, necessarily an issue yet.

Re: The “No Code” Delusion

#105

Post by camgunz »

cm2012 wrote: 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.

Yeah I've always read this to be a failure of engineering to produce stuff in time. I wonder if it's a failing of open source that it hasn't gotten to web infrastructure yet.

Re: The “No Code” Delusion

#106

Post by commandlinefan »

malux85 wrote: post #8

Cute article, but worthless and shallow. Sure you can replace 4-5 lines of python with some box-based UI rule system, but anybody who’s not first week out of a 2 week coding boot-camp knows that the devil is in the detail. What if instead of “display error” it’s “try again if it’s a mail server error up to a maximum of 4 tries then email the administrator and save debugging info” Then what about a loop? Have you ever…

That's... exactly what the article says.

Re: The “No Code” Delusion

#107

Post by ebiester »

Dirlewanger wrote: post #98
ebiester wrote: post #86

Earlier quoted context omitted.

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…

Doesn't matter if teaching fundamentals only takes "a week" -- that can't be afforded when you need a tool right now .

While true, that's a big failure of business - fix the pipeline before the fire, no?

Re: The “No Code” Delusion

#108

Post by thrower123 »

I've seen this so many times - rather than just write code to do something, wouldn't it be grand if the users could plug their code in with some scripting language or twiddle some configuration and poof! magic! new features just happen!

It's one of those things that looks grand on the whiteboard and fantastic on the slide deck, but holy fucking christ when it comes down to implementing it and moreover, having to support it forever after, the pain spirals. Users can't actually implement their plugins, so you end up writing them for them, in a gimped DSL or scripting language, and all the initial choices that were made become ossified, because you then can't ever risk breaking some potential plugin code out there that depends on the API.

Re: The “No Code” Delusion

#109

Post by roller »

UserIsUnused wrote: post #27
collyw wrote: post #24

Earlier quoted context omitted.

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

There are plenty of declarative programming language families. Lisps, MLs, SQLs. Configuration is code. Use a programming language.

Here's an example of a config system using prolog: https://github.com/larsyencken/marelle

It's a hard to tell where marelle ends and the config begins, since it's all just prolog.

Re: The “No Code” Delusion

#110

Post by mikece »

physicles wrote: post #59
arethuza wrote: post #17

Earlier quoted context omitted.

I'm actually quite fond of some "no/low code" tools but there is a threshold of complexity beyond which if you use them then terrible abominations will result that are far more complex then the equivalent code and actually require more technical expertise then 'code' - so you end up with components that only a skilled developer can maintain in a platform that developers will hate.

I’ve dealt with a few of these too, and the point at which you should just give up and switch to python/bash/anything always comes sooner than you think. By the way, this is an anti-pattern known as a Turing tarpit: https://en.wikipedia.org/wiki/Turing_tarpit

The classic magnet for this: Microsoft Access. It's a fantastic force-multiplier until Dr. Jekyll turns into Mr. Hyde and begins grinding your business to a halt.
Post reply on HN