Earlier quoted context omitted.
What are the best static languages + frameworks for shipping CRUD web apps?
ASP.NET and C#
Rails is better low code than low code
231–240 of 249 posts
Re: Rails is better low code than low code
#232Earlier 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.
Re: Rails is better low code than low code
#233Earlier 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…
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
#234Earlier 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).
Re: Rails is better low code than low code
#235Earlier 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.
Re: Rails is better low code than low code
#236Earlier 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".
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
#237Earlier 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…
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
#238Or, 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.
Re: Rails is better low code than low code
#239Earlier 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…
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
#240Earlier 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?