[HN Gopher] Rails is better low code than low code
___________________________________________________________________
Rails is better low code than low code
Author : thunderbong
Score : 70 points
Date : 2024-11-27 07:16 UTC (4 days ago)
(HTM) web link (radanskoric.com)
(TXT) w3m dump (radanskoric.com)
| namaria wrote:
| The low code space has been well explored. Excel is the flagship
| product in that space.
|
| You tell me if you want to be involved with a long lived and non
| trivial collection of spreadsheets.
| rqtwteye wrote:
| Not sure if Excel is low code. It has a pretty full featured
| language behind it: VBA.
| ebiester wrote:
| Retool has JavaScript. This is common for low code to have
| full languages attached.
|
| The point is that you can do 80% of the presentation by
| wiring things together and only rely on coding for the most
| complex tasks.
| stefan_ wrote:
| I don't know if that is the case. Here is a low code flagship
| product few people have heard of:
| https://mathworks.com/products/simulink.html
|
| It runs your car engine.
| cpgxiii wrote:
| More exactly, C code (hopefully MISRA C) generated from
| Simulink models runs much of the embedded systems in many
| cars. Although sometimes (cough, Toyota/Denso, cough) that
| generated C is then bodily assaulted by questionably
| competent embedded developers until it combines the worst
| qualities of MISRA C and low-quality embedded development,
| because, like many low-code solutions, getting (and keeping)
| everything in the low-code model is hard and the built-in
| escape hatch to a real programming language is not always a
| good fit to the problem at hand.
|
| (As a nit, I suspect that Simulink is known and deservedly
| disliked by the vast majority of people with non-software
| Engineering degrees, given the omnipresence of Matlab in
| academic contexts.)
| IshKebab wrote:
| I don't particularly want to be involved with a long lived and
| non trivial collection of Ruby code either, if my experience of
| the Gitlab codebase is anything to go by.
|
| I agree with the author's point, if you replace Ruby with
| something less awful (Deno, Go, etc.)
| lordofgibbons wrote:
| That's AN example, idk if I'd call it the flagship product.
| Another example is: https://www.sidefx.com/products/houdini/
| which uses node based programming with small amounts of code
| for edge cases. It's used in a lot of movies very successfully.
| simplemindedbot wrote:
| So low-code is faster to get started with little programming
| knowledge but isn't expandable. OTOH, a language and framework
| that you've taken the time and effort to learn takes a little
| longer to get started but is ultimately more suited to more
| complex tasks.
|
| I think the takeaway from the narrative here is knowing when to
| switch from the low code platform and call it a PoC. I'd have cut
| that off around the point that the custom lambda came into play.
| That way you've used the low code environment for what it's good
| at, creating something "they" can react to and easily explore
| basic functionality. While at the same time you're taking those
| learnings and building the more robust solution.
| ljoshua wrote:
| I agree that the main takeaway is knowing when to switch.
| Having a mental model for this makes many future discussions
| and decisions much easier, because this seems to be a conundrum
| that comes up frequently (even for me inside of a large tech
| organization!).
|
| Based on my experience, I'd suggest the pivot point occurs
| before even starting: it should pivot around who is building
| and maintaining the system. If you have the experience needed
| to quickly develop a solution in code, do it in code. If not,
| because this is a non-technical team without technical
| resources, do it in low code. Simple as that.
| rqtwteye wrote:
| I usually go straight to the full language. It's pretty hard to
| find the point when to switch from low code to something else
| when there is time pressure.
|
| Same with bash vs python. People say you should switch from
| bash once you have more than 100 lines or so. But at this point
| you already have some complexity in bash which makes the switch
| to python non trivial. So you usually end up patching the bash
| script in small increments as needed. It gets messier and
| messier but nobody wants to/can spend the effort for a full
| conversion
| jitl wrote:
| I don't want to build in a language without types, but low code
| is even less types than Rails. I've just never worked on a public
| app that was simple enough for Rails to feel good - Airbnb was
| rails but by the time I got there it was very much not simple.
| Internal tools in rails though, that is okay.
| darepublic wrote:
| I expect low code that can be translated into typed clean code.
| The low code side of it is just with more assumptions baked in.
| And with llms you can perhaps have a lot of leeway to in fact
| customize and allow low or no coders to specify somethinf
| exportable to readable typed code
| ajayvk wrote:
| This is what I am trying to solve for with
| https://github.com/claceio/clace.
|
| Allow internal tools to be built with regular frameworks, while
| making it easy to add gitops, SSO, secrets management etc which
| are required for internal tools.
| Neywiny wrote:
| It would be nice to get a brief definition of "low code."
| Otherwise great article. I've found myself using "low code"
| frameworks when they setup my environment for me and can generate
| the code files. Key example was a Minecraft mod maker. Within a
| minute I was fed up with the scratch style programming, but it
| had all the Java build stuff ready for me to just edit the files
| myself. No setting up gradle or anything.
| p1necone wrote:
| I think this is the key to them actually being useful -
| generate a sane project in some widely used language under the
| hood, and let people give up on the low code solution when they
| outgrow the guardrails. Otherwise you're just dooming yourself
| to an eventual rewrite as soon as you need some feature that's
| not supported.
| bloomingkales wrote:
| "Low code" means you do not have to go beyond the tool to solve
| problems. In fact, there should be entire problems you cannot
| even create with low code tools. Programming could mean an
| endless rabbit hole through several technologies, same with
| designing (you are concocting designs that may use several
| different technologies).
|
| If the tool lets you make a circle button and change text in
| it, then that's all you have to worry about.
| jameslk wrote:
| Both low code and Rails have become a lot less relevant since LLM
| assisted coding became the norm.
|
| Low code became less relevant because 1. LLMs solved many of the
| problems low code solves with better control over the output, and
| 2. you can't use many low code platforms as an output from LLMs
| or other types of models (yet).
|
| Rails became less relevant because Ruby is dynamically typed, and
| this poses a challenge for LLMs due to hallucinations. You don't
| want to find out at runtime what things were complete bs from the
| model. Static typing isn't a panacea to hallucinations but it's a
| significant enough advantage, especially against such a dynamic
| language as Ruby. Even mere mortals struggle to understand the
| magic in meta programming DRY golf that many in the Ruby world
| have chosen to embrace.
|
| EDIT: Any down voters care to explain why you disagree?
| bravura wrote:
| What are the best static languages + frameworks for shipping
| CRUD web apps?
| dallasg3 wrote:
| ASP.NET and C#
| jameslk wrote:
| This is going to be largely dependent on your needs, but a
| factor I would consider if you're using LLMs for coding is
| which models have been trained the most on which languages.
| The more a model has been trained on a particular language,
| the less it will hallucinate
| xrd wrote:
| I got stuck when he said he wrote a lambda function for the no-
| code project. How did a lambda function get categorized as no-
| code? </snark>
|
| (I think I'm aligning with his point in the article. No-code
| really does not offer much long term. And, IMHO, no-code will
| never truly be no-code, so why not start with "Yes! to code!" and
| build from there)
___________________________________________________________________
(page generated 2024-12-01 23:00 UTC)