Too much philosophy behind it to be chaotic. This very much feels like Lawful Evil. They're extremely determined to do *bad* things. And they'll follow rigid rules and guide lines to do *bad* things.
My entire OOP experience. Hours of philosophy to create code that doesn't make sense w/o that philosophy and blows up on a simple structural change due to all the coupling.
my functional experience as well. I remember eric elliott, guy from medium, overcomplicating things with transducers and react hocs naturally the js ecosystem is a mess, if guys like this have much influence
@@guillemgarcia3630 I just read his article on transducers, and it seems a bit misapplied in JavaScript. They're great for Clojure because they solve real problems the language had. I wish people would analyze tools in context rather than thinking they apply to every language. Similarly, I think monads are a bad choice for dynamic languages, but great for static languages. Yet you still see people trying to stuff them into Elixir.
The origins of object-oriented programming (OOP) can be traced back to the development of the Simula programming language in the 1960s by Ole-Johan Dahl and Kristen Nygaard at the Norwegian Computing Center. Simula was originally designed for simulating real-world systems, and it introduced the concepts of classes and objects, which are now fundamental to modern OOP languages. Simula's innovations in OOP inspired the development of other programming languages, such as Smalltalk. It's annoying when some people wrongly cite the history of OOP, then proceed to be is super opiniated it.
Imagine a function that I could pass any array of grades in. One student or the whole school, the function wouldn’t care. It would just return the best grade of the input set. Now wouldn’t THAT be cool 🤔
Better yet, what if we had a max function, so it doesn't even need to be a grade? Any number will work. Hell, it doesn't even need to be a number. It just needs to implement the `Ord` trait.
Best way to put it lol... One of the best things a programmer can do for themselves is creating logic that is direct and as generalized/simple as possible without making compromises. The article literally starts off by saying ''Well we could rename the function to better indicate usage, or [we can create a complicated web of indirection and run-time bloat]''(in so many words) Rename the function ''GetBestGradeFromArray'' - and the entire codebase as well as everyone involved will be happier.
Easy. We can just create a Students functional class thingamajig that take in multiple Student functional classes and then have a “function” that iterates over all the _students to get the max and return the max of that. Simple. Efficient.
This looks kinda' similar to how objects are implemented in the Structure and Interpretation of Computer Programs video lecture series. I guess the point of the article was to teach how you can build a thing which behaves like built-in objects using simpler parts-ignoring the fact that what you have created is a monster. That is, the point was not to teach a programming technique but to transmit a conceptual understanding. For comparison: I could roll my own vtables in C if I needed them. I hope I won't need them, but I really like knowing how to. This article might have expanded someone's mind the same way my mind was expanded when I understood that. With that in mind, I don't find the article objectionable.
It's clear from the last paragraph that he's not recommending that code style. It's designed that way to DEMONSTRATE what message passing is. He should have brought it back to idiomatic JS and pointed out where the message passing happens.
I think the author of the article missed the chapter on prototypes, prototype chains, and prototypal inheritance in JavaScript. Oddly enough, that's one of the main things that differentiates JavaScript from other languages.
I actually think this is great, it's so flexible that you can just override all properties inherited by the prototype, it defeats the coupling problem of inheritance. Also, if you're mad enough, you can implement abstract classes and interfaces by adding methods that throw an exception that tells you to replace the method with a new one. Don't recommend it but i did that on one older project that I started in JS and couldn't be bothered to port it to typescript.
The argument for FP has never been speed. Fans of FP tend to believe that their programs tend to be more correct. Hard to measure, so who really knows. I do think that there are lessons to be learned from that world, that will improve your programs, regardless of language or paradigm. Also, Rust is the only language that I know of that takes correctness seriously without going full FP. EDIT: The example in the article has nothing to do with anything that the hard core FP people are talking about though. Creating class-like functions with internal state is literally just a less readable way to write OOP.
yeah this article makes me sad. but "functional oo" is a real thing. if you initialize a class with immutable state, and have n number of functions produce values based on the initial state, and pass in any other dependencies you need...aka a decorator that doesn't mutate anything. also called a value object, if nothing is mutated.
Yes, that is my understanding as well. If I understand correctly, there is a solid case that OOP was designed to optimize for resources (eg memory/storage/processor), that today are cheap and fast so it makes more sense to optimize for code that is more maintainable (obviously there is a balance here that is different for each scenario). For example, in most projects I have been on, hardware limitations have not really been significant issues. But mutable state in the domain logic, and over-abstraction have been. It's a similar point for Event type storage vs just overwriting data in the DB. Basically, that there are some trade offs like eventual consistency and more storage costs, but all the stuff you're storing is worth it.
Functional programs do not tend to be "more correct", but their correctness is usually easier to prove. Rust does offer a useful middle ground, though, as smaller blocks are usually easy to reason with using Hoare logic.
I think the idea is that you don't need to have OOP built in to use inheritance and all that. It's not about how it's nicer to read or anything, just that classic Message Passing can be done at all. To reiterate, I'm big into FP (Elm, Haskell etc), and I don't think the article was saying 'write JS like this', but more 'if you were curious about how it originally worked, it would work like this'. The author didn't talk about immutability or referential transparency at all, which is a huge part of why writing frontends in Elm is so nice.
The absolute best example to show someone would be an example of code from a functional language, and explain what's going on. For someone that knows javascript, it could be teaching bad lessons. For someone like me that doesn't know any javascript, the choice to use it as an example provides no actual benefit.
@@Hazanko83 I think it's a numbers game. In 2023, more programmers know JS than not, I think. I get your point though, it doesn't show things off as well as it could in another language that plays to its benefits.
This whole article was edging me. I was excited for them to say "look! This is just partial application! And it's a really powerful model when combined with immutability, and a syntax to support it!". Then there was the conclusion and now I'm blue balled.
After now 20 years of software engineering. I never needed multi inheritance, not once. Actually, all problems could be solved without inheritance at all. Interface where nice sometimes, but thats it. OOP and Polymorphism is the bain of software engineering. It leads to slow and hard to debug code. Add Pointers into the mix and the disaster is inevitable.
All cases for inheritance can be solved with composition if your language supports something like interfaces. Sometimes inheritance is less code, but meh.
@@voidwalker7774 A real life example where composition can replace inheritance or where inheritance is less code? Or what? OOP is not inherently bad by the way, people simply overcomplicate things, and not being able to have functions as first class citizens is probably the biggest issue, because that means you create classes just to access a function, which is unnecessary overhead for no good reason.
So you're telling me... They would rather manually type obj('string-message') that is not autocompleted in ANY way, than just do a obj.functionName, that depending on how things are set up will likely be autocompleted, or at least suggested by intellisense sometimes? I don't like classes, but doing this just to avoid using the keyword is pretty crazy. I'd rather go back to writing ConcreteAbstractFactoryBeans in java than implement function-classes.
I'm new to programming. I'll still be new to programming for the next 5 years, because the more I learn about OOP, the more I just don't get it. What's the point? What's a class? What's an object? What is the entire nuclear family doing with their generational wealth, and why does the oligarchy even exist in my CPU? WTF is polymorphism, and do they also attend swinger parties? I keep picking up tiny little bits via osmosis just by watching videos like this, and every time I do, I conclude that the only reasonable solution to any programming problem is return to monke (AKA procedural), apes together stronk, and maybe eat the rich to get the oligarchy out of my CPU. I don't get functional programming either, but when you say "functional programming was created as a reaction to how bad OOP is" I can definitely understand why I would subject myself to the mental gymnastics required to learn Haskell. And, the more I learn, the more I thank God that my deep contrarian streak caused me to reject OOP outright, _because_ it was popular.
I feel like this is way more complicated than just using classes to encapsulate functionality while keeping all methods pure, and implementing message broker as core component to please Alan Kay.
This is like an exercise one might do to try and understand OOP better and then immediately throw it away, not something one should write an article about on the internet saying it's what you should do
it’s also the wrong language to do this sort of thing which makes the argument 100x worse. if he is going to style up a lisp-y looking object, he should do it in lisp. this code would make more sense in lisp than in abused-javascript. the ultimate implementation of string passing as a method of memory access is one of the worst headache-inducing paradigms in programming IMO. it’s bad in python and it’s bad here.
@@michaelthompson7217 yeah a CS class I took in college spent a lecture showing how to write classes like this in scheme and it was useful at the time for understanding how OOP works but its really not much more than that
@ThePrimegen PLZ go for all and every coding exercise of the SCIP book (Structure and Interpretation of Computer Programs). You can make a whole series about it, high content quality guarantied. It will open a whole new world and view to programming.
Pretty sure the authors point was not "Do it this way!" his point was to show how an OO system can be implemented using closures and higher order functions. The message passing here is of course very awkward in JavaScript, as you need to use strings to encode a message, which is not ideal. But the point is to show the concept, not to create something production ready.
The thing is that the author doesn't really make it clear what he's doing. He actually has a text in the beginning that says that he reimplement OOP with "FP" (if you can call it that), but that's just the picture description. Not part of the main article🤦. The intro is a meandering mess that's not at all connected to the rest of the article, unless you're looking VERY close and know a lot more than rhar article shows (LISP having closures AFAIK and apparently being the language where "object" was coined, presumably they did something similar). Also the author does all kinds of stuff that just doesn't make sense even with the aim you're suggesting. Perhaps I'm missing the purpose for some of them, but I've a really hard time finding it, so either don't do it or explain it.
When Alan Kay says message passing, he means calling methods: an object sends a message to another object by calling one of its methods. If the method has no parameters, it's just a signal. Otherwise the tuple of parameters is the message, thus message passing. Please understand the people and their historical context when trying to understand what they were saying.
Message passing is the idea, not the implementation. Early Smalltalk was actually implemented in terms of message passing, but was later changed to method invocation for performance reasons. For the programmer though, it looks like message passing. Similar story in Lisp, where early OO-Systems like Flavors were implemented using message passing, which didn't perform well and was also awkward to use (how do you pass such a call to "map"?) and so modern CLOS uses the method invocation approach. And although CLOS does not use message passing syntax either, it actually somewhat has a concept of a "message", messages being just generic functions. A concept which interestingly doesn't exist in JS, Java or C++.
Definitely, Functional programming is my choice!!! Elixir has been around for 10 years on top of beam (erlang from 80) and it is one of the best languages with a 'message' passing concept!
@@ThePrimeTimeagen javascript unfortunately gets concepts shoehorned into it quite a bit, because its the only browser-side language. i hope wasm can eventually take over and solve this
i like how the "fancy new functional way of making a class" is literally the issue js tried to solve by actually supporting `class` at some point. in the olden days that was all JS could do, to "make a class" you'd make a function that creates an Object with a bunch of data+functions before returning it
He basically said in order to achieve the double dispatch that makes OO message passing work, I am not going to use the features of the language and runtime that already provide this but I am going to write them myself every time I write a class. This insanity was particularly depressing as someone who learnt his OO as an undergraduate via Smalltalk and for whom Alan Kay was, and remains, an early hero.
What's so great about this article is that the basic implementation for finding the best grade doesn't change at all. There's just useless lines of OOP philosophy surrounding it. It still uses the 'not very semantic sounding' array and returns it in the end lol
I'm going to assume the `let _grades = grades` is probably a habit he developed from other functions that would mutate the function parameter. Also he's never mutating _grades, why not const? 😕 Edit: Could also be a habit from a different language? E.g. Declaring a private property with underscore?
The best part is that, if it's a type that will be copied by doing that, it's passed by value anyway. And any types (for example, an array of grades) passed in, will be passed to that variable by reference, so it literally does nothing.
I don't think the article suggests to use this, and instead it is trying to teach the deeper meaning of OOP by showing it as functions. Like the Turing machine in Minecraft videos.
8:06 I also thought that for a long time. Actually, modern js engines do not recreate them but just compile them once and return an alias bound with the context. So there is no issue of "creating" millions of functions in a loop, it behaves just like creating millions of small structs.
Thats what im confused about. I thought the function created and returned by a closure was only created once. Then that just uses the function reference to execute it. Can someone else chime in here and let me know what's actually happening?
I'm new to programming in JS, and the final implementation sounded confused as hell... It would be cool if Prime coded a better example about why that was bad right on stream, I would enjoy watching that!
well yeah as far as I can guess it's just a demo of how classes work under the hood in scripting languages the same way I could write c++ with typedef struct Class {void *(*vtable)(void *); ...} Class; not useful in real code but makes for an interesting demo
I'm really disappointed that the article didn't go into dispatch. I just don't understand why it ended where it ended with encapsulated state, dynamically created function objects, and mapping string literals to other dynamically created functions, when this is exactly what modern OOP languages already do, but better with classes and named methods. The article even started with notion that message passing can lead to decoupling and then went on to create the very coupled code that they were supposedly contrasting message passing to. There are lots of amazing ways in which OOP can be utilized and this is not one of them.
I think the author of the article didn't want to show actual practical code, but rather just talk about the original idea of OOP which is message passing (this was somewhat hinted at in the first 2 paragraphs but could have been explained better) and for some reason (too much coconut-oil? not enough coconut-oil?) decided to demonstrate how one would implement that concept in a functional style (for real though, I guess the reason was to reinvent something familiar in an unfamiliar way to really show how it works). And I guess Prime was looking for something cool/practical so expectations were mismanaged. I might be totally wrong though, but I'm not afraid of being wrong on the internet anymore!
I paused the video to learn more about Smalltalk, and yes, the author implements a basic ad-hoc Smalltalk runtime in Javascript. However - Smalltalk messages are just methods. There's no point in doing it this way since JS already has that feature. Also now that I understand Smalltalk's deal, C++ and Java do the same thing but using vtables instead of messages under the hood and that's great because it's usually faster to lookup an address of a function in a statically known precomputed set of vtables than to do a recursive dynamic lookup through said vtables. Meaningful usecases for messages as the dispatch mechanism are if you plan to break ABI between dynamic libraries and still want to keep legacy components (Objective-C does that) or in asynchronous multi-threaded environments (Elixir does that). It's just unnecesary to incorporate it to something like JS where there's no ABI, everything is single-threaded, and if you're doing RPC you'd probably like the tooling to implement message passing for you. I'm confused.
In Smalltalk, if an object receives a message it does not understand, it results in a "doesNotUnderstand" message being sent to the object, which has an implementation in class Object that can be the fallback if not overridden. Typically, this invokes the debugger (allowing the user to define a method to respond to the message)
Renaming local variables to have a leading underscore to indicate privacy inside a closure where variables are going to be private by default is... interesting.
Their mind will be blown! Imagine this, instead of carlos("get-best-grade") carlos("get-best-grade")() They can do () => carlos.getBestGrade() carlos.getBestGrade()
Glad I'm not the only one who reacted to the article getting this part wrong. The only time I used Simula was in a class at the University. Not a bad language for it's intended purpose, writing simulations.
Javascript and Typescript both already have Message based OOP built in. class Name extends EventHandler, The entire article is a Rube Goldberg implementation of an EventHandler.
Idk Erlang has been around for a long time now and does this properly. Why this is being done in JS is beyond me. Just do it in Erlang, or even elixir.
@2:51 I think it's ideal when the system simply ignores unmapped messages, so that a 404 response is part of the protocol you decide to implement and not an imposed by the language. 6:37 not a surprise that a book titled: "Javascript, the good part" exists.12:01 wow, that looks like an actor on Erlang. What a nice combo: Erlang + Js.
I think this was mostly to show how Alan Kay intended OOP - more of a focus on message passing, less on object code (if that makes sense). But squinting at Alan Kay's idea, I just get he tried implementing a shitty version of how Kafka works - a weirdly coupled pub-sub structure. Then again: I've never written a line of Smalltalk, so I also don't know what I'm talking about.
It's similar to a reducer in the react ecosystem. The message can be a discriminated union to make it work with typescript which helps if we want to make exhaustive checking if we want to make sure all types of messages are handled. Also, with the discriminator, we can now infer the contents of the message correctly. But it doesn't mean that we can make it work then we should do it.
The point of the article is not to show example if good code. The point was to show the connection between FP and OOP by implementing classes with functions and functions only. One of the implications is that if you have a cool feature in OOP you are guaranteed to be able to implement it in FP as well and vice versa.
Want Typescript to work with this mess, here's an example ( please please don't do this in real code PLEASE ) type Messages = 'do' | 'not' | 'do' | 'this' function shit(msg: Message) : Message extends 'do' ? () => false : Message extends 'not' ? () => 'yes' : ... If you do this the TS language server dies of cringe basically
I absolutely love that the author managed to reference the hero image from a different webpage, but didn't reference anything about the Alan Kay's message sending idea. _Priorities_
The stuff you see at about 14:00 is fairly similar to parts of Redux. And yeah, Redux isn't easy to properly type in Typescript - and very easy to fuck up or get very repetitive. I have heard that now there's default tools for it, but back when I had to work with that stuff it wasn't a thing. So after seeing a shitton of train wrecks I spent a decent amount coming up with a way that was properly typed and not repetitive, it relied on a decent but of type magic tho. That kind of magic is only possible in TS, well that is the only language I know it to work. Did stuff like "as const" casts, return type inference and getting the return type using helpers provided by TS, then making one big union type. Also, bruh, that Author doesn't know anything. I don't agree with all your comments, they are mostly about the performance, which that author may just not care about, but he also just doesn't know what he's talking about.
What blog-post-author does not grasp is that a member function call is THE SAME THING as passing a message to that object (a synchronous one to be exact). What he did was basically just circumvent language-level concepts to achieve the same thing. Nice for getting a general feel about what it means to send a message, but that's about it...
let _grades = grades is creating a closure on the variable. In functional spirit, this ensures the function is thread-safe...Perhaps moot because JS is single-threaded. But the code makes sense.
I saw some videos on Smalltalk by seasoned people who used it then and having wastly diffrent perspective than today language archeologists. As i understand what they say: Back then objects was like nanoservices - independent entity to whom you send letters or like Erlang processes with mailbox. Our today "objects" look silly in this neighbourhood.
I've used inheritance with actual benefit when I made a radix tree that finds me a hierarchical answer and it allowed me to speed up the program. Yet it's a tree and not oop in the sense that we think of it as.
ruby style message passing within js is what it looks like the author was going for, which is odd since there are better ways in js to do this like using Proxy
I feel like this is someone who saw a neat little idea about how you can reimplement OOP concepts in a purely FP language, but didn't really understand the idea, and also doesn't use a purely FP language, but decided to write an article about it anyway.
Better to implement this in C, or Zig, with a couple of thousand lines of code in every translation unit. I'm somewhat serious. It's like the old meme about the one-legged stool in the nitroglycerin factory. It's very unstable but that's exactly why it's good, it forces you to concentrate on what you're doing! :)
Read up on the Actor Model. It's what OOP should have been. It's not that nothing happens when you send an invalid message it's just that you have the option to handle it or ignore it without using try-catch all over the place. The actor mode is also great for asynchronous programming. No need for locks.
The extent to which we should be using OOP has pretty much been solved and this is far beyond even what Java users are comfortable with. At the data level a typical Spring developer would group data around an entity as a data transfer object and outside of type conversion put no additional logic into the class, doing so only encumbers the type and makes refactoring more difficult. The business logic would go into a service instead. More strict OOP principles are largely applied at the framework level and for entities that cannot easily change, like database connectors, webviews, the application context etc. The most practical OOP you'll see a developer add to a spring app is to encapsulate an entity such as a database connector or http client within a service who exposes all interfaces by which that entity can be invoked. If you go beyond that it is likely that you don't understand the problem you are trying to solve and make your code hard to extend and hard to read. OOP is a good way to conceptualize your code and it is a great basis for creating the entities within your application. That does not mean that the entities within your code need to be first class citizens within the business logic of your application. The same applies to functional programming, at its heart true functioning programming with no side effects is neither possible nor is pursuing more functional code at any cost desirable. But where you can it makes a lot of sense to separate out business logic from a database call and not bury the side effects deep within the abstraction. Nowadays a lot of Spring development will have a great deal of OOP at the framework level, procedural code within a service and a compositional approach to connectors and business logic where the business logic is written more functionally, returning a value to be sent off by the connectors. Dogmatically holding on to any one paradigm will make code rot faster than anything else.
And to make things even WORSE, this code will always start with let base=Person(args from Student) BUT only uses base in the DEFAULT case :rolleyes: Why not skip "base" entirely, AKA {default: Person(args)(message)} instead of {default: base(message)} :sigh:
this to me is the direction OOP should go, because sometimes it just really makes sense to have a class because having a complex object with certain functionality is great, but other times you end up making classes to just be able to put functions in them
I think the real issue here still remains unstated. I see this everywhere I go: 1) most people talking about functional JS don't understand functional programming, like at all. And 2) seeing this whole debate through the lens of a language like JS is a mistake to begin with; languages DO matter when it comes to programming paradigms. Most "functional JS" code is just OOP replication using closures. This is possible because JS (or even TS) doesn't really have immutable closures. Closures don't work anything like this in real functional languages i.e the ones that promote pureness. So, it makes zero sense to call code that looks like this functional. The JS world seems to be have taken a wrong turn at some point and ended up in a completely different corner of the programming landscape, where so many things bleed mutability that the simple act of using functions looks passable as FP. It's like how in the US you get to be right-wing af in every axis possible and still pass as a lefty. The React world is the biggest offender imo. Hooks are quite literally just a way to achieve what you would with objects for functions -- internal, mutable state. And yet, almost everyone seems to be convinced that rewriting code that uses class components into function components automagically makes their code functional.
You missed the point, I can't blame you though since the article doesn't even know what it's about. This is just explaining how you can encode objects with closures. The big take away should be a closure is equivalent to an object with 1 method. Doing this in a language with native support for objects just confuses the lesson though, should have done this in lisp or haskell.
This is how chaotic evil programmers write code
Too much philosophy behind it to be chaotic.
This very much feels like Lawful Evil.
They're extremely determined to do *bad* things. And they'll follow rigid rules and guide lines to do *bad* things.
As a Chaotic Evil, I prefer not being grouped together with this fellow. Makes too much sense.
Feels like _a lot_ of effort to just do something you can do better and more easily.
i feel this heavily
bro just re-created the worse parts of javascript in userland. i heard you like slow runtimes
@ThatGuyJamal
?
@ThatGuyJamalbut one is fast and robust while the other isnt
@ThatGuyJamal This is true.
My entire OOP experience. Hours of philosophy to create code that doesn't make sense w/o that philosophy and blows up on a simple structural change due to all the coupling.
my functional experience as well. I remember eric elliott, guy from medium, overcomplicating things with transducers and react hocs
naturally the js ecosystem is a mess, if guys like this have much influence
@@guillemgarcia3630 I despise people who add React to other languages. It's a disease. Cancerous.
@@guillemgarcia3630 I just read his article on transducers, and it seems a bit misapplied in JavaScript.
They're great for Clojure because they solve real problems the language had. I wish people would analyze tools in context rather than thinking they apply to every language. Similarly, I think monads are a bad choice for dynamic languages, but great for static languages. Yet you still see people trying to stuff them into Elixir.
@@guillemgarcia3630 Good ol' procedural FTW!
@@bobbycrosby9765 Totally agree. It feels like JS is not designed for complex FP patterns. It becomes super awkward and unreadable af
Sounds like a 'junior' trying to over-engineer something and they end up with a mess, also being very opinionated about it
i mean, the concept of message passing passing is a popular concept, but what was created here...
"former CTO" he says in his bio
@@stringnerd 😂
Dude saw a wheel and said "I could do a better job" and added corners. Stop reinventing the wheel, your square wheel is not better! 😂
it was crazy
The origins of object-oriented programming (OOP) can be traced back to the development of the Simula programming language in the 1960s by Ole-Johan Dahl and Kristen Nygaard at the Norwegian Computing Center. Simula was originally designed for simulating real-world systems, and it introduced the concepts of classes and objects, which are now fundamental to modern OOP languages.
Simula's innovations in OOP inspired the development of other programming languages, such as Smalltalk. It's annoying when some people wrongly cite the history of OOP, then proceed to be is super opiniated it.
Imagine a function that I could pass any array of grades in. One student or the whole school, the function wouldn’t care. It would just return the best grade of the input set.
Now wouldn’t THAT be cool 🤔
When there's that much brainrot going into an article it's easy to forget simple things like this 😂
Better yet, what if we had a max function, so it doesn't even need to be a grade? Any number will work. Hell, it doesn't even need to be a number. It just needs to implement the `Ord` trait.
Best way to put it lol... One of the best things a programmer can do for themselves is creating logic that is direct and as generalized/simple as possible without making compromises.
The article literally starts off by saying ''Well we could rename the function to better indicate usage, or [we can create a complicated web of indirection and run-time bloat]''(in so many words)
Rename the function ''GetBestGradeFromArray'' - and the entire codebase as well as everyone involved will be happier.
"An idiot admires complexity, a genius admires simplicity" Terry Davis (TempleOS)
Easy. We can just create a Students functional class thingamajig that take in multiple Student functional classes and then have a “function” that iterates over all the _students to get the max and return the max of that.
Simple. Efficient.
Oh my gosh ...if I were a jr programmer at Netflix I would be so nervous whenever Prime is reviewing my code. 😂
hah. i would assume you wouldn't take a silly 10 line function and turn it into 30 lines....
@@ThePrimeTimeagen that would be atrocious.
You could avoid half the chaos energy by using prettier.
This looks kinda' similar to how objects are implemented in the Structure and Interpretation of Computer Programs video lecture series.
I guess the point of the article was to teach how you can build a thing which behaves like built-in objects using simpler parts-ignoring the fact that what you have created is a monster. That is, the point was not to teach a programming technique but to transmit a conceptual understanding.
For comparison: I could roll my own vtables in C if I needed them. I hope I won't need them, but I really like knowing how to. This article might have expanded someone's mind the same way my mind was expanded when I understood that.
With that in mind, I don't find the article objectionable.
I love how one of the first paragraphs is "we need to understand what is message" and then doesn't explain it. 😂
Just found your channel recently and I didn't know just how much I needed an angry developer to aggressively afirm me
It's clear from the last paragraph that he's not recommending that code style. It's designed that way to DEMONSTRATE what message passing is. He should have brought it back to idiomatic JS and pointed out where the message passing happens.
I got out of bed at 5am to keep programming cause I couldn't sleep and this is going to be good entertainment
I think the author of the article missed the chapter on prototypes, prototype chains, and prototypal inheritance in JavaScript. Oddly enough, that's one of the main things that differentiates JavaScript from other languages.
I actually think this is great, it's so flexible that you can just override all properties inherited by the prototype, it defeats the coupling problem of inheritance.
Also, if you're mad enough, you can implement abstract classes and interfaces by adding methods that throw an exception that tells you to replace the method with a new one. Don't recommend it but i did that on one older project that I started in JS and couldn't be bothered to port it to typescript.
The argument for FP has never been speed. Fans of FP tend to believe that their programs tend to be more correct. Hard to measure, so who really knows. I do think that there are lessons to be learned from that world, that will improve your programs, regardless of language or paradigm.
Also, Rust is the only language that I know of that takes correctness seriously without going full FP.
EDIT: The example in the article has nothing to do with anything that the hard core FP people are talking about though. Creating class-like functions with internal state is literally just a less readable way to write OOP.
I program in Haskell because I like feeling superior to OOP plebs.
yeah this article makes me sad. but "functional oo" is a real thing. if you initialize a class with immutable state, and have n number of functions produce values based on the initial state, and pass in any other dependencies you need...aka a decorator that doesn't mutate anything. also called a value object, if nothing is mutated.
@@jearsh memory cost. If you could dealloc in 1 instruction - yes
Yes, that is my understanding as well.
If I understand correctly, there is a solid case that OOP was designed to optimize for resources (eg memory/storage/processor), that today are cheap and fast so it makes more sense to optimize for code that is more maintainable (obviously there is a balance here that is different for each scenario).
For example, in most projects I have been on, hardware limitations have not really been significant issues. But mutable state in the domain logic, and over-abstraction have been.
It's a similar point for Event type storage vs just overwriting data in the DB. Basically, that there are some trade offs like eventual consistency and more storage costs, but all the stuff you're storing is worth it.
Functional programs do not tend to be "more correct", but their correctness is usually easier to prove. Rust does offer a useful middle ground, though, as smaller blocks are usually easy to reason with using Hoare logic.
I think the idea is that you don't need to have OOP built in to use inheritance and all that. It's not about how it's nicer to read or anything, just that classic Message Passing can be done at all.
To reiterate, I'm big into FP (Elm, Haskell etc), and I don't think the article was saying 'write JS like this', but more 'if you were curious about how it originally worked, it would work like this'.
The author didn't talk about immutability or referential transparency at all, which is a huge part of why writing frontends in Elm is so nice.
The absolute best example to show someone would be an example of code from a functional language, and explain what's going on.
For someone that knows javascript, it could be teaching bad lessons. For someone like me that doesn't know any javascript, the choice to use it as an example provides no actual benefit.
@@Hazanko83 I think it's a numbers game. In 2023, more programmers know JS than not, I think.
I get your point though, it doesn't show things off as well as it could in another language that plays to its benefits.
This whole article was edging me. I was excited for them to say "look! This is just partial application! And it's a really powerful model when combined with immutability, and a syntax to support it!". Then there was the conclusion and now I'm blue balled.
Prime is too optimistic. I knew this wasn’t going to end well when we started returning different functions based on a switch statement.
bro literally took the class functions and made them being called with a magic string . OMFG
This is brilliant!
If i ever get pissed off with my employer i'll push this through - refactor all the code to match that pattern and then just quit.
After now 20 years of software engineering. I never needed multi inheritance, not once. Actually, all problems could be solved without inheritance at all. Interface where nice sometimes, but thats it. OOP and Polymorphism is the bain of software engineering. It leads to slow and hard to debug code. Add Pointers into the mix and the disaster is inevitable.
Better support for abstract algebra is all is needed.
All cases for inheritance can be solved with composition if your language supports something like interfaces. Sometimes inheritance is less code, but meh.
@@KyleSmithNH Ok, give me one real life example. :)
@@voidwalker7774 A real life example where composition can replace inheritance or where inheritance is less code? Or what?
OOP is not inherently bad by the way, people simply overcomplicate things, and not being able to have functions as first class citizens is probably the biggest issue, because that means you create classes just to access a function, which is unnecessary overhead for no good reason.
The only "problem" with multiple inheritance is the diamond problem. Which is only a problem in C++ because C++ sucks.
So you're telling me... They would rather manually type obj('string-message') that is not autocompleted in ANY way, than just do a obj.functionName, that depending on how things are set up will likely be autocompleted, or at least suggested by intellisense sometimes?
I don't like classes, but doing this just to avoid using the keyword is pretty crazy. I'd rather go back to writing ConcreteAbstractFactoryBeans in java than implement function-classes.
if you do this in any language, immediately you are having to create a mental mapping between objects and their string translation. huge headache
its an exploratory analysis into oop and functional representation of classes, its not meant to be viewed as actual code just oooo. i wonder if 🤔
I'm new to programming. I'll still be new to programming for the next 5 years, because the more I learn about OOP, the more I just don't get it. What's the point? What's a class? What's an object? What is the entire nuclear family doing with their generational wealth, and why does the oligarchy even exist in my CPU? WTF is polymorphism, and do they also attend swinger parties?
I keep picking up tiny little bits via osmosis just by watching videos like this, and every time I do, I conclude that the only reasonable solution to any programming problem is return to monke (AKA procedural), apes together stronk, and maybe eat the rich to get the oligarchy out of my CPU. I don't get functional programming either, but when you say "functional programming was created as a reaction to how bad OOP is" I can definitely understand why I would subject myself to the mental gymnastics required to learn Haskell. And, the more I learn, the more I thank God that my deep contrarian streak caused me to reject OOP outright, _because_ it was popular.
I feel like this is way more complicated than just using classes to encapsulate functionality while keeping all methods pure, and implementing message broker as core component to please Alan Kay.
Prime was so upset he forgot his outro lmao
it happens...
What's the punchline Douglas. WHATS the PUNCHLINE, DOUGLAS
This is like an exercise one might do to try and understand OOP better and then immediately throw it away, not something one should write an article about on the internet saying it's what you should do
it’s also the wrong language to do this sort of thing which makes the argument 100x worse. if he is going to style up a lisp-y looking object, he should do it in lisp. this code would make more sense in lisp than in abused-javascript.
the ultimate implementation of string passing as a method of memory access is one of the worst headache-inducing paradigms in programming IMO. it’s bad in python and it’s bad here.
@@michaelthompson7217 yeah a CS class I took in college spent a lecture showing how to write classes like this in scheme and it was useful at the time for understanding how OOP works but its really not much more than that
The article should've been titled: "How to fuck up the Actor model side-ways. Getting all the cons without any pros"
The post should have showed us what SmallTalk message passing looks like because I can’t believe it’s like this.
@ThePrimegen PLZ go for all and every coding exercise of the SCIP book (Structure and Interpretation of Computer Programs).
You can make a whole series about it, high content quality guarantied. It will open a whole new world and view to programming.
Pretty sure the authors point was not "Do it this way!" his point was to show how an OO system can be implemented using closures and higher order functions. The message passing here is of course very awkward in JavaScript, as you need to use strings to encode a message, which is not ideal. But the point is to show the concept, not to create something production ready.
The thing is that the author doesn't really make it clear what he's doing.
He actually has a text in the beginning that says that he reimplement OOP with "FP" (if you can call it that), but that's just the picture description. Not part of the main article🤦.
The intro is a meandering mess that's not at all connected to the rest of the article, unless you're looking VERY close and know a lot more than rhar article shows (LISP having closures AFAIK and apparently being the language where "object" was coined, presumably they did something similar).
Also the author does all kinds of stuff that just doesn't make sense even with the aim you're suggesting. Perhaps I'm missing the purpose for some of them, but I've a really hard time finding it, so either don't do it or explain it.
When Alan Kay says message passing, he means calling methods: an object sends a message to another object by calling one of its methods. If the method has no parameters, it's just a signal. Otherwise the tuple of parameters is the message, thus message passing.
Please understand the people and their historical context when trying to understand what they were saying.
Message passing is the idea, not the implementation. Early Smalltalk was actually implemented in terms of message passing, but was later changed to method invocation for performance reasons. For the programmer though, it looks like message passing. Similar story in Lisp, where early OO-Systems like Flavors were implemented using message passing, which didn't perform well and was also awkward to use (how do you pass such a call to "map"?) and so modern CLOS uses the method invocation approach. And although CLOS does not use message passing syntax either, it actually somewhat has a concept of a "message", messages being just generic functions. A concept which interestingly doesn't exist in JS, Java or C++.
Definitely, Functional programming is my choice!!! Elixir has been around for 10 years on top of beam (erlang from 80) and it is one of the best languages with a 'message' passing concept!
agreed, but its a language designed around a concept, not a concept shoehorned into a language ;)
@@ThePrimeTimeagen javascript unfortunately gets concepts shoehorned into it quite a bit, because its the only browser-side language. i hope wasm can eventually take over and solve this
if only Elixir wasn't dynamically typed...
Yup I remember stumbling into this specific article once... hated it. I feel so vindicated right now, thank you for this confidence boost sir
Great primer on code obfuscation and on how to get the mythical "Changes Requested - Merging is blocked"
Oh my godness, this blog post is going into my cringe folder. How did he manage to make such an easy to read function into such a mess? Impressive.
there is someone out there that thinks this is better
@@ThePrimeTimeagen there's 1.6k of them apparently
i like how the "fancy new functional way of making a class" is literally the issue js tried to solve by actually supporting `class` at some point. in the olden days that was all JS could do, to "make a class" you'd make a function that creates an Object with a bunch of data+functions before returning it
He basically said in order to achieve the double dispatch that makes OO message passing work, I am not going to use the features of the language and runtime that already provide this but I am going to write them myself every time I write a class.
This insanity was particularly depressing as someone who learnt his OO as an undergraduate via Smalltalk and for whom Alan Kay was, and remains, an early hero.
What's so great about this article is that the basic implementation for finding the best grade doesn't change at all. There's just useless lines of OOP philosophy surrounding it.
It still uses the 'not very semantic sounding' array and returns it in the end lol
ahah Fully agree with the initial opinions about Medium. Imagine being a blogging company known for low quality posts!
I'm going to assume the `let _grades = grades` is probably a habit he developed from other functions that would mutate the function parameter. Also he's never mutating _grades, why not const? 😕
Edit: Could also be a habit from a different language? E.g. Declaring a private property with underscore?
The best part is that, if it's a type that will be copied by doing that, it's passed by value anyway.
And any types (for example, an array of grades) passed in, will be passed to that variable by reference, so it literally does nothing.
The road to hell is paved with good intentions. The road to bad code is paved with misunderstood paradigms.
The keywords 'get' and 'set' are more than enough. That's why we implemented them in JavaScript...
9:02 Literally that's me reviewing code "What the hell that means" and "Stop it".😆 Thanks for idea that "I would fistfight for..."
I don't think the article suggests to use this, and instead it is trying to teach the deeper meaning of OOP by showing it as functions. Like the Turing machine in Minecraft videos.
I love watching Prime freaking out at the “dys-functional” FP crowd. Where have you been the last 9 years!!!?
8:06 I also thought that for a long time. Actually, modern js engines do not recreate them but just compile them once and return an alias bound with the context. So there is no issue of "creating" millions of functions in a loop, it behaves just like creating millions of small structs.
Thats what im confused about. I thought the function created and returned by a closure was only created once. Then that just uses the function reference to execute it. Can someone else chime in here and let me know what's actually happening?
I'm new to programming in JS, and the final implementation sounded confused as hell...
It would be cool if Prime coded a better example about why that was bad right on stream, I would enjoy watching that!
The title should be "how to recreate the prototype chain"
The returned closure is just the "getter"
How I Create The Prototype Chain in 3 simple steps!
well yeah as far as I can guess it's just a demo of how classes work under the hood in scripting languages
the same way I could write c++ with typedef struct Class {void *(*vtable)(void *); ...} Class;
not useful in real code but makes for an interesting demo
I'm really disappointed that the article didn't go into dispatch. I just don't understand why it ended where it ended with encapsulated state, dynamically created function objects, and mapping string literals to other dynamically created functions, when this is exactly what modern OOP languages already do, but better with classes and named methods. The article even started with notion that message passing can lead to decoupling and then went on to create the very coupled code that they were supposedly contrasting message passing to. There are lots of amazing ways in which OOP can be utilized and this is not one of them.
This reminds me of that clip where the guy does the complicated milk carton technique and then it just spills everywhere
I think the author of the article didn't want to show actual practical code, but rather just talk about the original idea of OOP which is message passing (this was somewhat hinted at in the first 2 paragraphs but could have been explained better) and for some reason (too much coconut-oil? not enough coconut-oil?) decided to demonstrate how one would implement that concept in a functional style (for real though, I guess the reason was to reinvent something familiar in an unfamiliar way to really show how it works).
And I guess Prime was looking for something cool/practical so expectations were mismanaged.
I might be totally wrong though, but I'm not afraid of being wrong on the internet anymore!
What happened with the simple, readable, easy to maintain etc function from the beginning of the article? Why did they mangled it this way?
This is basically what Crockford recommends in JavaScript the good parts. The revealing module pattern, if I recall.
Didn't he explicitly say never to use class and that it's one of the worst newer additions to JS?
@@alexk.7064 more or less, yes.
ruclips.net/video/PSGEjv3Tqo0/видео.html#t=1395
We all wasted 18mins of our lives! , I feel your pain going through the article.
I paused the video to learn more about Smalltalk, and yes, the author implements a basic ad-hoc Smalltalk runtime in Javascript. However - Smalltalk messages are just methods. There's no point in doing it this way since JS already has that feature. Also now that I understand Smalltalk's deal, C++ and Java do the same thing but using vtables instead of messages under the hood and that's great because it's usually faster to lookup an address of a function in a statically known precomputed set of vtables than to do a recursive dynamic lookup through said vtables. Meaningful usecases for messages as the dispatch mechanism are if you plan to break ABI between dynamic libraries and still want to keep legacy components (Objective-C does that) or in asynchronous multi-threaded environments (Elixir does that). It's just unnecesary to incorporate it to something like JS where there's no ABI, everything is single-threaded, and if you're doing RPC you'd probably like the tooling to implement message passing for you. I'm confused.
In Smalltalk, if an object receives a message it does not understand, it results in a "doesNotUnderstand" message being sent to the object, which has an implementation in class Object that can be the fallback if not overridden. Typically, this invokes the debugger (allowing the user to define a method to respond to the message)
Function creation in runtime can get way more expensive than just stackframes. They can be entire objects on various situations.
Renaming local variables to have a leading underscore to indicate privacy inside a closure where variables are going to be private by default is... interesting.
Someone, quick, tell author of that article that there's a new feature in javascript - prototype's!!
Their mind will be blown!
Imagine this, instead of
carlos("get-best-grade")
carlos("get-best-grade")()
They can do
() => carlos.getBestGrade()
carlos.getBestGrade()
1:00 Simula was the first language with OOP, not Smalltalk
Glad I'm not the only one who reacted to the article getting this part wrong. The only time I used Simula was in a class at the University. Not a bad language for it's intended purpose, writing simulations.
watching this explanation was like going back in time to the late 90s / early 2000s through JavaScript de-evolution.
Javascript and Typescript both already have Message based OOP built in.
class Name extends EventHandler,
The entire article is a Rube Goldberg implementation of an EventHandler.
Idk Erlang has been around for a long time now and does this properly. Why this is being done in JS is beyond me. Just do it in Erlang, or even elixir.
@2:51 I think it's ideal when the system simply ignores unmapped messages, so that a 404 response is part of the protocol you decide to implement and not an imposed by the language. 6:37 not a surprise that a book titled: "Javascript, the good part" exists.12:01 wow, that looks like an actor on Erlang. What a nice combo: Erlang + Js.
I think this was mostly to show how Alan Kay intended OOP - more of a focus on message passing, less on object code (if that makes sense).
But squinting at Alan Kay's idea, I just get he tried implementing a shitty version of how Kafka works - a weirdly coupled pub-sub structure. Then again: I've never written a line of Smalltalk, so I also don't know what I'm talking about.
It's similar to a reducer in the react ecosystem.
The message can be a discriminated union to make it work with typescript which helps if we want to make exhaustive checking if we want to make sure all types of messages are handled. Also, with the discriminator, we can now infer the contents of the message correctly.
But it doesn't mean that we can make it work then we should do it.
That bit about referencing a function x creating a new one was so instructive, thank you
The suggestion of implementing multiple inheritance at the end surely shows it's a meme
Technically, Simula was the first OOP language (early 1960s), developed in Norway.
The point of the article is not to show example if good code. The point was to show the connection between FP and OOP by implementing classes with functions and functions only. One of the implications is that if you have a cool feature in OOP you are guaranteed to be able to implement it in FP as well and vice versa.
They even mentioned in the conclusion it was humble. But they also mentioned multiple inheritance
all of this to avoid using "class" keyword and methods?
I almost blackout with that space between the function and it's name. JSML sound so fun, lol.
Want Typescript to work with this mess, here's an example ( please please don't do this in real code PLEASE )
type Messages = 'do' | 'not' | 'do' | 'this'
function shit(msg: Message) : Message extends 'do' ? () => false : Message extends 'not' ? () => 'yes' : ...
If you do this the TS language server dies of cringe basically
sounds like a ts language server problem
i am a fan of cringe deaths
@@CYXXYC The TS language server is slow and unreliable as it is and if you start doing this it just blows up
@@TechBuddy_ ah just like any other microsoft product (assuming ts is all microsoft)
@@CYXXYC exactly yess
How to ensure a project is unmaintainable. This is the purest form of chaotic evil😂😂
My program works because the syntax looks good. 1.6k claps
I absolutely love that the author managed to reference the hero image from a different webpage, but didn't reference anything about the Alan Kay's message sending idea. _Priorities_
The stuff you see at about 14:00 is fairly similar to parts of Redux.
And yeah, Redux isn't easy to properly type in Typescript - and very easy to fuck up or get very repetitive. I have heard that now there's default tools for it, but back when I had to work with that stuff it wasn't a thing. So after seeing a shitton of train wrecks I spent a decent amount coming up with a way that was properly typed and not repetitive, it relied on a decent but of type magic tho.
That kind of magic is only possible in TS, well that is the only language I know it to work. Did stuff like "as const" casts, return type inference and getting the return type using helpers provided by TS, then making one big union type.
Also, bruh, that Author doesn't know anything. I don't agree with all your comments, they are mostly about the performance, which that author may just not care about, but he also just doesn't know what he's talking about.
Redux toolkit, the *default* way to use Redux in any new app.
What blog-post-author does not grasp is that a member function call is THE SAME THING as passing a message to that object (a synchronous one to be exact). What he did was basically just circumvent language-level concepts to achieve the same thing. Nice for getting a general feel about what it means to send a message, but that's about it...
let _grades = grades is creating a closure on the variable. In functional spirit, this ensures the function is thread-safe...Perhaps moot because JS is single-threaded. But the code makes sense.
I saw some videos on Smalltalk by seasoned people who used it then and having wastly diffrent perspective than today language archeologists.
As i understand what they say:
Back then objects was like nanoservices - independent entity to whom you send letters or like Erlang processes with mailbox.
Our today "objects" look silly in this neighbourhood.
I've used inheritance with actual benefit when I made a radix tree that finds me a hierarchical answer and it allowed me to speed up the program. Yet it's a tree and not oop in the sense that we think of it as.
I _think_ he was trying to explain how to use FP with closures to do OOP things, not using this in real production code
...I _think._
...I hope.
ruby style message passing within js is what it looks like the author was going for, which is odd since there are better ways in js to do this like using Proxy
I feel like this is someone who saw a neat little idea about how you can reimplement OOP concepts in a purely FP language, but didn't really understand the idea, and also doesn't use a purely FP language, but decided to write an article about it anyway.
The article actually looked promising originally until it rapidly spiraled into an absolute mess.
I feel the whole point of message passing was missed. The author must have had a very confused mind at that moment
Better to implement this in C, or Zig, with a couple of thousand lines of code in every translation unit. I'm somewhat serious. It's like the old meme about the one-legged stool in the nitroglycerin factory. It's very unstable but that's exactly why it's good, it forces you to concentrate on what you're doing! :)
Read up on the Actor Model. It's what OOP should have been. It's not that nothing happens when you send an invalid message it's just that you have the option to handle it or ignore it without using try-catch all over the place. The actor mode is also great for asynchronous programming. No need for locks.
Prime, with all the hate of Javascript, what is your approved way of doing front-end webdev programming? Language/lib/framework?
The extent to which we should be using OOP has pretty much been solved and this is far beyond even what Java users are comfortable with. At the data level a typical Spring developer would group data around an entity as a data transfer object and outside of type conversion put no additional logic into the class, doing so only encumbers the type and makes refactoring more difficult. The business logic would go into a service instead. More strict OOP principles are largely applied at the framework level and for entities that cannot easily change, like database connectors, webviews, the application context etc. The most practical OOP you'll see a developer add to a spring app is to encapsulate an entity such as a database connector or http client within a service who exposes all interfaces by which that entity can be invoked. If you go beyond that it is likely that you don't understand the problem you are trying to solve and make your code hard to extend and hard to read.
OOP is a good way to conceptualize your code and it is a great basis for creating the entities within your application. That does not mean that the entities within your code need to be first class citizens within the business logic of your application. The same applies to functional programming, at its heart true functioning programming with no side effects is neither possible nor is pursuing more functional code at any cost desirable. But where you can it makes a lot of sense to separate out business logic from a database call and not bury the side effects deep within the abstraction. Nowadays a lot of Spring development will have a great deal of OOP at the framework level, procedural code within a service and a compositional approach to connectors and business logic where the business logic is written more functionally, returning a value to be sent off by the connectors. Dogmatically holding on to any one paradigm will make code rot faster than anything else.
JEEZZMUL ahahhaha EPIC Prime in his natural habitat :)
And to make things even WORSE, this code will always start with let base=Person(args from Student) BUT only uses base in the DEFAULT case :rolleyes:
Why not skip "base" entirely, AKA {default: Person(args)(message)} instead of {default: base(message)} :sigh:
Functional OOP? You mean when you only have 2 to 3 classes and the rest is functions and data?
this to me is the direction OOP should go, because sometimes it just really makes sense to have a class because having a complex object with certain functionality is great, but other times you end up making classes to just be able to put functions in them
There is two types of people, those that love OOP, and those that not program in python.
this was painfull.. and the NESTING!!! OH GOD THE NESTING!!
I think the real issue here still remains unstated. I see this everywhere I go: 1) most people talking about functional JS don't understand functional programming, like at all. And 2) seeing this whole debate through the lens of a language like JS is a mistake to begin with; languages DO matter when it comes to programming paradigms. Most "functional JS" code is just OOP replication using closures. This is possible because JS (or even TS) doesn't really have immutable closures. Closures don't work anything like this in real functional languages i.e the ones that promote pureness. So, it makes zero sense to call code that looks like this functional. The JS world seems to be have taken a wrong turn at some point and ended up in a completely different corner of the programming landscape, where so many things bleed mutability that the simple act of using functions looks passable as FP. It's like how in the US you get to be right-wing af in every axis possible and still pass as a lefty. The React world is the biggest offender imo. Hooks are quite literally just a way to achieve what you would with objects for functions -- internal, mutable state. And yet, almost everyone seems to be convinced that rewriting code that uses class components into function components automagically makes their code functional.
Article title should be "OOP is bad, here's something worse".
You missed the point, I can't blame you though since the article doesn't even know what it's about.
This is just explaining how you can encode objects with closures. The big take away should be a closure is equivalent to an object with 1 method.
Doing this in a language with native support for objects just confuses the lesson though, should have done this in lisp or haskell.