Live data from Hacker News

Rails is better low code than low code

radanskoric.com

101–110 of 249 posts

Re: Rails is better low code than low code

#101

I never understood the "low code" microbubble that was being inflated. We went through that era already. We called them RAD tools, and they targeted the same sort of strange, mythical end user profile. Someone so technically capable and apt that they could navigate a dizzying domain of deeply buried checkboxes, property fields, and sprawling relationships & side-effects, but who was also simultaneously unable to unde…

I think you're taking the intent of "low-code" too literal, or have not worked in an organization of sufficient size for its value proposition to be evident. It's not to solve a solutioning problem; it's to solve an organizational one.

While any "low-code" is marketed as a WYSWG, business friendly solution platform, what it actually is is a way for the business to get access to capabilities IT otherwise gatekeeps as "domain expertise", but fails to actually produce with.

Case-and-point: IT quotes an organization $75 million for 30 projects in fiscal year 20nn. By 20nn+1 IT has completed 5 projects for $75 million. Sick. Org gets "low-code" on their own dime for $1 million, hires a couple "business systems analyst" for a little less, and in 20nn+1.5 has completed 25 projects. In 20nn+3 IT looks incompetent, gets pissed, cries foul, the "business systems analyst" are ingested into IT and taught Java and CRUD circa 1998, and the life-cycle continues.

Re: Rails is better low code than low code

#102
people like to shit on document databases - but man oh man - the expressivity you get working with document databases combined with Ruby is unmatched. I know someone is gonna reply all you need is postgres - but yeah jsonb queries don't match mongo queries. & after all - most of the places I have worked the database writes / queries hit one or two tables and work loads got migrated to dynamodb. that includes socia media ingestion, iot streams and metasearch.

yeah if you need kimball style queries i.e olap then yeah use postgres with rails etc

Re: Rails is better low code than low code

#103

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 initially works quite well until you hit the limits of the low-code framework.

I wrote this a while ago. May be the future is a No Code tool with AI that generate enough of an App to allow Low Code edit with the help of AI while the whole App itself is still a full Ruby Rails App that allow Real Code modification in the future by professionals.

Re: Rails is better low code than low code

#104

I never understood the "low code" microbubble that was being inflated. We went through that era already. We called them RAD tools, and they targeted the same sort of strange, mythical end user profile. Someone so technically capable and apt that they could navigate a dizzying domain of deeply buried checkboxes, property fields, and sprawling relationships & side-effects, but who was also simultaneously unable to unde…

RAD is a broadly used term, but tools like Delphi were good at it and not restricted. You could build anything, but the dream of dragging and dropping little boxes and filling properties to build applications with the client and having, possibly another team, building other little boxes to satisfy the features you couldn't deliver, was a successful way of doing things.

I would say especially in modern day guy in some cases: I have not seen anyone happy changing modern code (nextjs or so) that has not been touched for 5 years. The 'just drop in a new component' won't work because 9 billion dependencies had updates and break everything (seems modern devs in the npm ecosystem have serious issues keeping things compatible even across minor versions); that issue was never there with delphi; you just make the change; either in code or gui. Many components I used for 2 decades to create and fix applications without the pain I feel these days. Unlike others apparently, I have no interest in actually maintaining applications: I want to make them and if no changes are needed, I don't want to update them; security fixes are meant to be compatible with what there already is, so that's just a recompile. It's not anymore though so it causes work and work costs money. It's not very nice unless you get paid by the hours then it's brilliant.

Commenting on your general use of rad tools, the rest you say i agree with. I see (i googled a bit) that things like Outsystems are RAD tools now, and yes, those are hell on earth to work with (we did a massive project with it and everyone basically thought it was terrible).

Re: Rails is better low code than low code

#105
post #84
post #6

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.

Ruby is strongly typed. Dynamic typing and inferred typing are not the same as typeless. B and Forth are examples of typeless languages.

"Strongly typed" is not a well defined term—it basically means "I'm personally comfortable with the level of guarantees offered by the language", which is a purely subjective measurement.

In context it's obvious that what OP meant is that they wouldn't want to build in a language without statically-checked types. That there are languages that provide even fewer statically-analyzable guarantees than Ruby does not make Ruby a suitable candidate.

Re: Rails is better low code than low code

#106
post #102

people like to shit on document databases - but man oh man - the expressivity you get working with document databases combined with Ruby is unmatched. I know someone is gonna reply all you need is postgres - but yeah jsonb queries don't match mongo queries. & after all - most of the places I have worked the database writes / queries hit one or two tables and work loads got migrated to dynamodb. that includes socia me…

People like to shit on mongo not so much on others as far as I have seen. They were bitten by it I guess.

I guess they are harder to grok after the initial ease of use: performance is harder to reason about; things can suddenly grind to a halt even though you 'didn't do anything different' etc.

Re: Rails is better low code than low code

#107

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…

My escape from this: https://github.com/olegantonyan/typerb

Re: Rails is better low code than low code

#108

I never understood the "low code" microbubble that was being inflated. We went through that era already. We called them RAD tools, and they targeted the same sort of strange, mythical end user profile. Someone so technically capable and apt that they could navigate a dizzying domain of deeply buried checkboxes, property fields, and sprawling relationships & side-effects, but who was also simultaneously unable to unde…

RAD is a broadly used term, but tools like Delphi were good at it and not restricted. You could build anything, but the dream of dragging and dropping little boxes and filling properties to build applications with the client and having, possibly another team, building other little boxes to satisfy the features you couldn't deliver, was a successful way of doing things. I would say especially in modern day guy in some…

Oh man, I totally forgot about the delphi IDE and the drag and drop editor for making GUIs. I only ever did encounter it in college (early 2000s) and for group projects it was really nice. Simply because it allowed you to prototype GUIs in the IDE and then instead of having to re-implement them in your markup language simply use those prototypes to build the functionality behind it.

https://i0.wp.com/blogs.embarcadero.com/wp-content/uploads/2...

It's a bit of a different perspective as you describe.

> I have not seen anyone happy changing modern code (nextjs or so) that has not been touched for 5 years.

Yeah... even if you do faithfully update dependencies it isn't straightforward. The sort of stuff I work on is mostly used internally and overall is fairly simple as far as the UI goes. So, for a while now, I have done away with most dependencies where I can and switched to vanilla JS, HTML and CSS for this sort of tooling. Not only does this help me with future maintaining of these tools, it also makes the whole development process a lot smoother as there is no building involved.

I very much realize that I am in a somewhat luxury position here as I don't do client facing applications and most of them are fairly simple. But that's also my point, all too often I see very simple single purpose applications that make use of a complete ecosystem of modern frameworks where the same can easily be achieved without them.

Re: Rails is better low code than low code

#109

I never understood the "low code" microbubble that was being inflated. We went through that era already. We called them RAD tools, and they targeted the same sort of strange, mythical end user profile. Someone so technically capable and apt that they could navigate a dizzying domain of deeply buried checkboxes, property fields, and sprawling relationships & side-effects, but who was also simultaneously unable to unde…

Well said. You are exactly right. Low Code stuff is usually invented by people with a specific set of criteria that they realize can be generalized, and defined by a GUI, but who lack enough experience to realize the entire world of possibilities can't be crammed into their model. Languages (like Python, etc) are already the most compact way to represent most things, and trying to avoid that fact just makes things ev…

You're letting perfect be the enemy of good. The low code solutions can simply have a full-code escape hatch with interop. Much like how Python can interop with C.

Re: Rails is better low code than low code

#110

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…

It's wild how all the huge successful applications written in it manage to stay alive eh
Post reply on HN