Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails is better low code than low code

radanskoric.com

Post reply on HN
Print view View original

141–150 of 249 posts

Re: Rails is better low code than low code

#141

Post by speleding »

Gigachad wrote: post #91
brightball wrote: post #80

Earlier quoted context omitted.

One of the perks of Rails is that Ruby itself makes it more compelling. When you need to get to something that the framework doesn’t expose, Ruby makes it easy to get to it without having to rewrite the framework, extend a class and replace it in multiple places or fork it just to use your modification. This applies to the entire gem ecosystem too. Over the years this ability has saved me numerous headaches with only…

Ruby is my least favorite part of Rails by far. The lack of type checking makes every single gem and rails update extremely dangerous in ways that are incredibly difficult to predict. For example the redis gem updated to return an int from exists() instead of a bool like it did before. This doesn’t raise any exceptions because all ints work in if statements. They just always return true. Silently breaking all of the…

I agree that it's very bad they broke the exists() behaviour in a point release by changing the return value from a boolean to an integer. But I think strong typing is not the answer. It's a drag on productivity and I can think of several other ways they could have broken the user space API that would not have been picked up by strong typing. You really need good test coverage, and ruby/rails makes that easy.

If you have great test coverage then strong types are superflous, if strong types help you then your tests are not good enough.

Re: Rails is better low code than low code

#142

Post by qsort »

devjab wrote: post #127
ahodgkinson wrote: post #66

Low code initially works quite well until you hit the limits of the low-code framework. If you just need a throw-away proof of concept, or a personal utility, or the like, low-code solutions can be quite efficient. However, implementing anything significant that's expected to be extended and improved, particularly when there are users that request changes, improvements and new features, low-code "is like climbing a t…

I’ve spend a few decades in non-tech enterprise including 7 years in the public sector, and I’ve never seen a low-code solution work at all. Even extremely simple automation flows require at least some degree of software engineering. Looping isn’t intuitive at all, he’ll even conditions aren’t. What has completely changed the field is LLMs. We now have employees of every sort building small Python scripts which actua…

The second coming of Excel, basically.

Re: Rails is better low code than low code

#143

Post by bigfatkitten »

phartenfeller wrote: post #124

Even though it is Oracle, Oracle APEX is exceptional at creating CRUD applications. The main benefit to other low code tools is that it doesn't want eliminate code but just the repetitive UI code. It still expects you to have skills in database development so you can achieve everything but generating a Report, Grid or Form from a SQL query takes as long as you need to write the query. And everything is customizable a…

A former employer of mine banned Microsoft Access, because they didn't want critical business functions running from random desktop machines. I imagine they'd take the same view today to home made LLM-generated Rails apps.

They instead said "if you need to write your own little CRUD apps, use our APEX instance that we support and have backups for."

Re: Rails is better low code than low code

#144

Post by Tarks »

qsort wrote: post #142
devjab wrote: post #127

Earlier quoted context omitted.

I’ve spend a few decades in non-tech enterprise including 7 years in the public sector, and I’ve never seen a low-code solution work at all. Even extremely simple automation flows require at least some degree of software engineering. Looping isn’t intuitive at all, he’ll even conditions aren’t. What has completely changed the field is LLMs. We now have employees of every sort building small Python scripts which actua…

The second coming of Excel, basically.

Shhhhhhhh.

Do you have any idea how much I made in Fintech converting spreadsheets that'd exceeded the TA's ability to hack/keep it all in their head and/or quit?

Favourite included a single cell that had, I am not kidding, something like 150+ nested if statements.. and there was a dateTime bug in it somewhere :D

A friend did very well positioning himself as a data engineering consultant that could come in and quickly improve poorly thrown together data pipelines, wonder what the equivalent is for these :)

Re: Rails is better low code than low code

#145

Post by ec109685 »

daelon wrote: post #35
Klonoar wrote: post #31

Earlier quoted context omitted.

