51–60 of 249 posts
Better headline: The framework you know intimately is better low code than low code. What programmer “believes” in “low code” solutions?
Sometimes the thing really is just the thing. The real thing is plenty of low code systems are just garbage. But Salesforce is the size it is because it's a successful "low code" system.
Both low code and Rails have become a lot less relevant since LLM assisted coding became the norm. Low code became less relevant because 1. LLMs solved many of the problems low code solves with better control over the output, and 2. you can’t use many low code platforms as an output from LLMs or other types of models (yet). Rails became less relevant because Ruby is dynamically typed, and this poses a challenge for L…
I’m not sold on the importance of static typing though. I’ve had great results with Ruby and Python with 4o, o1, and to a limited degree Copilot.
One of the biggest benefits of Ruby is how simple testing is. The language is so dynamic that mocking/stubbing and intercepting or whatever is dead simple stupid.
So the “static types prevent you using LLM hallucinations” does not hold for me. I’m going to write tests covering the method (which the LLM will probably help with), and I’m going to get an undefined method error.
Both low code and Rails have become a lot less relevant since LLM assisted coding became the norm. Low code became less relevant because 1. LLMs solved many of the problems low code solves with better control over the output, and 2. you can’t use many low code platforms as an output from LLMs or other types of models (yet). Rails became less relevant because Ruby is dynamically typed, and this poses a challenge for L…
What are the best static languages + frameworks for shipping CRUD web apps?
Better headline: The framework you know intimately is better low code than low code. What programmer “believes” in “low code” solutions?
Sufficiently advanced "low code" is indistinguishable from a framework or a library. The main difference in practice is that most software that markets itself as "low code" obscures how it works and tries to lock you in to charge rent. Though to be fair, there is generally not much of a market for proprietary/non-OSS libraries and frameworks anymore, so if you want to monetize your library/framework low-code (or an A…
In my view there are certain aspects of app building that's hard. Some of it is in code, some of it is in design, some of it is in domain modeling. Every once and awhile you get stuck and your low-code solution is suddenly paralyzed at that one point. ChatGPT unblocks you until you REALLY need a programmer.
Low or no code did not make sense until ChatGPT.
Earlier quoted context omitted.
Sufficiently advanced "low code" is indistinguishable from a framework or a library. The main difference in practice is that most software that markets itself as "low code" obscures how it works and tries to lock you in to charge rent. Though to be fair, there is generally not much of a market for proprietary/non-OSS libraries and frameworks anymore, so if you want to monetize your library/framework low-code (or an A…
This makes me think about Microsoft Access and why it never took off. It helps people create databases, forms, and reports. One might call it a no code solution as opposed to merely a low code solution. There are a lot of businesses that's ostensibly in the right place for Microsoft Access. In my view there are certain aspects of app building that's hard. Some of it is in code, some of it is in design, some of it is…
Then the client-server world dominated the desktop, plus we needed automated backups and source control and tests and scalability and auditing and hosting and security and other really important things that never properly made there way into Access. Presumably Microsoft didn't want to cannabilize SQL Server sales and chose not to invest in those things that would have actually made it an MVP for building home-grown apps.
Earlier quoted context omitted.
Sufficiently advanced "low code" is indistinguishable from a framework or a library. The main difference in practice is that most software that markets itself as "low code" obscures how it works and tries to lock you in to charge rent. Though to be fair, there is generally not much of a market for proprietary/non-OSS libraries and frameworks anymore, so if you want to monetize your library/framework low-code (or an A…
This makes me think about Microsoft Access and why it never took off. It helps people create databases, forms, and reports. One might call it a no code solution as opposed to merely a low code solution. There are a lot of businesses that's ostensibly in the right place for Microsoft Access. In my view there are certain aspects of app building that's hard. Some of it is in code, some of it is in design, some of it is…
I'd argue that it was Cloud and improved monetization opportunities rather than ChatGPT which made the current iteration of low/no-code more popular, although ChatGPT certainly helps (I'd argue that past a certain level of complexity/code sized, LLMs also stop working properly). Most low/no-code tools include hosting, which is a must for anything meant to be served on the Internet, and before public cloud took off, this was a lot more complicated to offer for free or a low-cost. There's also a much bigger market for SaaS and it's easy to take payments over the Internet now, which incentivizes semi-technical to build software to be served over the Internet rather than their desktop (and also makes it easier to build the low/no-code tools themselves).
> until you REALLY need a programmer
This is the thing I was getting at, there are a lot of people who know how to program but are not super-skilled at it, and I think a lot of software engineers don't get this. Think back to when you were just learning to program and how frustrating it probably was to do "basic" things like set up your dev environment or ship a website for the first time. For the people using low-code, it's not that they can't do these things, it's that they'd have to spend a lot of time looking things up and learning how do it, which is a major time investment (and frankly require a lot of persistence/patience which I think professional SWEs self-select for, because the learning SWE learning curve is brutal for most people) that they'd rather not make. You can argue that past a certain degree of complexity that the investment is worth it, but in many cases it probably isn't, and in others it's possible they'd not have made it to the point of outgrowing low-code at all if they had to do everything from scratch.
It's not much different from how we as programmers use things like Cloudflare or AWS Lambda. Could we run and manage our own DNS or scaling? If we really need to learn it, we probably could if we set our minds to it. Is it possible we could outgrow those tools if we start on them? Definitely. But even when we know how to implement our own scaling or DNS we might still reach for these tools just because they're so convenient to get something working quickly, and most of the time we don't outgrow them anyway. Low-code is pretty much the same thing except it has a lower technical barrier to entry (eg you don't need to know how building/deploying software works) and often is easier to outgrow.
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 app version of an existing site that’s close to templates)
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.
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…