201–210 of 249 posts
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).
Earlier quoted context omitted.
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…
Microsoft Access definitely took off. It was certainly more popular than the new crop of no-code/low-code platforms we have today. In the late-90s and early 2000s almost every large company seems to have had Access applications running in several different corners of the business. The reason Access eventually died off is that it wasn't designed as a multi-user database. You could run Access on a network file share bu…
Both your comment and a sibling's mention features that Access either didn't have or didn't do well. However, there were low-code/scripting workarounds for all of these, which were in fact used in many places. It was scalable if you were just knowledgeable and persistent enough to keep chasing your goals. In addition, the backend didn't have to be SQL Server, it could just be another Access database.
I myself created a 'sharded' Access-only implementation (admittedly a fairly simplistic one) that supported over 300 concurrent users. The trick was to keep record locking to a minimum by training users to click a 'save record' button when they were done filling out a form (which defaulted to an offline state)-- all the data was then uploaded to the central database in a few milliseconds, and the connection was immediately closed. Kind of mimicking old webforms. It worked.
> IT programmers invariably cursed the buggy hack of an application they had to maintain
This was really the biggest problem. Only apps designed by people who were pretty good at what they were doing avoided this.
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…
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.
...
Earlier quoted context omitted.
So we're not losing our jobs?
Maybe long term we will lose our jobs but medium term there will be huge demand for people who can clean up the mess which was created by people who used AI to generate code without understanding what they did.
Earlier quoted context omitted.
The second coming of Excel, basically.
Shhhhhhhh. Do you have any idea how much I made in Fintech converting spreadsheets that'd exceeded the TA's ability to hack/keep it all in their head and/or quit? Favourite included a single cell that had, I am not kidding, something like 150+ nested if statements.. and there was a dateTime bug in it somewhere :D A friend did very well positioning himself as a data engineering consultant that could come in and quickl…
Yay! for non-deterministic financial modeling.
Also was really fun trying to explain to the folks who hired me why I couldnt get the results they wanted to see.
[1] https://support.microsoft.com/en-us/office/remove-or-allow-a...
I never understood the "low code" microbubble that was being inflated. We went through that era already. We called them RAD tools, and they targeted the same sort of strange, mythical end user profile. Someone so technically capable and apt that they could navigate a dizzying domain of deeply buried checkboxes, property fields, and sprawling relationships & side-effects, but who was also simultaneously unable to unde…
RAD is a broadly used term, but tools like Delphi were good at it and not restricted. You could build anything, but the dream of dragging and dropping little boxes and filling properties to build applications with the client and having, possibly another team, building other little boxes to satisfy the features you couldn't deliver, was a successful way of doing things. I would say especially in modern day guy in some…
Earlier quoted context omitted.
Maybe long term we will lose our jobs but medium term there will be huge demand for people who can clean up the mess which was created by people who used AI to generate code without understanding what they did.
The only question is: does anyone want to do that job (and I doubt that the "maintenance" job will be better paid than the job for originally writing the code)?
Most backend, integrations, automations require some degree of business logic, which requires algorithmic thinking, and this in turns requires engineers - there aren't many people who 'think algorithmically' and can't code. Engineers, in turn, hate low code frameworks, as they are useless on the CV and annoying to work with for reasons mentioned by others here. Proprietary s*ht tech that always, inevitably, leads to custom code.
And, it's expensive. We had mulesoft, outsystems, boomi and replaced it all with general purpose stuff shaving approx. 9M/yr in license costs. We have lost no velocity, and the great thing about the alternative (in our case: simply standardizing the toolset and going with GCP 'serverless' stack) is that its super easy to find devs who will willingly work on that. That hasn't been our experience with the low code frameworks.
Earlier quoted context omitted.
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…
Good tests do indeed not test the detailed shape of inputs and outputs, they test the system end to end. And they should be cheap to run, so you run them after every change. As soon as someone mistypes jobId the test will break and you will know where to look. If that would slip through then your tests simply aren't good enough. And because tests do not test the detailed shape of inputs and output it becomes easier t…
You misunderstood my point about the `job`/`jobId`, though. It would be correctly typed, and wouldn't break anything. But it would not be immediately clear for a developer working on that code in the future if it was an instance of Job or the ID of a job, and there would be no type information that immediately makes that clear.
I don't feel like the point you are making with regards to changing the signatures is true, either. If you're changing the shape of some data structure, or adding/removing parameters, then you would also have to make those changes in a dynamically typed language, it's only when you're changing the types of the parameters that you have to make a change, but that's really not that big of a deal, since your development environment should helpfully point out the places you need to update as you change them. I value code that's easy to makes changes in, but I value code that someone else can quickly pick up more.