Everything Is Just Functions: 1 week with David Beazley and SICP

> Everything Is Just Functions...

I'd iterate on that and say: everything is just languages and dialogues, with functions being one component of them. Over time, we’ve evolved from machine languages to higher-level ones, but most popular languages today still focus on the "how" rather than the "what".

Programming paradigms, even those like functional and logic programming, requires the "how". My rant is this: the next major iteration(s) in programming languages should shift focus to the "what". By abstracting away the "how", we can reach a higher-order approach that emphasizes intent and outcomes over implementation details.

I don't want to constrain this idea to Z3, LLMs, or low/no-code platforms, but rather to emphasize the spirit of the "what". It’s about enabling a mindset and tools that prioritize defining the goal, not the mechanics.

I know this contradicts our work as software engineers where we thrive on the "how", but maybe that’s the point. By letting go of some of the control and complexity, we might unlock entirely new ways to build systems and solve problems.

If I should be plain realistic, I'd say that in the middle, we need to evolve by mixing both worlds while keeping our eyes on a new horizon.

> programming languages should shift focus to the "what"

SQL is an example of a language that is at least somewhat like that.

    SELECT foo WHERE bar = baz

Doesn't really say "how" to do that, it only defines what you want.

isn't that what declarative programming frameworks do already ?

Yeah, but a new generation is coming of age, whose teachers only learned these ideas through books, not experience. They are rediscovering computer science one blog post or tweet at a time, because books and classes are obsolete.

Incorrect: you need to know the "how" to create more complex and optimal queries. Your example is like saying, in Python, you just need to write print("Hello World!") to print something.

They don't do it "already" but are one of the approaches taken. If you build state of the art web UI/UX you know that it is not just dragging and dropping objects on the screen while it is perfectly possible to build a tool like this.

That’s every programming language abstraction. All of them break when you get a fair amount of complexity or performance requirements.

Imagine this concrete example: you are the best developer in the world in some specific area(s), except for UX/UI. If you wanted to create a relatively simple yet secure site with user authentication, even if described declaratively as “create a secure site with user authentication,” it would still take a significant amount of time to learn technologies like React and put everything in place. There are zillions of development teams doing the same work around the world.

I wouldn't say that since SQL was an improvement over previous ways to query data which were more concrete, like writing C code to get what you need. As such we are on a level of abstraction higher. Thus SQL specifies the "what", not the "how", with respect to those previous methods. However in complex queries, since we are constrained by the relational model (PK/FK), we may have a feeling of having to specify too much details.

That's why I said "somewhat."

You aren't telling the database how to get those results from the files on the disk. You are telling it what values you want, matching what conditions, and (in the case of joins) what related data you want. If you want an aggregation grouped by some criteria you say what values you want summed (or averaged, etc.) and what the grouping criteria are, but not how to do it.

Not a perfect example and it breaks entirely if you get into stuff like looping over a cursor but it is why SQL is usually called a declarative language.

Then this programming paradigm cannot interact with one another. If I have subroutine that does X and another that does Y. How do I compose them? Composability is basically saying, "You can then do Z using X and Y" which is already explaining how its done. So you end up with a language where no subroutine can reference another, because that would constitute how.

No, it is complementary. For example, the quicksort algorithm/function you are indirectly using is available in just at another level of abstraction. Clearly we are far from writing algorithms using a "what" approach. It can even be impossible but I wrote about this concept because we have a codebase of algorithms and higher level frameworks that enable us to focus on the "what". I can never imagine a working paradigm like this decades ago.