←back to thread

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

(ezzeriesa.notion.site)
389 points kurinikku | 6 comments | 17 Nov 24 15:07 UTC | HN request time: 0.273s | source | bottom
Show context
wslh ◴[17 Nov 24 16:11 UTC] 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 #
1. SoftTalker ◴[17 Nov 24 16:58 UTC] 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 #
2. wslh ◴[17 Nov 24 17:54 UTC] 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 #
3. moomin ◴[17 Nov 24 18:56 UTC] No.42166090[source]▶
That’s every programming language abstraction. All of them break when you get a fair amount of complexity or performance requirements.
replies(1): >>42166547 #
4. wslh ◴[17 Nov 24 19:47 UTC] No.42166547{3}[source]▶
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.
5. lkuty ◴[17 Nov 24 19:51 UTC] No.42166587[source]▶
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.
6. SoftTalker ◴[17 Nov 24 22:37 UTC] 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.