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

41–50 of 334 posts

Re: The “No Code” Delusion

#41

Post by maweki »

collyw wrote: post #36
UserIsUnused wrote: post #27

Earlier quoted context omitted.

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

So how do you differentiate a declarative language like SQL with a declarative YAML file for Ansible? What would be the benefit of adding a declaritive language into the mix over YAML?

If you want to build a DSL, build a DSL. DSLs are easily embeddable in the mentioned programming languages.

YAML is not typed and you can basically do whatever. The worst of all worlds.

Re: The “No Code” Delusion

#42

Post by aequitas »

collyw wrote: post #24
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…

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

While (most) actions in Ansible modules are idempotent the entire playbook is not. So how your system is going to look at the end of a run is highly dependent on the order of everything in your YAML files and the current state of the system. You can ensure a file exists in and part and remove the directory containing it in another, and you are non the wiser unless you run the playbook multiple times and pay attention to the changes.

Re: The “No Code” Delusion

#44

Post by mimixco »

osullivj wrote: post #14
mikece wrote: post #12

I've been hearing about "no code" or "no programmer required" business solutions for over 20 years. Cynically, I encourage this thinking because my billable rate to untangle someone else's hot mess when urgent deadlines are looming goes up. Practically speaking, if the business problems being solved are complex you might be able to pull off a low-code solution but without knowledge and practice of the essential archi…

Nearly 40 years for me; I remember reading about The Last One [1] back in 81. [1] https://en.wikipedia.org/wiki/The_Last_One_(software)

Yes, in the 80's and 90's we called it CASE (Computer Aided Software Engineering). It was just as fascinating then and equally impractical now. Text turns out to be a great, compact way to convey ideas or instructions which is the heart of software development.

Re: The “No Code” Delusion

#45

Post by UserIsUnused »

collyw wrote: post #36
UserIsUnused wrote: post #27

Earlier quoted context omitted.

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

So how do you differentiate a declarative language like SQL with a declarative YAML file for Ansible? What would be the benefit of adding a declaritive language into the mix over YAML?

Tooling. Data transformation. Libraries.

Emacs is configured using Lisp. Because of that it is amazingly configurable. XMonad uses Haskell, which gives types to avoid lots of error cases.

The thing is providing an actually programming language doesn't remove anything specially if the same config can be written as cleanly.

And you would avoid "YAML templates for creating YAML", when you actually need to process some data (even if it's just for pre/suffix creation in names). Secrets retrieval is another thing that you also need to do and template.

Also, YAML is a terrible to parse language, with can give out weird error cases. Other languages compilers/interpreters are more mature.

And ofc, if you provide SDKs for your IaC tool, you should be able to use the language that your developers are more familiar with. Taking advantage of the good practices their are used to. Don't limit with "declarative languages". Use a programing language that make more sense, and leave data languages for data.

Re: The “No Code” Delusion

#46

Post by dangerface »

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…

You can implement LUA in less lines of code than YAML, lua has been around longer, easier syntax, loads of support, proper community around it. Yet people still use YAML on hype alone, it's awful.

Re: The “No Code” Delusion

#47

Post by ckuehne »

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…

This sounds a lot like the "We do everything with XML now"-phase that the Java world has gone through.

Re: The “No Code” Delusion

#48

Post by logicIsTruth »

Angostura wrote: post #35
emilecantin wrote: post #13

I read somewhere a quote that stuck with me: "No tool is ever going to free us from the burden of clarifying our ideas." And that's how I view my job as a software developer: clarifying ideas. Any "No Code" tool is still going to either force you to clarify your ideas, or have a large amount of assumptions. "Idea People" and "Business" don't like that, so they'll probably end up delegating the use of "No Code" tools…

I rather disagree. I work at a large non-profit. I'm not a coder, but I'm IT literate, and know enough about database design to not do absolutely stupid things. I'm happy to document processes enjoy clarifying ideas. We use Sharepoint. In many many respects Sharepoint is detestable garbage, but I have managed to create some really quite complex automated workflows which are saving people in the organisation a lot of…

Eh, the automation I've done between python, vba, and SharePoint (language/markup) has convinced me anything is possible.

Re: The “No Code” Delusion

#49

Post by jordanbeiber »

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…

Well, I would have to disagree (but agree somewhat, as well :)). These insanity levels you describe, and I agree with you here, are actually pushed through projects by coders for coders.

Here in lie much of the ”devops” problem, imo, as coders seem to want to allow easy configuration management through “simple“ declarations, inventing almost a new language in the process.

Having worked for 20 years with systems/configuration management, mainly as a developer I can tell many coders have not. Not at scale, and not supporting 100s of different services simultaneously. Hence square wheels gets re-invented.

To be rid of all yaml templating and loosely coupled technical integrations you will have to treat config/service delivery/ci/cd/what-have-you as a business domain of it’s own, and develop it the same way.

I guess we agree, completely perhaps?! :)

I’ve been fortunate to have been able to work everything from small upstart to big corporate enterprises and to me this is more true now than ever.

As a developer I build my own version of a CMDB, I do not use crazy templating - I write an API, that leverages the CMDB and produces sane output. It’s still configuration as code, just something that is easier to scale and adapt.

Guess I’m only disagreeing on whom to blame for this mess.

Re: The “No Code” Delusion

#50

Post by yebyen »

mmerlin wrote: post #4

"Low Code" is currently where it's at. Intelligent subject-matter experts who are non-programmers can build 80 to 90% of their business info capture and reporting requirements inside the walled garden of their chosen platform. Programmers are called in temporarily to complete the final 10 to 20% of the LowCode app, and integrate with external services. It's been happening since Excel, through to Wordpress and nowaday…

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!

Post reply on HN