Code is the new no code
lumberjack.so
lumberjack.so
My observation was that apex is better positioned to take advantage of the future of AI programming tools due to being a simple Java based language with high level of abstraction.
At some point this will flip the equation and it will be easier for non-coders to manage the code than the visual graphs.
Salesforce is building AI tooling for their flow platform, but I don't think they will be competitive again the billions being invested in solving general programming / SDLC with AI
When was that? All I remember is that it might have been a good science-fiction story, or the promises of a few salesmen.
It’s at least 50% of the job for many salesman. That and convincing the ‘target’ that they have the persons best interests in mind, and it will all work out great if they just sign on the dotted line/give them the money right now.
For the moment, we're necessary middlemen. And we may even be necessary for a long time -- less for our skills at programming but for our experience in bridging the gaps between what users actually want, what they say, and what the computer can do.
But most of the things that we prize in each other aren't really that important to the customer. They just want the tool to assist with their actual task, whatever it is.
"No code" has never been anything like that. It's a buzzword that sells because that is indeed what people want, but it's fiction. Still, it's good to remember why it's such a desirable buzzword.
People have wished to do away with computer code specialists ever since they found out computers could do things for them. But what make computers useful - their ability to be very exact and to do a lot (and I mean A LOT) of very exact things very quickly is the magic.
You can't wish for very complex things done in a very exacting way but not needing to be exact yourself. You can hire people to do that for you. But thinking that you can somehow get a computer to be very fast and very exact for you without needing other people to go through the effort of being very exact about thoughts and language is just magical thinking.
Software that can make software will be more complex than the software it makes and will necessitate more people to have exact thoughts and conversations and writings, not less.
At our best, we do exactly what you say: take things that people say and make them more concrete and specific. This is something I think a lot of programmers don't realize: it is fundamentally a human job. We are "in the middle" between the people (with their vague, hazy ideas) and the computer (with its very simplistic binary model of the world).
When we think that our jobs are all about computers, we're setting ourselves up to be replaced. Not by AI, but by plain old software written once and then left there.
Funny thing is, I think in the 80s, with computers like the Commodore 64 and BASIC, anyone with some aptitude really could learn to do some programming. You didn't have higher-level concepts or much abstraction, just global variables, loops, and screen manipulation. The average person couldn't do a lot, but you could have some fun making shapes move around the screen, or write a little program to catalog your albums or something.
Ironically, as computers and languages have gotten more powerful, they've also gotten harder to program, requiring a more specialized sort of mind to understand what's going on with more abstractions packed into less code.
This should be sufficient to fuel the need for faster hardware for another few decades, especially if we integrate it with Electron.
Perhaps even integrate the LLM and a compiler into Electron so only the prompt is deployed to the users' machines and each user can get their own piece of software.
I've never been bullish on no-code. Every couple of years there is a new unicorn darling, but none of them ever reach escape veclocity. They just seem to replace each other. An unfortunate category of product where the end state is just graduation to either learning to code or hiring an engineering team.
Happy to answer questions about GenSX!
But I'm not sure about this GenSX thing. I looked at the docs briefly, but wasn't able to figure out what using JSX syntax adds over just using plain old function calls. Convenient named parameters? But you can already effectively get that in TS just by passing an object and treating its fields as parameters. There does seem to be some automatic stream handling, which might be handy.
(I suppose you could make the same criticism of React, but I think the answer is clearer there: You're gonna wind up with HTML, and JSX gives you convenient HTML syntax for making the parts.)
It turns out that react's programming model is great at constructing and executing DAGs. The resulting code is much simpler, and more expressive.
And the React's focus of composition over abstraction is 100% what you need in the LLM world. It enables sharing code across large teams by default.
When you have serializable props, outputs, and pure functions (properties of both the React and GenSX component model) then it is trivial to layer things like durable execution on top of it. Might give you an idea of what is soon to come!