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).
Probably a hard question to answer. IME, cultural norms around documentation vary pretty wildly.
Some orgs I've worked for were very "wiki" driven - there's a big expectation of using Confluence or Notion to navigate documentation. This applies both big (5000+) and small (50+) organizations for me.
Other organizations I've worked in were very document centric - so you organize things in folders, link between documents (GDoc @SomeDocument or MSFT's equivalent). Those organizations tend to pass around links to documents or "index" documents. Similarly, this applies for both big and small organizations in my experience.
Of the two, I tend to prefer the latter. Without dedicated editors, the wiki version seems to decay rapidly, especially once the org grows above some size.
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)?
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!
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.
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.
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.
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.
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.
"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."
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.
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.
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.
How about an AI-tutor? Actual professors don't have time to adapt their teaching to every indfividual studen's knowledge background. But AI might.
Universities should start their own AI-tutor development programs, in co-operation with others because, only way AI-tutors can become better is by practice practive practice.
So I'n not sure if this is a new viewpoint or not, but it is not only students that need training, it is also teachers who need to be trained more in teaching. AI is all about "training", understanding is about training. Training is the new paradigm for me.
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.
> 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.
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.
It's also useful to be able to understand how the idioms map into the syntax of programming languages that one is actually going to use going forward. The point of SICP isn't what language you use, but how you use it, and how you think about the process of using it. Lisp itself exists because someone had the idea of taking the theoretical abstraction and actually realizing it, in notation similar to what the theorists were already using. But that similarity isn't actually relevant to core concepts like "functions as first-class objects", or referential transparency, or the substitution model of computation, or the complexity introduced by mutable state, etc. (Or, dare I say it: to the mind-expanding effects of contemplating the Y combinator.) These ideas can make you a better programmer in any programming language.
Nor is there any good reason to filter people out preemptively. If seeing `foo(x)` instead of `(foo x)` makes the student more receptive to a proper understanding of recursion, that's just fine.
Then it does not matter what language SICP chooses to illustrate timeless concepts? Even if some JS stuff changes down the line people should be able adapt what’s on the book on the fly?
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 43
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?
>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 notation 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.
When encoding tagged unions as lambdas, the tags are arguments. In this case `Nothing` has two available tags (`nothing` and `just`) and uses the tag `nothing`. `Just` does the same with the tag `just`, only that the tag gets an additional argument (as does its constructor `Just`), such that the value can be extracted afterwards - just like in an enum:
This is a big reason why legacy production code bases are such a nightmare to work with: developers refuse to learn anything beyond the minimum necessary to pile on yet another band-aid fix and the code base turns into a disorganized ball of mud
Alternative: successive developers each piled on their own, different coding preferences, leading to frankencode that requires keeping every paradigm at once in working memory
You 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.
In this particular case IMO it's bad because it essentially removes nominal typing for arguably no benefit.
Even in Lean, a dependently typed language where recursors can be made explicit, people prefer using pattern matching instead of them. There is even sugar for transforming some recursors-like functions into pattern matching like syntax. FYI in Lean recursors are marked as non-computable due to performance concerns, so you can use them to write proofs but not programs.
Seen from yet another point of view, this is transforming inductive types in a function corresponding to a visitor. And yet functional programming folks spent years trying to convince people to replace visitors with proper inductive/algebraic data types and pattern matching, so this idea is a step backwards even for them.
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
The two higher order functions passed into `foldMaybe` are your `Nothing` and `Just` (modulo I added the Unit param to the Nothing case to be a little more precise).
It may be elegant mathematically, but then conveyed through a language that is strictly in the ASCII character set without any alignment or internal justification, they're really just painful to look at.
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.
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.
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.
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.
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.
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.
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.
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
For me it was "JavaScript must be enabled in order to use Notion" (I'm a NoScript user). But it had already redirected me to another domain to show this page. How am I supposed to enable JS for the actual domain of the page? I have ways of course, but it seems like notion is deliberately flipping the bird to people like me...
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’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:
"Lambdas" and functions are not different things, in a functional-programming perspective (i.e. where you're operating with referential transparency and immutable objects anyway). The lambda syntax is just function-definition syntax that doesn't include an implicit name binding.
I just found it by chance somehow when trying to review gaps in my maths education - it’s excellent for reviewing complex analysis (say) if you did it years ago - or less obviously - doing a quick pass over a topic before you learn it for the first time. Then I found the excellent math sorcerer channel and his view is much the same as mine.
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 :-)
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.
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
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.
Highly intelligent people can learn without any real world context (and I'm not one of them). Obviously there are problems with unapplied learning (or learning for learning's sake), but it is certainly possible.
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.
I learned functions in terms of sets. Domain and codomain are sets. Function is a set of ordered pairs between them.
How could we go the other way? A set can be "defined" by the predicate that tests membership, but then how do we model the predicates? Some formalism like the lambda calculus?
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?
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?
> 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.
Just to pick some nits with those claims… CPUs do have hardware support for functions in the form of a stack and CALL/RET instructions. Functions are a useful abstraction since more or less all software uses them. Functions and functional languages are two related but different things, and the usefulness of functions as an abstraction doesn’t depend on whether functional languages have taken off. And last, I’d say functional languages have gained ground over time, as well as semi-functional languages like, say, Python and JavaScript. Even C++ is gaining more functional language features over time.
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.
I'd rather see FP addicts exit Python ecosystem. I had dubious pleasure of working with Python codebases written by FP enthusiasts. It was hell. Simple, well-understood problem domains were made way more complex by introduction of GraphQL and FP resulting in about a dozen levels of nesting for something that could have been a simple FastAPI app.
The two calls to `fib` are surely meant to be `fibonacci` since the latter is defined, but not the former. Indeed, the code is correct in the github repo:
"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)
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.
It is a simplification that makes easier to grasp a paradigm. Sure, it could be taken to extremes and pretend nothing else exists outside this ‘everything is a … “ bubble. Luckily we can learn from others’ mistakes and not fall into traps too often.
>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.
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.
Everything (expressed with language) is just a model of something else.
By making the model follow some simple rules which we think the real thing follows as well we can reason about what happens when some inputs to the real thing being modeled change, by runnign our model (-simulation).
Thus you could add to your list: "Everything is just a simulation".
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.
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
Half of what you call functions in that comment, are not actually functions and in the FP world many would not call them functions. Rather they are procedures. Functions are procedures, but not all procedures are functions.
Which is also a problem with thinking this is a helpful abstraction: apparently, not everything you need to do can be captured by functions (in that sense)!
Afaik, the definition is just "a sequence of steps/instructions". That is of course much broader than a (simple) function, which among other things for one input gives you one output, and for the same input always the same output. A procedure can do that too, but it can also give you different outputs for the same input, due to side effects.
Many of those things can be modelled as functions, they just need to actually be written that way (e.g. if you have a function that requires some resource, maybe it should require that resource! If it depends on the date/time, maybe it should depend on the date/time! If it returns a nondeterministic value, maybe it should return a nondeterministic value!). I think the functional programming approach shines partly because it forces you to take these things seriously: if you want to use e.g. implicitly shared resources, you need to model that, and "functions" that rely on implicitly shared resources are going to be explicitly distinct from actual function functions.
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 think you could prove 0 ≠ 1 if you had some other concrete fact about inequality to make use of. You could reason from the theorem "f = g -> f x = g x" to create your inequality fact on the right side and then take the contrapositive.
It seems correct to me that you can't directly prove inequality between Church numerals without starting with some other fact about inequality. Whereas with inductive data types, a proof system can directly "observe" the equality or inequality of two concrete instances of the same inductive type, by recursively removing the outermost constructor application from each instance.
Looking at the linked references, I'm not sure what else is being assumed to be available or not available when considering proofs using the Church numerals. I guess that will matter a lot, and I don't know enough to make more general statements about what is or isn't sufficient here.
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
243 comments
[ 3.3 ms ] story [ 288 ms ] threadhttps://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)
What if your text editing and presentation experience was slow and laggy? That’s Notion.
Some orgs I've worked for were very "wiki" driven - there's a big expectation of using Confluence or Notion to navigate documentation. This applies both big (5000+) and small (50+) organizations for me.
Other organizations I've worked in were very document centric - so you organize things in folders, link between documents (GDoc @SomeDocument or MSFT's equivalent). Those organizations tend to pass around links to documents or "index" documents. Similarly, this applies for both big and small organizations in my experience.
Of the two, I tend to prefer the latter. Without dedicated editors, the wiki version seems to decay rapidly, especially once the org grows above some size.
Knowledge management is hard...
Edit: also, the pop-up menu on the right side that completely breaks your scrollbar. Putting that UI/UX degree to use.
Well then that’s a relief.
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.
Infinite configurability means infinite validation time.
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.
Archive seems to "bake" JS sites to plain HTML.
I guess that just goes to show that the author’s mind was, in fact, blown.
https://news.ycombinator.com/newsguidelines.html
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.
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.
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.
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.
Call me a hopeless optimist, but I think there's a better way out there.
Universities should start their own AI-tutor development programs, in co-operation with others because, only way AI-tutors can become better is by practice practive practice.
So I'n not sure if this is a new viewpoint or not, but it is not only students that need training, it is also teachers who need to be trained more in teaching. AI is all about "training", understanding is about training. Training is the new paradigm for me.
Is that why they are so bad at adapting to foreign languages and frameworks? Maybe they should go back to the basics.
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.
A more fair comparison is engineering or applied math major, not pure math at MIT.
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.
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.
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.
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"
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.
Nor is there any good reason to filter people out preemptively. If seeing `foo(x)` instead of `(foo x)` makes the student more receptive to a proper understanding of recursion, that's just fine.
https://sicp.sourceacademy.org/
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:
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?
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 notation 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...
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):
That's just weird.i agree that the cognitive load in a language like js which is not prepared to accommodate this paradigm is not worth it
even when deciding to use Haskell we need to weigh the pros and cons wrt the project's goals
Even in Lean, a dependently typed language where recursors can be made explicit, people prefer using pattern matching instead of them. There is even sugar for transforming some recursors-like functions into pattern matching like syntax. FYI in Lean recursors are marked as non-computable due to performance concerns, so you can use them to write proofs but not programs.
Seen from yet another point of view, this is transforming inductive types in a function corresponding to a visitor. And yet functional programming folks spent years trying to convince people to replace visitors with proper inductive/algebraic data types and pattern matching, so this idea is a step backwards even for them.
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.
SQL is an example of a language that is at least somewhat like that.
Doesn't really say "how" to do that, it only defines what you want.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.
In elixir you can pop off as many as you like.
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.
A closure with no behaviour is just a pointer to the enclosed variable. A closure with 2 pointers is a pair, which you can get the car and cdr.
The runtime needs to make the pointee available outside its definition, so escape analysis, garbage collection, etc. But no dictionary is needed.
that said, since I've been reading about kanren and prolog I'm about to say "everything is a relation" :)
I got to the same conclusion a while ago, except that I found that it's lambdas all the way down.
https://www.cambridge.org/core/books/all-the-math-you-missed...
https://m.youtube.com/watch?v=ur0UGCL6RWc
Did you read the book in isolation or was it a part of a class / MOOC ?
https://archive.org/details/all-the-mathematics-you-missed
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.
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.
It's practical and productive and profitable, which is great, but not really the original goal.
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.
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?
How could we go the other way? A set can be "defined" by the predicate that tests membership, but then how do we model the predicates? Some formalism like the lambda calculus?
A category can be defined in terms of its morphisms without mentioning objects and a topos has predicates as morphisms into the subobject classifier.
lambda calculus would provide a computational way to determine the truth value of the predicate, any computable predicate that is.
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.
How do you represent an irregular float?
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.
https://github.com/savarin/pyscheme/blob/0f47292c8e5112425b5...
- 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 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.
That one ends in a tarpit where everything is possible but nothing of interest is easy.
https://www.cs.yale.edu/homes/perlis-alan/quotes.html
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.
It's like being mad that hammer was so successful we invented screw to improve on it's greatest hits.
- 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.
By making the model follow some simple rules which we think the real thing follows as well we can reason about what happens when some inputs to the real thing being modeled change, by runnign our model (-simulation).
Thus you could add to your list: "Everything is just a simulation".
Except the real thing of course :-)
* modulo infinity
** except a small number of languages that are not
What doesn't fit into this particular "everything?"
- everything is a string
https://wiki.tcl-lang.org/page/everything+is+a+string
- 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!)
One of the thinga I miss from my C++ days was the ability to mark functions as const, which made them fairly pure.
Being able to clearly mark which is which, but also to combine them easily, was very productive.
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".
It seems correct to me that you can't directly prove inequality between Church numerals without starting with some other fact about inequality. Whereas with inductive data types, a proof system can directly "observe" the equality or inequality of two concrete instances of the same inductive type, by recursively removing the outermost constructor application from each instance.
The relevant part is that this is basically how “software engineers continual education” is going to look like
That's a fun statement.
https://www.dabeaz.com/compiler.html
There are externalities like networking and storage, but still data transformation in a way.
If this number, jump to numberA otherwise jump to this numberB. Also if numberC store numberD at numberE. ;)