Live data from Hacker News

Rails is better low code than low code

radanskoric.com

231–240 of 249 posts

Re: Rails is better low code than low code

#231
post #16

Earlier quoted context omitted.

What are the best static languages + frameworks for shipping CRUD web apps?

ASP.NET and C#

Not to forget Entity Framework Core. It has become one of the best (if not the best) ORM over the years. Bit of a learning curve, but for CRUD ideal.

Re: Rails is better low code than low code

#232
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…

I currently work in the public sector in the UK and my experience is different. I see quite a lot of PowerAutomate going on to automate tasks and to create simple SharePoint apps.

It’s been some years since I left the public service, PowerAutomate didn’t really exist back then. It may be an exception to what I said, I do know my current organisation had a few of those Apps running. I wasn’t much involved in the process, but they were basically discovered because of their cost and later shut down. Since I know basically nothing about this process, the PowerApps would have been made by non-developers since I know all the developers in house. I’ll assume they also must have worked.

Re: Rails is better low code than low code

#233

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…

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…

I'm curious to hear why you don't like strong types, because I can't imagine not using types.

My day job involves working on a PHP app that's been around since the 5.x days. So it's a mixture of "new code" which has typehints everywhere (PHP nomenclature for runtime type-checking, but static analyzers can also read the signatures and alert you before runtime, which is the real benefit IMO) and "old code" where everything is an array, but to figure out what's in the array you've been passed, you have to look at the 3 functions that call the function you're looking at, and even then sometimes you have to back up 2 or 3 steps up the stack to find where the array is created, and even then you're not 100% sure if that `userEmail` member is present all the time or only in certain circumstances.

With strong types, we pass a UserModel object, and everyone immediately knows what they can and cannot do with it.

I remember in college trying to write some Selenium scripts in Python to do some scraping, and my biggest frustration was not being able to identify the return type of anything. The language wouldn't tell me, the built-in python IDE (IDLE?) wouldn't tell me, so the best I could come up with was something like `print(typeof(x))` (or maybe it was a function to print the properties/methods? it's been a while, I forget) every time I called a new function and running the tool, which was a painful experience to say the least. A few months later I ended up doing something similar but in C# and the difference in productivity was night-and-day.

Re: Rails is better low code than low code

#234
post #53
post #16

Earlier quoted context omitted.

What are the best static languages + frameworks for shipping CRUD web apps?

Wicket is the best library I've ever used. Not just best webapp library or best Java library, the best library anywhere. If server-side rendering is an option then I'd absolutely use that (possibly from Scala).

Happy to see Wicket mentioned. It is still pleasure to work with, even now.

Re: Rails is better low code than low code

#235
post #53

Earlier quoted context omitted.

Wicket is the best library I've ever used. Not just best webapp library or best Java library, the best library anywhere. If server-side rendering is an option then I'd absolutely use that (possibly from Scala).

Wicket sounds like a throwback to JSF. No thanks.

Yes, sounds like, but it isn't. There is no logic inside html templates apart from wicket-specific component binding tags and everything happens in Java.

Re: Rails is better low code than low code

#236
post #214
post #152

Earlier quoted context omitted.

Power Apps https://www.microsoft.com/en-us/power-platform/products/powe... Uses excel and excel like formulas for stuff. Not bad for power users that can/want hack their app together.

PowerApps would not catch me endorsing it for anything beyond a year of use, however. Either a replacement needs to be on its way, or it's for a project with a defined end date. Otherwise, "there's nothing more permanent than a temporary solution".

I see low code tools are suitable for power users (citizen developer) and less for programmers (pro developer).

Like a farmer hacking together some stuff for their needs instead of waiting for official solution.

Power users automate their way to gain efficiency when programmers are busy doing their stuff.

Re: Rails is better low code than low code

#237

Earlier quoted context omitted.

Python is also open source.

Indeed, and that's an attraction even despite Matlab being effectively "free" due to generous academic site licenses. But people are catching on that open source means more than "free" as in beer. I think it has also encouraged what we've seen, the flourishing ecosystem of libraries, tools, tutorials, etc., that really make Python what is. People don't want to pour their heart and soul into something that somebody el…

> People don't want to pour their heart and soul into something that somebody else owns.

Plus the soul of academia is openess and sharing (perhaps trending towards closed IP and privatisation).

Re: Rails is better low code than low code

#238
post #75

Or, you could use Elixir/Phoenix, which has Flame. *hint hint*

I've done a lot in Rails and a bit in Elixir/Phoenix. I haven't dipped my toes into Flame yet, although I did like the presentation. Have you used or seen it used successfully? Just to learn from, not to knock it down.

I haven't personally used Flame, but I have extensively used Elixir and Phoenix and contend that, even without Flame, they compete well with so-called "No Code" solutions (like the article contends with Ruby/RoR).

Re: Rails is better low code than low code

#239

Earlier quoted context omitted.

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…

I'm curious to hear why you don't like strong types, because I can't imagine not using types. My day job involves working on a PHP app that's been around since the 5.x days. So it's a mixture of "new code" which has typehints everywhere (PHP nomenclature for runtime type-checking, but static analyzers can also read the signatures and alert you before runtime, which is the real benefit IMO) and "old code" where everyt…

In rails or elsewhere in our code base, if I'm ever unsure what a function does or what it returns then I just jump to the function definition and read it, a single key stroke in my IDE.

Now I need to fix a small bug in a library. Rather than wait for the library to be fixed I can monkey patch the fix into the library until it's fixed upstream. Trying to do that with a strongly typed language, you typically need to jump through all kind of hoops or end up fixing the problem outside your library or put some shim in between the broken library and your code. And then once the fixed library comes out you need to undo the code fixes on your side rather than just delete the monkey patch.

Sure I understand the benefits you list, but for me the effort put into strong typing, typing the stuff, changing it each time, just doesn't seem a worthwhile trade off because it's very rare for me to encounter a problem caused by a wrong type. Perhaps I would feel differently if I had to work on a poor code base with many people, but I don't.

Re: Rails is better low code than low code

#240

Earlier quoted context omitted.

I’ve worked on rails apps for a while now and on previous jobs it wasn’t so bad, but those were smaller apps. At the current company, almost every update manages to slip something through CI that blows up on production. Even with 30,000 rspec tests and tons of cypress tests. The CI is set up to raise exceptions on warnings, but I think it only applies to warnings raised by rails. I guess rails works alright at the st…

30,000+ tests and it can't detect breaking changes?

In this case no because the broken code was in another gem (sidekiq) using the redis gem. Our CI does not run the unit tests for every library we import. Only our own.
Post reply on HN