31–40 of 66 posts
The second sentence ("First, you work all month, and then you give half of the money to those who didn't work.") is already so blatantly wrong and reactionary that I almost have to force myself to read on - after all, if the premise is already flawed what good can come of it?
;)
Earlier quoted context omitted.
Because drag and dropping blocks is the same difficulty as writing it down just with more steps. The difficulty isn't in writing the code, but specifying exactly what you want to do.
Yeah, I mean, you're right, it is difficult to specifically know what you want the computer/server to do. But, writing code (as text) is a lot harder for people to do, than to use graphical elements. Why I don't know, maybe it's just more daunting to get started. But people have an easier time pickup "programming" via blocks rather than text.
Earlier quoted context omitted.
It's obviously supposed to be humorous. Whether you like the joke or think it's dumb, the article isn't premised on it being true.
Jokes with false premises always struck me as bad humor. It's like Jerry Seinfeld getting up there and being like "the problem with coffee is that there's always just a litttttle hint of banana flavor. No matter what you do! Always the banana! I mean, is the guy making my coffee some sort of orangutan??"
The second sentence ("First, you work all month, and then you give half of the money to those who didn't work.") is already so blatantly wrong and reactionary that I almost have to force myself to read on - after all, if the premise is already flawed what good can come of it?
Seriously.. it wouldn't be such an aggravating statement if people didn't actually believe it. (To state the obvious, the idea of the taxes is that the money is used to pay for the roads to get you to work, for the education that provides you and your employees the skills to work, and for all the other things that allow society to function so you can work. Yes, including helping people who are looking for work, so th…
I recommend James C. Scott as relevant reading.
I've gotten sucked into this in the form of MS Power Automate, and it just seems to make everything more complicated and confusing. I spend most of my time looking for workarounds to try to get back the ability to do stuff that any programming language allows. I only learned Access and VBA about a year ago, but I tend to agree with the people who say Microsoft has broken up parts of the functionality of this reasonab…
If you want the "developer experience" (source control, some code, etc.) while also having access to the flow-based editor you should look into Azure logic apps instead.
The good part is that (as the article) says, you only need to write the code when you know the code will be used.
The bad part is that the no-code solution will break at some point. Usually because some part of the chain introduced a breaking change, or the process its modelling needs to change in a way that the solution can't handle. Then you need to replace the no-code with actual code, while under time pressure because the business is broken waiting for the new solution.
He's right - this is a useful tool, and sitting in the middle is the best place. But there are lots of people who will read this and create something completely with no-code and with no intention of replacing it with code, until it breaks and then they're in a painful place.
It's not "no code" it's "code later". It doesn't prevent the effort of coding the solution, just moves it down the line and makes it harder. The good part is that (as the article) says, you only need to write the code when you know the code will be used. The bad part is that the no-code solution will break at some point. Usually because some part of the chain introduced a breaking change, or the process its modelling…
What is harder about using a OCR app and calling the Airtable API to get the expenses compared to writing all the code to take photos, scan for text, and then upload to Airtable or even a SQL DB?
What "no code" is really about is "no figuring out the toolchain, deployment, integration with third parties, etc". For actually writing business logic, replacing code with drag and drop logic blocks is... not really helpful to anybody. But with all the crap that programmers actually spend our days dealing with removed from the picture, anybody can write their own business logic, even if they have to do it in gasp co…
It occurred to me once that for the typical front end dev, there are 4 data types being dealt with, disregarding individual chars which don't have a whole lot of use on the internet at large. Now, someone who is using a framework of a framework is going through AT LEAST 4 translations. High level framework -> low level framework -> javascript -> machine code via the runtime.
4 data types, 4 languages. Just in the UI, not even talking about the server and the database.
Perhaps the trend is a reaction to poor language and framework design...
It's not "no code" it's "code later". It doesn't prevent the effort of coding the solution, just moves it down the line and makes it harder. The good part is that (as the article) says, you only need to write the code when you know the code will be used. The bad part is that the no-code solution will break at some point. Usually because some part of the chain introduced a breaking change, or the process its modelling…
> It doesn't prevent the effort of coding the solution, just moves it down the line and makes it harder. What is harder about using a OCR app and calling the Airtable API to get the expenses compared to writing all the code to take photos, scan for text, and then upload to Airtable or even a SQL DB?
Often, it is good enough, when the no-code solution has some flaws, but not enough to justify a rewrite.
And some workflows utterly needs to be rewritten, because of various reasons (change in pricing of the provider, new feature that's not possible in no-code, bug in the no-code solution, scaling issue).