Live data from Hacker News

Rails is better low code than low code

radanskoric.com

61–70 of 249 posts

Re: Rails is better low code than low code

#61

I am not a rails dev but have looked into it for some side projects that I am considering. IMO, I think it hits an excellent balance between rolling-your-own framework and no-framework-low-code. Rails itself handles so much configuration and wiring up so you that most of the code you do have to write is business logic. Lambda functions and firebase are convenient and compelling but come with their own tradeoffs that…

I think Rails is good for a consultant who wants to pump out a lot of relatively generic apps. You pay a constant upfront cost to learn the Rails magic and the conventions, and once you know that stuff, it makes greenfield development faster.

If you're doing a single big project, Rails is less attractive. The upfront cost is amortized over just one project, and the magic makes it a bit harder to stray from the beaten path when you need that.

Re: Rails is better low code than low code

#62
post #20
post #14

Earlier quoted context omitted.

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.

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

Matlab / Simulink will doubtlessly have a very long tail, but is being overtaken by Python. For one thing, programming is gaining ground in areas that have no established loyalty to Matlab, and those are growing areas. Such as the life sciences. For another, a certain fraction of students want to test the waters and see if they can explore software development as a career option. Python is more relevant to that option than Matlab.

But Simulink does continue to rule its own roost. I think the users see themselves more as engineers than as software developers. And engineers are more inured to using awkward tools.

Re: Rails is better low code than low code

#63

No code is easy to get started but difficult to customize. Code is a pain to set up but easy to modify. It really depends how much flexibility you need: if you have to experiment, change on the fly, possibly pivot then the initial investment is usually justified with code. If your requirements are fixed and fit within the existing functionality then a no code platform might be best (for example if you’re building an…

> Code is a pain to set up but easy to modify.

How I wish this was true. Code is a joy to set up using the new shiny tech and people get promoted before the pain to modify comes bite them.

Re: Rails is better low code than low code

#64

Better headline: The framework you know intimately is better low code than low code. What programmer “believes” in “low code” solutions?

You can get really far with Make.com

It handless authentication, storing if auth tokens, can run periodic jobs without managing any infra.

Its great.

Re: Rails is better low code than low code

#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 tree in order to reach the moon". You'll will very quickly run out of tree and further progress becomes almost impossible.

To a lesser extent the same thing also occurs with web development frameworks, but the limits are less constraining and there are often mechanisms that allow you integrate your own code, that implements whatever it is that the framework doesn't provide.

Low code, frameworks, and "build it totally from scratch", can all be a valid solutions, but the right choice often depends on a bunch of specific considerations (technology, user & quality expectations, organizational capabilities & constraints, etc.)

My recommendation is to keep an open mind about alternative technologies and approaches, and to pick solutions that are appropriate for the environment in which they will be developed, extended and operated. And that requires experience, which you normally don't have in the early phase of your career (e.g. good judgement comes from experience, and experience comes from bad judgement)

Re: Rails is better low code than low code

#67
post #3

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.

Somewhat of a tangent: As much as us engineers hate it, I consider the fact that Excel monstrosities are commonplace high praise for the product. Being hated by engineers because your product is so common is exactly where you want to be (double points if you stir up some consulting/certification for migrating to actual solutions).

Re: Rails is better low code than low code

#70
post #3

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.

I'll never understand why more devs don't learn Excel. Yeah, it's ugly. It's also the only thing you know you can use to develop a tool, slap one file into an email, send it to whoever needs the tool, and they'll immediately know exactly how to open it and use it. No 5-step lists of instructions, no dependency hell, no need to subvert the IT department. Excel is the lowest-friction platform for developing internal to…

We use sheets all the time at work for all sorts of processes, essentially an internal tool. But it doesn't really even need code, the human is the code. I had to strongly suggest to some of our TPMs and actually a principal in the last year that no they didn't need a tool, they just needed a spreadsheet. But this is so low code that people likely don't even think of it as a low code solution, it's just a spreadsheet.

That said other than managing and sorting lists of work to do, I break the limits on sheets and excel all the time so for anything with customer scale data I can't use it.

Post reply on HN