191–200 of 249 posts
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 has types.
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?
Or, you could use Elixir/Phoenix, which has Flame. *hint hint*
Have you used or seen it used successfully?
Just to learn from, not to knock it down.
Earlier quoted context omitted.
Ruby has types.
In runtime. Basically you lose most of the benefits.
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 totally disagree. I think not having static types is a drag on productivity and maintainability. I have to work with both Kotlin and Ruby codebases, and the Ruby ones are always a nightmare whenever you need to make a change deep within the application's core, even though the Ruby one has more extensive tests. The idea that test coverage is a replacement for static types is nonsensical. I won't insult your intellig…
And because tests do not test the detailed shape of inputs and output it becomes easier to try out a quick refactor of your code later, without having to change a zillion signatures just to experiment a little. Agility matters.
It would be nice to get a brief definition of "low code." Otherwise great article. I've found myself using "low code" frameworks when they setup my environment for me and can generate the code files. Key example was a Minecraft mod maker. Within a minute I was fed up with the scratch style programming, but it had all the Java build stuff ready for me to just edit the files myself. No setting up gradle or anything.
Earlier quoted context omitted.
Right software, wrong company. Tensing appears to be a FME reseller and consultant. https://www.safe.com is the company that makes FME. While they started in the GIS world, and this is very much where their roots and core user base is, they've expanded greatly over the past few years into becoming a more general automation, data processing and ETL tool.
Ah, cool. Thanks. This must be for serious industry w/ deep pockets. There's not even a sign up link for individuals.
For what it's worth I seem to recall base licenses started at roughly $3500 per user for the desktop version of their software last time they had a price list.
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…
Your critique here isn’t even a critique of Ruby in these use cases, it’s a critique of any dynamically typed language.
The Ruby functionality I mentioned could easily bail you out in this situation by allowing you to monkey patch the redis gem to restore the old functionality until you were ready to get around to fixing it in your codebase or until you determined that the other dependent gems had been updated.
If anything, this is a great example of exactly my point about the flexibility of Ruby.
When you try to replace an entire language and multiple libraries with visual editor, you end up with something really complex, and often beyond your user's abilities to learn with the limited time/attention they have.