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

131–140 of 334 posts

Re: The “No Code” Delusion

#131

Post by marcosdumay »

solatic wrote: post #78
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…

> Especially with tools like Helm I believe we reached peak insanity levels. Instead of using a general purpose or configuration-specific (like Jsonnet/Cue/Dhall) programming language to build and then emit in-memory objects to YAML manifests, the industry is using YAML to define templated YAML and then parametrize this templating with even more YAML. As a big proponent of Dhall, I gotta say, probably the primary rea…

There is a levels of indirection problem with that explanation.

Using Dhall to create the YML you will use isn't great, but it's quite possible today and is much better than using YAML to script a YAML generator that will read some more YAML to create the YAML you will use.

I guess some people simply like YAML.

Re: The “No Code” Delusion

#132

Post by marcosdumay »

bitcuration wrote: post #128
worldsayshi wrote: post #20

Earlier quoted context omitted.

There are plenty of tools that help us in clarifying our ideas though. Take mathematical notation for example. Or music notation. Or a CAD program. All are examples of domain specific tools that allow the user to specify their intention in a non-ambiguous way. And they also allow the user to think about and experiment with the problem space. I think what we need is something akin to this. The "business logic" that we…

Business domain vs. Math., that's an interesting comparison. The problem is that business domain is exact an "infinite domain", in comparing with Math. Or to say that the competitive nature of business is very much reliant on its ability to break its domain boundary. Again, not so much in the case of Math.

> Again, not so much in the case of Math.

I will resonantly disagree here. Math is successful exactly because each time it had a rule that was problematic, people just extended it.

And the success of modern (20th+ century) Math is caused exactly by the fact that we got an inifinitely extensible language, so nobody has to ever break it again anymore.

Re: The “No Code” Delusion

#133

Post by toyg »

reallydontask wrote: post #104
toyg wrote: post #103

Earlier quoted context omitted.

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

Most devops tools are built on Linux for Linux, then ported to Windows later as an afterthought, so I don’t think platforms are much of a factor. It’s a defect in the production pipeline somewhere, something like feedback from potential users not reaching developers until it’s too late. It doesn’t help that, in some cases, vendors just impose what is going to happen, and the community is simply forced to put up with it.

Re: The “No Code” Delusion

#136

Post by pavlov »

mimixco wrote: post #44
osullivj wrote: post #14

Earlier quoted context omitted.

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.

Conveying ideas and instructions is also at the heart of architecture. Digital representations are embedded at every stage of a contemporary building design and construction pipeline. 98% of those representations are something else than text.

I strongly believe software application design is fundamentally closer to architectural design than the kind of work done in a purely textual realm — say, writing a novel or a research paper. But it's a really hard nut to crack.

I hope CASE today is like AI and neural nets were in early 2000s — a bit of a laughing stock, "something people in the 1980s wasted a lot of time on but nowadays everyone knows it doesn't work."

Re: The “No Code” Delusion

#137

Post by bpizzi »

shadowgovt wrote: post #97
mimixco wrote: post #44

Earlier quoted context omitted.

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.

I don't think text is nearly as compact as people claim it to be. I dabble in graphical programming languages from time-to-time, and one feature they all share is the editing environment for code makes entire categories of syntax error impossible; there is no way in the language's design to pass a string to a function that only accepts a number, for example, because the "blocks just don't fit together." It's a level…

> there is no way in the language's design to pass a string to a function that only accepts a number, for example, because the "blocks just don't fit together."

Which is easily achieved by the first typed language that comes to hand, no?

Re: The “No Code” Delusion

#138

Post by solatic »

marcosdumay wrote: post #131
solatic wrote: post #78

Earlier quoted context omitted.

> Especially with tools like Helm I believe we reached peak insanity levels. Instead of using a general purpose or configuration-specific (like Jsonnet/Cue/Dhall) programming language to build and then emit in-memory objects to YAML manifests, the industry is using YAML to define templated YAML and then parametrize this templating with even more YAML. As a big proponent of Dhall, I gotta say, probably the primary rea…

There is a levels of indirection problem with that explanation. Using Dhall to create the YML you will use isn't great, but it's quite possible today and is much better than using YAML to script a YAML generator that will read some more YAML to create the YAML you will use. I guess some people simply like YAML.

I agree, which is why I use Dhall at work. But the fact of the matter is that `kubectl apply -f config.dhall` isn't realistic yet, and there's a big segment of the market that's just not willing to accept anything but that.

Re: The “No Code” Delusion

#139

Post by lucasverra »

yebyen wrote: post #50
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!

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

Re: The “No Code” Delusion

#140

Post by sequoia »

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 well paved road through the woods. If you take a light & narrow wheeled racing bike, you'll travel much much faster than if you ride a knobbly wheeled mountain bike with suspension, as long as you stay on the road. As soon as you need to go off the road and cut a new path, you are going to wish you had that mountain bike, and the road bike is actually going to make you go much slower or just stop altogether.

So does the "speed bike"/advanced framework make you go faster? Yes, as long as you stay on the road (i.e. constrain your requirements to their feature set). The moment you need to "go off-road" (i.e. do something the framework doesn't do), such tools actually make it difficult or impossible to make progress.

This is why, for a complex applications (most commercial software), I prefer the mountain bike. Yes, it's slower on certain paths, but when we need to "go off-road" I don't slow to a stop.

Post reply on HN