Live data from Hacker News

Rails is better low code than low code

radanskoric.com

161–170 of 249 posts

Re: Rails is better low code than low code

#161

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. If you just need a throw-away proof of concept, or a personal utility, or the like, low-code solutions can be quite efficient.

The same I'd say for dynamically typed languages (and their frameworks like Rails): initially works quite well until you hit the limits.

Once your app is big and there is a team, the efficiency dwindles. Refactoring becomes really hard. Unit test for the rescue, but they also take time to write.

Re: Rails is better low code than low code

#162

Earlier quoted context omitted.

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.

So we're not losing our jobs?

Only time can tell.

Re: Rails is better low code than low code

#163
post #150

Earlier quoted context omitted.

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!

Indeed. Let's not forget the greatest invention in history of software development, unparalleled in how it improved productivity of software developers:

  THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT
  WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
  INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
  PURPOSE AND NONINFRINGEMENT.

Re: Rails is better low code than low code

#164

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…

> The lack of type checking makes every single gem and rails update extremely dangerous in ways that are incredibly difficult to predict.

This. I found a typed-Ruby in Kotlin (OO-core with lots of FP niceties; code even looks similar to Ruby in many cases as type inference it quite good).

Kotlin + http4k (analog to Rack+Sinatra) + JTE's KTE (or kotlinx.html) + SqlDelight (or jOOQ; fuck ORMs anyway: also ActiveRecord) is a dream to work with.

I'm not sold on TypeScript. Yes it helps but it allows for very messy code.

Re: Rails is better low code than low code

#166

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…

Apex is nice, but it becomes hard to maintain larger applications.

It also makes it so easy to create opportunities for SQL injection if you don't have careful coders. And it is also a great target for DoS attacks.

Having said all this, it really is the only low code platform I would ever consider using, in spite of it being Oracle's.

Re: Rails is better low code than low code

#168
If you are asking "well we could build this in 2 hours with low-code or 8 hours with rails" - then you are not the target market for low-code. To be able to build a rails app in one day takes years of skill and education and maturity. A lot of people or organisations want to build apps but don't have that expertise.

Also, I don't see what is wrong with the outcome that at some point you have to rebuild with code. You have spent not very much time to develop a prototype that was able to get some feedback and come up with new ideas. Maybe that very revolutionary idea about the reservations app the author describes would never have imagined if they didn't have a prototype to play with?

And don't even get me started on the risks of traditional software engineering. How many projects never even got to a viable prototype because devs decided to rewrite everything in flavour-of-the-month every 3 weeks?

Re: Rails is better low code than low code

#169

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…

Low code efforts go back decades. In the eighties there was this whole movement around 4GL languages. Basically relatively simple languages around databases that enabled relatively quick development of business applications. Before that, Cobol of course was an attempt to come up with a business programming language that was nominally human readable. In the nineties we got things like Visual Basic, Delphi and a bunch of other things which again were targeting relatively inexperienced programmers. And then of course there's a long history of creating domain specific languages for all sorts of things - typically with the goal to let domain experts be able to define things. Tcl/TK is a good example for UI applications on X-windows.

Rails built on all of that. Ruby brought two useful thing to the table (well, borrowed from Lisp) which was meta programming and the ability to use its syntax to build so-called internal DSLs: domain specific languages which were just building on top of Ruby's own syntax instead of needing a new one. Rails is basically a DSL for building web based database applications with server side model view controller style UIs.

Once MVC moved mostly client side with single page javascript applications and rich mobile applications, the MVC bits and bobs became somewhat redundant. And of course the rest of it is basically a nice but otherwise unremarkable ORM framework that you can find for other languages as well. I was never that impressed with it to be honest and I'm not a big fan or ORM frameworks in general. Server side MVC is still somewhat relevant if you are into server side rendering (which reinvents what world + dog was doing twenty years ago) but otherwise not that relevant for most REST APIs.

IMHO the last two decades have been a bit unremarkable for UI development. It seems a lot of things plateaued in the nineties. The average UI projects are still fairly labor intensive for what they do; which is mostly just building a lot of form based crap to input data in some database. We had perfectly usable and relatively idiot proof visual UI builders that did that sort of thing thirty years ago. From a functional point of view, the resulting UIs more or less did the same thing. Was that great code, not necessarily. But it did the job. And most "modern" react/rails/django/whatever code isn't a whole lot better. If you discard the lipstick on a pig that is CSS, you are left with essentially the same UI components and primitives (buttons, checkboxes, text fields, etc.). We had all of those decades ago. You don't need a mustache twirling hipster web ninja to reinvent those wheels.

Re: Rails is better low code than low code

#170
post #84

Earlier quoted context omitted.

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…

> "Strongly typed" is not a well defined term

True. But it has boundaries. Strongly typed cannot be used for langs with implicit nulls. You need to do better than stock C, C++, Java or Go to be able to use the term.

Rust, Elm, Haskell, Kotlin and OCaml come to mind.

Post reply on HN