“Ejecting” is the key term here I think, or at least the one I’ve always used - for when you need to shed the handlebars for more control.

"Escape Hatch" is also commonly used.

Escape hatch feels like the lambda the author talks about. Ejecting is abandoning the generator and owning the code from that point on completely.

Re: Rails is better low code than low code

#146

Post by egeozcan »

devjab wrote: post #127
ahodgkinson wrote: post #66

Low code initially works quite well until you hit the limits of the low-code framework. If you just need a throw-away proof of concept, or a personal utility, or the like, low-code solutions can be quite efficient. However, implementing anything significant that's expected to be extended and improved, particularly when there are users that request changes, improvements and new features, low-code "is like climbing a t…

I’ve spend a few decades in non-tech enterprise including 7 years in the public sector, and I’ve never seen a low-code solution work at all. Even extremely simple automation flows require at least some degree of software engineering. Looping isn’t intuitive at all, he’ll even conditions aren’t. What has completely changed the field is LLMs. We now have employees of every sort building small Python scripts which actua…

Those scripts work, until they don't and the people who generated them cannot even ask the right questions to an LLM, and people who can actually maintain them get overwhelmed by the side-quests of keeping them in order, because everything that gets some use become a dependency for the business.

Re: Rails is better low code than low code

#147

Post by raffraffraff »

rqtwteye wrote: post #13
simplemindedbot wrote: post #4

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

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

Unless you're a regular python user who has already paid the high cost of installing learning to use the whole mess of tools, the break even point exists. There are times when I do the 100+ lines of shell to avoid python. How often do python apps just stop working on me for no apparent reason? (Yesterday I tried to launch puddletag and had to nuke it and reinstall). But for me the big thing is that using "curl | jq | awk" is easy, fast and terse. If I can get away with that I'll choose it every time.

Re: Rails is better low code than low code

#148

Post by jstummbillig »

ahodgkinson wrote: post #66

Low code initially works quite well until you hit the limits of the low-code framework. If you just need a throw-away proof of concept, or a personal utility, or the like, low-code solutions can be quite efficient. However, implementing anything significant that's expected to be extended and improved, particularly when there are users that request changes, improvements and new features, low-code "is like climbing a t…

Low code tools are fantastic for people with unambitious software goals (not to be confused with unambitious company goals). A lot of burden is lifted off of the tool builder, simply, because there is so much stuff that has been decided for you and therefore a lot of things you can not do.

But you have to really accept this limitation as a feature, just like you need to accept that inventing pieces or moves is not an option when you get frustrated during a match of chess. As soon as you fall into the coder mindset of "If only I could go one level down", you immediately switch into having 0 upside while having all of the downside. You fight the tool and then there's a ton of things that would in fact be simpler if you just wrote it starting from the correct level.

I would argue, just as with coding, this is mostly a matter of discipline. Having boundaries is part of the real world problem solving. Being able to work within them is a skill.

Re: Rails is better low code than low code

#150

Post by exe34 »

potamic wrote: post #118
Gigachad wrote: post #91

Earlier quoted context omitted.

Ruby is my least favorite part of Rails by far. The lack of type checking makes every single gem and rails update extremely dangerous in ways that are incredibly difficult to predict. For example the redis gem updated to return an int from exists() instead of a bool like it did before. This doesn’t raise any exceptions because all ints work in if statements. They just always return true. Silently breaking all of the…

Anyone maintaining software in the public domain needs to understand Torvald's first rule of kernel development. YOU DO NOT BREAK USERSPACE! Seriously, how hard is it to understand? The collective impact across thousands of users will always be greater than any overhead in versioning. It's equivalent to willingly shipping a bug, and you would never do that, would you? Arguments about keeping the interface simple are…

> Anyone maintaining software in the public domain needs to understand Torvald's first rule of kernel development. YOU DO NOT BREAK USERSPACE!

That's why they offer refunds!

Post reply on HN