←back to thread

389 points kurinikku | 1 comments | | HN request time: 0.461s | source
Show context
wslh ◴[] No.42164921[source]
> 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.

replies(3): >>42165246 #>>42165320 #>>42169451 #
SoftTalker ◴[] No.42165246[source]
> 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.
replies(1): >>42165630 #
wslh ◴[] No.42165630[source]
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.
replies(3): >>42166090 #>>42166587 #>>42167999 #
1. SoftTalker ◴[] No.42167999[source]
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.