They give a nice introduction to encoding state as pure functions. In fact, there are many more purely functional encodings for all kinds of data like trees, integers, sum/product types, images, monads, ...
The encodings can be a bit confusing, but really elegant and tiny at the same time. Take for example a functional implementation of the Maybe monad in javascript:
Nothing = nothing => just => nothing
Just = v => nothing => just => just(v)
pure = Just
bind = mx => f => mx(mx)(f)
evalMaybe = maybe => maybe("Nothing")(v => "Just " + v)
console.log(evalMaybe(bind(Nothing)(n => pure(n + 1)))) // Nothing
console.log(evalMaybe(bind(Just(42))(n => pure(n + 1)))) // Just 43You can see this as replacing an inductive type with its recursor's function type. It's pretty cool in type theory, but not so good for actually programming stuff.
You can derive these implementations from the recursion principle for your type:
data Maybe a = Nothing | Just a
foldMaybe :: (Unit -> r) -> (a -> r) -> Maybe a -> r
If you have any light to shed, I'm wondering about inductive data types and their expressive necessity here: https://news.ycombinator.com/item?id=42166709
[flagged]
I think it's all right if you're used to the notation. The first two lines are tagged unions and will be recognisable as such if you're familiar with encodings like Scott/Church pairs/lists/numbers. Once you understand the structure, the definition of `bind` becomes obvious, as its two arguments represent the cases "is nothing" and "is just", where in the first case Nothing is returned, and in the second case the function is applied to the value inside the Just.
I think that writing such code, if only for educational purposes, can be really helpful in actually understanding how the state "flows" during the monadic bind/return. Typical monad instantiations of Maybe do not give such deep insight (at least to me).
> Just because you can do a thing doesn’t mean you should.
Of course you should, where would be the fun in that?
> The first two lines are tagged unions
Are they? But in the Nothing you have 2 identical members (`nothing' without arguments), won't that throw an exception?
To borrow Rust syntax (pun intended):
enum Nothing {
nothing,
just
nothing
};
It's alright once you get used to it usually means it isn't alright in my experience. There are exceptions of course.
>I think it's all right if you're used to the notation.
Higher mathematics in a nutshell.
>Of course you should, where would be the fun in that?
Also higher mathematics in a nutshell.
Narrator asks: Who should we put in charge of <<thing that will effect people in a tangible way>>?
Not the mathematicians! echo the crowd in unanmity.
Narrator asks: Who will we delegate the task of <<abuse of notation>> to?
The crowd grumbles, arguing amongst themselves whether such a question even warrants an answer. A mathematician stands up, proclaiming "We'll take it!", following up with, "Once you understand the notarion involved in my previous statement, you will understand why this outcome is inevitable."
The crowd, seeing the wisdom of not even embarking on that tribulation, assents to the delegation, given the task of undoing the abuse of notation for the legibility of the layperson is also delegated to the aspiring mathematician.
Scene opens on current day...
It’s definitely easier to read in an ML language, that’s for sure!
If there is a wrong way to do something someone will do it.
There’s an old saying attributed to the Inuit: everyone enjoys the smell of their own farts.
David Beazley is a bit of a legend in the python world and honestly this course seems a surprising idea but it took about two seconds thought before it seemed perfect match and Inhave signed up for the next one.
The relevant part is that this is basically how “software engineers continual education” is going to look like
"legend in the python world"
That's a fun statement.
The cons/car/cdr implementation as lambda was magical the first time I saw it. But it just shows that the language runtime must implement key/value dictionaries and you are able to borrow that implementation to make other data structures.
I find the destructuring logic in elixir much more interesting, and the watered down version in ES6 much more practical.
In elixir you can pop off as many as you like.
Can you share any resources about it?
I’m a bit of an elixir noob, but Enum functions like slice let you cut up lists in various ways, and you can pattern match values in maps in function definitions:
http://www.skuunk.com/2020/01/elixir-destructuring-function....
Which can let you unroll function preambles, or apply different rules if for instance an admin user runs a function versus a regular user.
Surprised "mind-blowing" is not in the HN clickbait filter.
It is now.
There's a typo in the code in "the substitution model" section:
("+", ("fib", ("-", "n", 2)), ("fib", ("-", "n", 1))),
https://github.com/savarin/pyscheme/blob/0f47292c8e5112425b5...
OP here. Thank you!
I recently came across the notion that you need inductive data types (and can't just use Church encodings) if you want to do theorem proving, like proving that `0 != 1`.
I threw up some content up here: https://intellec7.notion.site/Drinking-SICP-hatorade-and-why... , along with an unrelated criticism of SICP.
I'd like to better understand what the limitations are of "everything is just a function".
Not a fan of everything-is-a-function because it's oversimplistic and often unhelpful. Some of the issues:
- functions that don't fit in cache, RAM, disk, etc.
- functions that have explosive big-O, including N way JOINs, search/matching, etc.
- functions with side effects, including non-idempotent. Nobody thinks about side channel attacks on functions.
- non-deterministic functions, including ones that depend on date, time, duration, etc.
- functions don't fail midway, let alone gracefully.
- functions don't consume resources that affect other (cough) functions that happen to be sharing a pool of resources
- function arguments can be arbitrarily large or complex - IRL, there are limits and then you need pointers and then you need remote references to the web, disk, etc.
(tell me when to stop - I can keep going!)
Oversimplifying can be great at times. In this case, the lambda-calculus model (which is the base for this type of "everything is just a function" approach) is a great model of computation because it is so simple, while being easy to handle /reason about (compared to eg. Turing machines), which is why it is at the base of most computer logic/proof systems
Neat article. But it was very difficult to navigate for me because 99% I use the keyboard up/down arrows to scroll the page as I'm reading. This page swallows those keystrokes, apparently. Page up/down work, but sometimes. I never use page up/down while reading because I'll be in the middle of a sentence of a paragraph at the bottom, hit page down, and now I need to scan my eyes back to the top of the page. First, it introduces a hiccup in the middle of a sentence, and secondly, because of the hiccup I often want to go back a line or two to reestablish context, but it is now offscreen. Grr.
For me it was "Your browser is not compatible with Notion." on Android with Hack's (hacker news client) built in browser which is I guess just a stripped down Web view
He wrote my favourite maths book.
https://www.cambridge.org/core/books/all-the-math-you-missed...
Cool, available on archive.org too
Did you read the book in isolation or was it a part of a class / MOOC ?
Fellow is doing an aggressive function. I wouldn't dare put contrary functions against his output.
this guy has Chris Fleming energy.
Reading this brings back fond memories of taking CS61a with prof Brian Harvey at UC Berkeley some 25 years ago. Same book, same level of mind=blown, and very similar instruction style. we spent a semester instead of a week and if memory serves tuition was about the same, but they threw in some English and history courses as well :-)
OP here. Thank you for the kind words! For those who enjoyed this, I would also point out Eli Bendersky's excellent SICP series https://eli.thegreenplace.net/tag/sicp
Same. For me it was 15 years ago, but was with Prof. Brian Harvey in Pimentel hall with the rotating stage.
Nice memories.
I fell in love with scheme eventually as it was such a simple syntax. Getting used to parentheses did take some time though.
Same memories, and even the same timeline :) I still recall being blown away by the concept of "code is data", the magic of which I haven't encountered in professional development, alas.
alternative take: everything is just sets
both can be a foundation for mathematics, and hence, a foundation for everything
what's interesting is how each choice affects what logic even means?
The book itself is currently being discussed at:
https://news.ycombinator.com/item?id=42157558
Is there a reason why the link goes to the discussion at the bottom of that page rather than the beginning?
Could this be folded into the other discussion? (I don't see that the link has been posted there yet)
From my perspective all software is essentially applying transformation functions to some data.
There are externalities like networking and storage, but still data transformation in a way.
Actually it is more like Algorithms + Data Structures = Programs.
for some reason I resonate more with the fp/math/linguistic side of this coin. you don't even think about programs in the end
that said, since I've been reading about kanren and prolog I'm about to say "everything is a relation" :)
"Everything is just" approaches usually result in hammering things that don't fit into fitting. That often ends badly. Computing has been through, at least:
- Everything is just a function (SICP)
- Everything is just an object (Smalltalk, and to some extent Java)
- Everything is just a closure (the original Common LISP object system)
- Everything is just a file of bytes (UNIX)
- Everything is just a database (IBM System/38, Tandem)
- Everything is just a filesystem (Plan9/Inferno)
- Everything is just a buffer (K&R C and many of its descendants)
- Everything is just a logical assertion (Prolog)
I look at the list and I see a bunch of successes, though some of them are niche.
None of the things you mention ended badly though. I think all of those approaches you list are incredibly useful and important concepts and I am very happy that I not only know them, but that because of how universal they are I can leverage my knowledge of one approach to learn or apply another approach.
Another angle on this is that there’s many formal axiomatic ways to define computing.
Everything is just a Turing machine. Everything is just a function. Everything is the Conway’s game of life.
The fact that all of these forms are equally expressive is quite a surprise when you first discover this. Importantly, it doesn’t mean that any one set of axioms is “more correct” than the other. They’re equally expressive.
Everything is just a Turing machine.
That one ends in a tarpit where everything is possible but nothing of interest is easy.
>where everything is possible but nothing of interest is easy.
Real development IMX is not much different. People just have low standards for "interesting" nowadays, and also have vastly increased access to previous solutions for increasingly difficult problems. But while modern programming languages might be more pleasant to use in many ways, they have relatively little to do with the combined overall progress developers have made. Increased access to "compute" (as they say nowadays), effort put into planning and design, and the simple passage of time are all far more important factors in explaining where we are now IMO.
That's the generic problem with "Everything is a ...". Trying to force things into a paradigm that doesn't fit well complicates things.
I would go further and say that each one of these were so useful that they presented entirely new sets of problems to attempt to solve, because of how many other problems they directly addressed.
It's like being mad that hammer was so successful we invented screw to improve on it's greatest hits.
OP here. I would add "All you need is NAND".
"All you need is Transistor" - can't believe how badly that ended!
It's because all you need is Ohm's law.
Ohm's law doesn't really work for transistors though.
James Clerk Maxwell has entered the conversation
How about everything is just state and transformations.
Everything is just a turing machine after all* **
* modulo infinity
** except a small number of languages that are not
And functions are just numbers combined with if/else's and a pretty name at the end of the day.
If this number, jump to numberA otherwise jump to this numberB. Also if numberC store numberD at numberE. ;)
So an integer is represented by how deep in the stack you are?
How do you represent an irregular float?
Probably by using IEEE 754.
What will make any function that uses floating point numbers mindblowing complex. But there's probably an easier way by creating some transformation from (Integer -> a) to (F64 -> a) so that only the transformation gets complex.
Anyway, there are many reasons people don't write actual programs this way.
David Beazley is using Scheme! That is a nice shift towards a civilized language. I hope he scraps the scheme-in-python section, but perhaps that is intended as an exit drug for Python addicts.
Shameless plug: https://aplaceofmind.notion.site/It-s-Lambdas-All-the-Way-Do...
I got to the same conclusion a while ago, except that I found that it's lambdas all the way down.
> 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
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.
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 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.
isn't that what declarative programming frameworks do already ?
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.
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.
Imagine if that statement applied to every non-digital thing as well.
Has anyone read the new SICP with Javascript as language of choice?
Isn't scheme with close to zero syntax so easy to learn?
Why did someone think it was a good idea to switch to JavaScript?
I think the person who'll get value out of SICP will not have any problem picking up scheme syntax on the fly.
I agree. Being self contained helps make it timeless. In contrast are books with a CD in the back with an outdated Java compiler you will never be able to setup. And then you have to migrate the snippets yourself.
If you study any other related field like math or physics you become accustomed to learning a formal system for the context of a particular problem.
CS students tend to have this weird careerist view where every page just directly help them get a job.
Most undergrad CS students want a practical/engineering curriculum. They are not really there for theory, but for a long time that's how CS departments operated, unless maybe you were at an engineering school.
Schools are so desperate to keep up enrollment numbers today that many have capitulated and are giving students what they want instead of what the faculty thinks they need.
> Most undergrad CS students want a practical/engineering curriculum.
If all someone wants is the practical benefits of programming and has no interest in the underlying theory, they shouldn't waste their their time and money on a CS degree. All the practical information is available for free or at very low cost.
But, a lot of employers demand a degree.
Maybe so, but we shouldn't be doubling down on expensive and time consuming degrees in the name of ill-conceived credentialism. That hurts everyone except the universities profiting off of it.
How does that mean anything to the people who need to be employed to continue living? We're not the ones with the ability to change this.
The same applies to CS, so you're missing something else -- skilled tutors and the campus experience.
At least in the U.S., many students are paying upwards of a $100k for a four-year degree. That better be one hell of a "campus experience" and some next-level "skilled tutors".
Call me a hopeless optimist, but I think there's a better way out there.
There is a big difference between being practically minded and the allergy to learning anything which doesn’t translate to resume keywords. SICP will teach you more about JavaScript, python, etc than most anything.
> They are not really there for theory
Is that why they are so bad at adapting to foreign languages and frameworks? Maybe they should go back to the basics.
> Most undergrad CS students want a practical/engineering curriculum.
Somewhat understandable considering that student loans put you into indentured servitude unless you have rich parents. Although I still think they're shortsighted. A good CS graduate should understand that programming languages are just syntactic sugar over the underlying concepts and have little trouble translating/picking up the basics of new languages.
You are comparing mathematicians to programmers.
A more fair comparison is engineering or applied math major, not pure math at MIT.
I dont think so. SICP isn’t abstract algebra, it’s just unlikely to be the exact syntax you will use at your job.
Engineers rarely do laplace transforms by hand either.
The book is written for 1st year stem undergrads at MIT. So maybe 2nd or 3rd year at state school.
Because knowing scheme isn't going to get you a job at most places. Employers overwhelmingly want JavaScript or Python these days. Trailing that would probably be Java, C++ and C#, and regular old C.
When I did my undergrad CS degree, the fact that scheme was so heavily used was a common complaint they received from students. It just wasn't a marketable skill.
Four year CS degrees usually require something around 20 (maybe even more) CS courses. Are you saying that all of those courses at your school were taught in Scheme? You never had a chance (in the classes, ignoring hobby or internships) to use other languages? That'd be a pretty unique school.
But even if that were true and you did take 20+ classes in Scheme, you're still a college educated computer scientist. You can't pick up JavaScript or Python in time for a job interview for an entry level job? They're easy languages to learn. If you survived four years of exclusively being taught with Scheme, they'd be a breeze to pick up.
No not all scheme. That's an example. The intro course and programming languages course was scheme. There were a number of other languages used. I guess I should have been more nuanced in that a number of students wanted to be taught the currently popular progrmmming languages so they could use them on a resume. They complained about using scheme (or whatever "teaching" language a professor might require) and did not yet appreciate that the concepts/theory they were learning applied to any programming language they might need to use.
They wanted a trade school/practical education in something immediately marketable, not a theoretical education.
The reason I remember this is that in my "exit interview" as a senior I mentioned that I appreciated the exposure to these languages and theory and my advisor remarked "we don't hear that very often, the usual feedback is that we don't teach the languages employers want"
JS is easier to read IMO. And of the widely-used interpreted languages I can think of, it's actually got the least confusing implementation of first-class anonymous functions. Python lambdas are limited to one expression, Ruby has that confusing block vs. proc vs. lambda problem, etc.
I do feel like the value of using Scheme is teaching students early on that syntax doesn't really matter. Those that are actually interested in CS theory will find this enlightening, those that are simply in it because investment banking is so 2007 will churn out.
I haven't, but you can compare editions with this SICP Comparison Edition:
Yes. But, I prefer the regularity of the Lisp syntax.
The link takes around 10s to render. That's excessive for a text article.
"Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
And if you have JS disabled by default, it redirects to a page on a different domain name, so you cannot easily allow it in noscrpt just for that website, even if you want to. I gave up on that though; judging by the title, the article is going to be about modelling all the things as functions, as commonly and similarly done with other objects (e.g., sets, categories), which I wanted to confirm, and maybe to nitpick on this perspective and/or the title then (i.e., it is not quite correct to declare everything a function just because you can model or represent things that way).
The arrow and page up/down keys don't work in any predictable pattern for me, it's really weird. Like I thought it only scrolled up and down with the arrow keys if I press it 4 times, but then page up/down keys don't work no matter how many times I press it, then I focus on the page and it works, but then the arrow keys take 6 times to press before moving, and then I tried the same pattern again, and the arrow keys now take 11 presses before they start moving. Usually a lot of modern apps predictably break the back/forward history buttons and tab focus, but I've never seen anything quite like this. I guess it must be still delivering value though even if the product isn't polished.
I can’t use the scroll to the top gesture in iOS either.
I guess that just goes to show that the author’s mind was, in fact, blown.
Archive seems to "bake" JS sites to plain HTML.
Notion. Why do people use that stuff? Especially for tech text articles.
wysiwyg document authoring experience, afaik there are still no alternative publishing platforms with both the flexibility and point click content authoring UX of Notion. Change my view, I’m in the market!
I’m also on the market and this conversation took Notion out of the running.
Maybe it's made entirely of functions.
Well, it’s a published Notion site, and Notion is a powerful doc creation platform. It’s not really intended to be a performant publishing tool.
>a powerful doc creation platform
Which, based on what I see in the rendered archive.is version, is being used to do nothing outside of the normal use of a standard Markdown-based SSG like Nikola or Jekyll.
Not that doing more would be a good idea anyway.
Or a performant anything else, AFAICT
It’s a performant publishing tool (depending, of course, on your expectations) but it’s not a high performance publishing tool.
It's a performant publishing tool and perhaps even high performance publishing tool - in terms of user effort. What it's not is performant displaying the thing it published.
That’s fair. Viewers who don’t know what is serving the page will be disappointed. If you know it’s Notion, then it works about as expected which satisfies the definition of performant.
“Just because you are bad guy doesn’t mean you are bad guy.”
Yeah the guy at my last place that was proud of serving < 2 req/s/core liked to use the world “powerful” too. It’s like it was his favorite word. And he’s on the short list of people I refuse to work with again. What a putz.
Well Notion usually exceeds at least 3 req/s/core, so nothing to worry about there
<snerk>
Well then that’s a relief.
Powerful, lightweight, configurable, performance.
These are some of the biggest weasel words of IT. Every one of them has an implicit nature of a comparison word and yet the comparison or any sort of hard metrics are always completely absent in their use.
Yarp.
Infinite configurability means infinite validation time.
46 domains blocked by UBlock Origin, 3 by my own NoScript filter. Seems about right for a "modern" website.
Edit: also, the pop-up menu on the right side that completely breaks your scrollbar. Putting that UI/UX degree to use.
Page weight is 7.2MB, 25.6 uncompressed. 110MB heap size. Such extravagant wastefulness.
And this is for what, a ~100KB header image (most of which is bounding-boxed away) and 24KB of actual text (Markdown source would be only slightly larger)?
I wonder if that's large enough to contain an old linux running an old version of firefox and feed that the page content.
Wow it’s really bad.
I mean it’s Notion. That’s par for the course.
What if your text editing and presentation experience was slow and laggy? That’s Notion.
Whats the best corporate wiki platform?
Notion. Delivering value right at your fingertips.
Is that a clever way of saying it’s about as fast as braille?
That’s why no one reads articles, just headlines.
A computer fundamentally isn’t functions though. That’s not how a processor works. If functions are a useful abstraction, why haven’t functional languages taken off?
> A computer fundamentally isn’t functions though. That’s not how a processor works. If functions are a useful abstraction, why haven’t functional languages taken off?
If computers and their processors are a useful abstraction, why don't we write everything directly in machine language - or microcode for that matter?
This is more about computing than about computers. As Dijkstra put it, "Computer science is no more about computers than astronomy is about telescopes."
Computing involves languages, including many languages that are not machine languages. Every language that's higher level than machine code requires translation to actually execute on the particular machines that we've developed as a result of our history and legacy decisions.
The lambda calculus is a prototypical language that provides very simple yet general meanings for the very concept of variables - or name-based abstraction in general - and the closely related concept of functions. It's a powerful set of concepts that is the basis for many very powerful languages.
It also provides a mathematically tractable way to represent languages that don't follow those principles closely. Compilers perform optimizations like static single assignment (SSA), which are fundamentally equivalent to a subset of the functional concept of continuation passing style (CPS). In other words, mainstream languages need to be transformed through functional style in order to make them tractable enough to compile.
The mapping from a lambda calculus style program to a CPU-style register machine is quite straightforward. The connection is covered in depth in Chapter 5 of SICP, "Computing with Register Machines." Later work on this found even better ways to handle this, like Appel's "Compiling with Continuations" - which led to the SSA/CPS equivalence mentioned above.
There's a lot to learn here. It's hard to recognize that if you know nothing about it, though.
It seems functional language experts are too busy rewriting SICP instead of actually useful programs.
I just haven’t seen anything concrete as to why SICP’s materials are useful in either the real world or academia. Sometimes these discussions talk about how it is useful for computer science and for theory but even that seems like a claim without evidence. Is this just people reminiscing about their first introduction to programming or a favorite professor?
I think it's a cool book for students.
But for real world programming, the tedious ones is related to validation, parsing and other business logic.
So i prefer a book to help teach CS by using real world codebase to solve real world everyday problem as a software engineer instead.
You can have your cake and eat it.
SICP shows a real world code base. It's real world programs that builds up to implementing real world programming languages.
Why would you validate if you can parse? If you have a decent chunk of experience in implementing business logic then you know that your quality of life will be destroyed by switches and other inscrutable wormhole techniques up until the point where you learn to use and build around rule engines. SICP shows you how you can tailor your own rule engine, so you won't have to get the gorilla and the jungle when you reach for one in an enterprisey library.
That's like teaching physics via car repair. You'll learn a few ideas, but not much of the science.
It's practical and productive and profitable, which is great, but not really the original goal.
It's not a surprise that most of students failed and hate abstract algebra right ? I mean to learn the concept, you will need to know more about the concept itself in a real world context.