To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/GavinFreeborn . The first 200 of you will get 20% off Brilliant’s annual premium subscription.
@@user-tx4wj7qk4t Static typing is not necessary to have a useful language. Immutability makes the typing issues generally a lot less problematic than typing issues in something like JS.
@@olaniyanayodele5986 I started off doing code puzzles on www.codewars.com/. Looking at the top voted solutions and comparing it to my own was very helpful in learning some best practices. I have also been doing puzzles at adventofcode.com/. Now I have a couple of small hobby projects going where I'm learning to use some of the popular libraries (like megaparsec, servant, aeson) A great tutorial series here on youtube: Haskell for Imperative Programmers www.youtube.com/@philipphagenlocher I have been listening a lot to a Haskell podcast here on youtube called @HaskellWeekly. They have short episodes covering one topic per episode: www.youtube.com/@HaskellWeekly I found a couple of online books that look promising (but for me personally I learn faster by doing real projects and through youtube): book.realworldhaskell.org/read/ (The author of this one has an old but great talk here: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ZR3Jirqk6W8.html) learnyouahaskell.com/chapters Let me know if you know any other good resources!
I totally agree. Having worked with haskell professionally for several years, I have to say, with a well designed haskell code base, different layers of the app well layed out, and domains well modelled. It's not only very easy to test, scale, but it's also almost impossible for newcomers to screw up. Also refactoring is very cheap. And yeah STM is amazing for concurrency/transactions. Haskell is the only language I reach out for other than Bash. I have had to work with several other languages in the past, but nothing, I mean nothing really beats Haskell for my needs.
Rust actually compiles iterators into a single for loop, and doesn't loop through a whole collection at every Iterator method. But what haskell does is still impresive
I'm writing a book on Haskell, because I found Haskell documentation to be really messy and inefficient. They don't talk to developers, they tend to talk to mathematician wannabes. Hope it will help.
Good luck on that. It would be nice to have something aimed more at people with experience programming rather than studying abstract algebra :) though I must admit it did lead me to learn quite a bit about abstract algebra.
The way you described the documentation might be just the most spot-on description of it I've heard. I hope your book will be just as spot-on, fingers crossed :)
@@vikingthedude Not a website. A simple PDF (maybe an epub, but that's not currently a goal). I really dislike websites for long-term documentation, core concepts and explanations. PS: it's been a while since I contributed to it, I should get back to it.
I don't know who said this, but the quote was some version of "I love writing Haskell code, and I hate everything about Haskell that's not the writing code part." And I very much agree with the sentiment. The toolchain is really just... not great. That's why things like OCaml are gaining such popularity when it comes to functional languages, imo. A language success these days is (and should be!) more than just about the language, but also about the tools to work with that language. Something like rust & cargo and so on.
That person was Tsoding, and while his experience in the language *was* accurate, it is not anymore. The ecosystem has grown a lot since then and it's way more nice to use than your `npm`s and your `pip`s, which just so happen to be the package managers of the two most popular programming languages right now. Just go with Cabal, and you'll have a great time. As of right now, I would say Haskell's ecosystem is way better than OCaml's. Dune is really painful to work with in comparison to Cabal and it's much more annoying to learn.
In my experience ocaml has been substantially worse when it comes to tooling 😞. Constant issues with build tools and packaging. Maybe something big has changed in the last few years
don’t really know much about cabal, but, as alternative build tool, stack is really great, it’s very intuitive and i havent run into any problems with it, either way, things are for the most part, really great
@@ribosomerocker Cabal still cannot do simple things like add dependencies to your .cabal file. You don't even know how long it took me to get a project even started in Haskell, because I just could not understand why HLS wouldn't work with my version of GHC, or why cabal just wouldn't download files from the internet, or even just installing an IHaskell environment locally was impossible without running it in docker. The lib situation is also not great, you just get something super barebones. Compare that to Rust, which just works.
I also heard and believed this to be the case, but I don't think it's true. I am still new to the ecosystem so maybe it has improved a lot recently? For me the tooling has worked wonders! HLS is probably the most useful language server that I've worked with (comparing to Pyright for Python and clangd for C++). Cabal for me has also "just worked" and I've had less trouble with it than with Pip. One of my favourite tools is ghcid, which is truly amazing for iterating quickly. Come to think of it (having worked as a professional C++ programmer for 10 years) this is probably the best tooling I've used. Maybe I'm still in the honeymoon phase and haven't encountered the really bad parts yet...
All code is concurrent, but its stripped from languages and given to the Compiler to sort out. Time is stripped from languages, but unfortunately it exists on computers in like... reality. Things like CSP create temporal boundaries with channels and processes to give the compiler a much easier time of it. The reason we find concurrency hard is we are trained to ignore time. When we bump into time we're lost.
@@idiomaxiom Your right, but that's not what I meant. With imperative languages, programs primarily consist of statements executed step-by-step (yes, in practice CPUs break this assumption, but that's the mental model the programmer keeps in mind). In purely functional languages, the mental model is "expressions that evaluate to something". It's quite powerful, because it not only simplifies problems that aren't "execution", but more importantly it lets you model other approaches just as well. If you want step-by-step execution there are the ST and IO data types. If you need continuous time, you can go with FRP.
@@mskiptr Generally time exists in the compiler. Load A A + X Wait.... there are 200 cycles in between those. What would you like to do with them? Just isn't a thing. FP's current struggles largely come from trying to bake time back in. Somehow. We're getting there though.
@@idiomaxiom What do you mean it exists in the compiler? If this is about CPU instructions in codegen then sure, but that's just an implementation detail. It's unrelated to what the programmer usually has to keep in mind when writing code. If you want precise control over the machine code then use ASM, C or maybe Rust | C++. Or wait a couple years until I finally try implementing that 'assembly as a Haskell EDSL' idea I had some time ago. But also, that doesn't have to be the case. Pure FP code can instead be compiled to silicon circuits or whatever.
@@mskiptr A compiler wrangling concurrency is an implementation detail? Once FP handles time in its logic, you won't need ASM for tight execution control. ASM doesn't have time either, the Compiler or the developer currently has it.
The IO monad in Haskell is revolutionary. I suspect we won't see it directly in mainstream languages but I think we'll see purity-checkers appear in 10-20 years time because it's such a powerful feature for code maintainability.
I completely agree. Its something that doesn't seem as important at the beginning but as languages and their use expands it's value increases. A great example of this is the effect analysis system added to the Julia compiler. It's not perfect but extremely powerful
Functional Core Imperative/Reactive Shell is quite the dial just like Entity Component Systems. Feels like the biggest reasons to have imperative stuff in code that's supposed to be functional is either tech bravados who won't compromise in their messy core ideals or the company has no idea of the product's vision/overly reactive to customer demands. Just when you think the engineers have a "good enough" vision, all it takes is one seemingly harmless request before it all tumbles down as months of unnecessary refactoring effort are made from a house of cards that holds the architecture together.
the reason you need an imperative shell is to "drive" the functional core such that it's able to "interact" with users. otherwise your program would do nothing but heat up the cpu
@@zachary4725 That or all the calculations would only be done at compile time and the final program will just be null and void. As far as algorithms themselves, you would hope that compilers were smart enough to translate any functional block into a block that was either imperative or functional, whichever was faster, smaller, and more parallel/concurrency friendly. Maybe that day will come when CPUs permanently separate from the 80+ yo Von Neumann design, but for now, there will be a time and place for imperative and functional algorithms.
Hi Gavin, I never once used or even saw code for a functional programming language like Haskell. I've been thinking about it lately to learn a bit about either Haskell or Scala, but I don't know which would be better if your main purpose is to learn how recursion works or for improving your skills in algorithms. I don't know how true this is? But I read some article which stated learning a functional programming language can help you a great deal in understanding data structures and algorithms. Also, I was considering Scala over Haskell because I am already focused on Kotlin and I know JavaScript. I figured since Scala runs on the JVM maybe there is similarities from what I am learning with Kotlin? Anyways, I would be interested in hearing which would you recommend? Haskell or Scala? Or it doesn't matter? Anyways, thank you.
i’d say that you should go for haskell, it’s pure, so it (for the most part) forces you to think in functional terms without escape hatches, (like other languages do, especially regarding recursive functions and loops) it’s possibly more difficult to learn at first than scala (as far as i know, scala “cheats” a bit and, allows a more imperative approach) but is definitely worth it, it gives you a very difficult way to look at programming in general
@@rogergalindo7318 Great, thank you! I've been coding for about 1 year and a half with JavaScript now Kotlin. But I need something to twist and bend my mind and give me a different perspective in thinking. Thanks Roger. What is your recommended IDE or editor for Haskell?
Most people use vscode. I personally find Emacs to be great but wouldn't recommend investing time into learning it if the end goal is just to learn haskell. vscode is more than friendly enough
@@GavinFreeborn At the moment I don't have a clear defined goal with functional programming. It was something I was and am still considering to improve my skills in programming and gain a different perspective. But I've heard of Emacs as well as NeoVim and Vim. I am strongly considering these options, I appreciate the feedback thank you.
@@Instr oh. this is my first time hearing about Template Haskell. thanks for pointing me in that direction! i do wonder why function couldn't do the same job as a macro
@@xybersurfer Functions can't read raw code, given a function, the most a higher order function can do is to apply the function to data, preprocess the inputs of the function, or postprocess the outputs of the function. It can also inject effects, obviously, but in Haskell effect injection / actions is somewhat complicated (you end up in a monadic type context of some kind, many of which cannot be exited trivially or safely).
Happy to see some Haskell love. It is absolutely a mind expanding experience. I would love to use it in anger but it is hard to find mature, well maintained libraries. That makes it a hard sell.
Definitely, coming from all the lisping haskell has a much more active ecosystem. I get where you are coming from though. Especially when it comes to the more obscure stuff.
I am unfortunately using emacs for this video but you can try zepl for a simple way to integrate repls into vim/neovim. There are more complex solutions but zepl is my goto when using vim. In addition, I tend to also use the haskell language server which I recommend. If you use vim you can use vim-lsp and if you use neovim you can use the built in language server support.
There is a huge list of languages I would like to learn out of curiosity or principle, and there is small list of languages I should learn for practicality and the sake of my career. Haskell certainly has no place in the latter. Same for various LISPs. I learned Scheme through SICP, and that was pretty cool, and maybe I'll switch from Neovim to Emacs at some point and learn ELisp, but it's otherwise impractical to learn niche languages. I'll 100% jump at the opportunity to learn them on the clock though, but that seems unlikely to ever happen.
Ya I admit that learning most of these was driven by my desire to learn and a few ideas for side projects. I cant say I have used them directly at my day job but maybe one day I will. I still apply many things I learnt day to day. Especially the things I learnt from haskell.
I wanna preface this by saying I love your videos and hope you continue to make them. You have fallen (albeit slightly) into the classic problem with Haskell. Introductory videos of Haskell should NOT be talking about functors, applicative and monads. They make sense to you and me (I only have a little amateurish experience), but for someone who hasn't looked at Haskell before, it's all greek. The sort of greek that makes it too intimidating to consider learning. Looking at the available literature, one would be forgiven for thinking you can't program in Haskell unless you know these theoretical concepts. I'd rather people show how to build stuff with Haskell, then introduce these 'patterns' that they've been using all along and how they fit together, before formalising them into type classes with some intuitive names. Then maybe giving them their actual correct names and exploring a bit of theory behind them as a recommended advanced extension. I mean, Javascript has Promises - which behave a lot like monads. They envelope data and support chaining. But you won't find mention of that in Javascript for dummies.
If seeing that there's an entire world you don't know scares you off then you're not cut out for this field and should stick with Python. Showing making some random software won't do anything to really show why it's special. And being an engineer means you use math to solve problems. Abstract factory Singleton Bean is not engineering and is more scary in my opinion. Promises are not like monads except superficially. You don't know haskell at all if you don't know what a functor and applicative are in category theory
I have no idea how this popped up on my feed but I remember your name from a programming discord I used to be part of. Possibly because I'm learning Ocaml right now. Subbed, I guess.
Once you try Haskell, you cannot go back to a language without sumtype (algebraic data type has always been there but all the hype with OOP made programming language designers ignore it) and pattern matching. By trying Haskell one learns a few things but also becomes much more intolerant to other languages in a way
True ADTs are incredibly helpful when the language supports them. I keep finding myself reaching for them no matter what language I'm working in because they elegantly capture what I'm trying to encode with minimal boilerplate... If the language actually supports them natively. If not, then you're stuck reimplementing a bunch of functionality that should have been there from the start :/ Rust is one of the few languages that supports them though, so there is that I guess (of course, then you have to deal with the headache of the borrow checker).
@@Bobbias I totally do the same. For example C++ has support for sumtype (called variant) but it's pattern matching is a bit complicated (if not a hack). I personally like Rust design, you can really see the influence of ml languages
Someone once saw me using Lisp and said something to the effect of "You should try Haskell, it's like Lisp but with less parentheses". My response was "Oh, that's too bad. Sounds good otherwise though!"
Oh yes, it hurts so bad to have the choice to write: foo = bar . baz . quux or foo a = bar (baz (quux a)) rather than: (define (foo a) (bar (baz (quux a)))) Absolutely intolerable... The parenthesis aren't what you like about s-expressions anyway. It's more likely the regularity, lending itself easily to manipulation, whether you see it as code or data. And Haskell really isn't very lisp-like, particularly with the static type system. We wouldn't have a procedure like number? (pardon the Scheme) but a declaration like foo :: Num a => a -> a making that predicate moot. Or you use a sum type, perhaps from Aeson or S-cargot.
@@defaultxrs expressions are objectively bad. The only reason it's a thing is because LISP wanted it's surface syntax to be nearly identical to AST so they they could treat code as data, which as well as know now is a terrible idea unless you're specifically making a DSL
"Functional core, imperative shell." Here's a technique for handling input that comes from the imperative shell to the functional core: Monadic Parsers at the Input Boundary. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-LLkbzt4ms6M.html
What sort of jobs can you get using haskell? So many places are getting into rust and a few famous ones (Jane Street) even use ocaml. Given Haskell's very quirky toolchain, it can be hard to justify delving into the language vs the alternatives that are almost as language nerdy but much more employable (rust).
There are plenty of companies using Haskell today. It's definitely not gaining adoption at the rate of rust but about on par if not ahead of ocaml. Jane Street using ocaml is great but it's also one of the only things keeping the language going. Haskell sure isn't used for all companies core infrastructure but it's used in tons of domains. Web, compilers and other fields reach into the Haskell world. E.g. Facebook has used it for multiple internal tools and lex-pass, same goes for Google, Microsoft uses it for Bond and sponsors Haskell development. Hope that answers your question. Let me know if I misunderstood 😁 Edit: as far as rust being more enjoyable that depends person to person.
@@GavinFreeborn thanks! I definitely enjoy it more than rust (though not as much as Lisp, but that's just my haskell ignorance), which feels like extra frustrating C++. Let's hope Val takes off, as I think that'll span the gap between C++ and Haskell
Haskell's toolchain is not quirky, it's a 1 button install to get everything. Rust is enjoyable lol? It's a systems language that deals with a bunch of messy hardware details instead of actual computer science. All of its interesting ideas were taken from FP. otherwise it's just not as bad C. And calling these things "nerdy" is pretty much just saying they're intelligently designed languages instead of adhoc blue collar memory moving languages
Almost every language now is trying to emulate / port all of the great features of Haskell. At some point you have to ask yourself... Why not just learn Haskell? Its a great language.
For browser support there is recent support for compiling Haskell to JavaScript but if you want something more mature look at purescript. It's basically Haskell that compiles to js without lazy evaluation and a few extra features. I've used it for a few projects and can happily recommend it.
@@GavinFreebornPureScript is way too behind the ghc and is definitely not getting dependent types because nobody is going to put in that effort. Might as well just stick to haskell. There's frontends like Miso
Writing a function needs to be really really easy, because breaking up programs needs to be something a programmer does with very low activation energy. Haskell gave me the impression that I was signing a contract with a lawyer present every time i tried to write a function
foo arg1 = bar. What's the problem? Unless you're TyDDing it, you can pass off the type signature to the IDE, which will mutate the type signature via inference as you write the function; when you're done, click the code shadow. If the signature looks wrong, you probably screwed up somewhere anyways. Also, it's idiomatic to skip type sigs in where clauses, so you can just define an IO action then write the functions it uses in the where clauses. What's the problem?
Haskell fits quite neatly into a family of languages that seems to cater to people who spend more time talking about writing code than actually writing or shipping code.
First of all, in modern days nobody uses Lisp language, it's known as a language family. Second, projects developing by Clojure (which is a lisp lang btw) and Haskell are published in corresponding pages, which could be easily found, instead of wasting time to make another bs statement on "useless" languages.
Rust is imperative programming with some features inspired by the functional world and extra formalism around generics and lifetimes. Haskell on the other hand is a language that sometimes likes to dress-up functional programming to resemble the imperative model. But in the end all the constructs behind it are alien to those who have lived in the imperative land (unless they have background in math, I guess).
"purely" functional, as long as you don't look under the hood, but its a great language, and you cant fault it for how computers work and the factual limitations of reality.
You take away the purely functional branding and the syntax reduces to Python with much better functional programming support, performance, and type safety. The entire purely functional thing is a mirage, anyways. It's all lambda calculus under the hood, but Haskell supports immutable pointers to mutable variables and replaces for loops with higher order functions that are much more descriptive, including for and for_ hofs.
There's nothing about purely functional that doesn't allow any mutation whatsoever. It's just that you have to mark mutable objects as part of your type system. For example, ST does mutate, IO is dependent on outside output, IORef is both mutable and IO.
The way I see it is that the developer sort of integrates their pure functions into a monad (IO) that keeps the impure parts away from them. Those impure parts are a part of the runtime. But yeah, obviously it can't be absolutely pure, as it would be completely useless then, unable to achieve any effect. It just tries to put a barrier between the pure and impure parts of it.
@@MRL8770 One trend I'm investigating is the one wherein the IO parts just get replaced by a framework. It's ironically very natural for Haskell, since IO is an unfortunate sacrifice to pragmatism, but why not hide the entire IO part of the system with a framework? Then you just plug in pure functions, values, and callbacks into the framework and it's way more expressive and powerful than anything you could do with a conventional language. Or, in other words, you go from "Haskell is for Wizards" to "Haskell is a Wizard" and you just specify the callbacks and values you want for the mechanism.
I attempted to learn haskell in the past and had the feeling. Now with ghcup and cabal becoming more fully featured I find haskell much more user friendly. I'd say for the age of the language the tooling is decent and mostly lacking in learning opportunities. With the love this video has gotten I plan to make videos helping new users get to grips with the newer tooling. www.haskell.org/ghcup/ cabal.readthedocs.io/
Technically, functional languages are procedural. The only exception is that any data has a type signature, which cannot be changed or ignored. Purely procedural languages have a very week type system. If I remember correctly, C used to have only binary, integers and characters, everything else including floats and strings had to be build from scratch and you could change types by accident.
I like haskell but personally if I had a choice I'd probably either use ocaml or elixir for most things. The new ocaml modes that Jane Street is adding to the compiler are also extremely compelling because they effectively add ownership and borrowing to the language in a way that is intuitive and easier to understand then the rust implementation. It basically removes any potential for data races too. It's especially cool to see in a garbage collected language like ocaml. I worked with elixir in the last professional project I was on, It was great to use because we were also able to mix it with rust nifs. So we got the insane concurrency of Erlang with the speed of rust. Not to mention the productivity boosts they come with working with a language like elixir are significant. I literally built an entire blockchain (in rust with substrate), matching engine, graphql API, cacheing system, and decentralized no SQL crdt/raft database in about 8 months. I've worked with Haskell a few times but I always get hung up on the syntax. I find that it gets kind of messy if you are not careful. I love the type system, the stm concurrency and the currying but the syntax for closures for instance or threading macros can be a little messy. Elm had a similar syntax but they definitely cleaned it up considerably. Scala and ocaml both have higher kinded types but I wouldn't say they are as intuitive as the ones in Haskell. Btw, really love that you're using org mode to do your videos. Love me some org mode.
The syntax isn't messy at all, it's as clean as it gets and is basically nearly exactly how math is written... Haskell is a significantly more advanced language than everything you've mentioned Closure syntax? What does that mean And idk why you keep mentioning rust, it's not fp and is a systems language
@@user-tx4wj7qk4t me not liking Haskells syntax is not a personal attack on you, just FYI. I wouldn't say it's a more advanced language than elixir or ocaml, and what does it matter? This is not a competition, they might all be functional programming languages but they all fill different domains. To be clear, I still use Haskell despite the fact that I don't like it syntax as much as I like many other languages. I still use Scala even though I don't like the way that it does certain things as well (many of the problems were fixed in Scala 3 but not all of them). Haskell's syntax might be similar to math if you are just talking about the type system and maybe the way it does boolean logic but rarely do you use those two features in isolation. I specifically highlighted the threading macros as well as the closures aka capturing functions. In Haskell, you use parentheses filled by a \ to indicate a closure, which is fine on its own but you almost rarely are going to just have a closure surrounded by nothing. The way the language uses white space in general can be pretty messy in my opinion. At the end of the day though, all of this is subjective opinion. I personally really like lisp and scheme (which are both basically implementations of lambda calculus) and I know a lot of people who hate those languages because of their syntax. I'm not going to take personal offense to somebody saying they don't like lisp. The reason I keep mentioning rust is because I'm talking about enterprise projects where I have used it in production alongside these other languages. It might not be a strictly functional language but it has a lot of functional features, even though it's certainly a first class imperative language.
@@draakisback me not using moral relativity as a convenient way to claim anything I want without rebuttal is not a personal attack on you, just FYI. "I wouldn't say it's a more advanced language than elixir or ocaml" Your "truth" doesn't change the fact that it is objectively a more advanced language " and what does it matter? This is not a competition" Ah so you can claim things about how some syntax is better and compare languages but then somebody coming in to tell you that you're comparing apples to oranges makes it no longer a competition and not something relevant. How convenient. I wish I could warp reality this way " they might all be functional programming languages but they all fill different domains." It's more that they have different histories. For example OCaml is only really used because Jane Street needed a language they could basically mold to fit their needs. They picked a dead language nobody cared about being there wasn't competition. It's politics, same reason they abandoned their project to give Haskell a dependent type system because it competed with them too heavily. "Haskell's syntax might be similar to math if you are just talking about the type system and maybe the way it does boolean logic but rarely do you use those two features in isolation." No it's similar to math in nearly everything to how it's based on category theory, function composition is a dot from a Semigroupoid, lambda notation is directly from lamba calculus, function notation is directly from set/type theory, how every operator is a function, abstract data types, quantifiable/existential types are directly from set/type theory, it uses typeclasses to directly model algebras, and the fact that everybody who doesn't like it has to mention at some point that it "looks like math". " I specifically highlighted the threading macros as well as the closures aka capturing functions." Closures are not "capturing functions" and all functions in Haskell are closures. "In Haskell, you use parentheses filled by a \ to indicate a closure" No you don't, you use that syntax to create a lambda aka anonymous function. That's not at all the same thing as a closure. This is something I'd expect a javascript soydev to say. "which is fine on its own but you almost rarely are going to just have a closure surrounded by nothing." What "The way the language uses white space in general can be pretty messy in my opinion. " You're right, let's clean it up by putting curly braces, semicolons, and massives piles of boilerplate everywhere. Oh but somehow Python is really clean and the perfect syntax "At the end of the day though, all of this is subjective opinion. " Copout. Nobody thinks java is cleaner than Kotlin. Nobody thinks C++ templates are cleaner than Haskell generics. You just want an excuse to not like Haskell because you don't understand it very well. "I personally really like lisp and scheme (which are both basically implementations of lambda calculus)" Unironically liking Lisp's syntax means you like a syntax that was only created that way to be nearly identical to the AST, aka the language completely ignored actually making an ergonomic syntax to make the entire language manipulatable. The language designers very literally made it ugly and you think that's good. "The reason I keep mentioning rust is because I'm talking about enterprise projects where I have used it in production alongside these other languages. It might not be a strictly functional language but it has a lot of functional features, even though it's certainly a first class imperative language." So you randomly brought it up, ok Overall it sounds like you're unironically a soydev who doesn't really understand computer science very well and thinks that low-level blue collar work like threads, memory plumbing, and CRUD APIs are "serious programming" instead of the software version of being a car mechanic vs a mechanical engineer. Go learn category theory or frankly some baby's first lambda calculus because you don't know what a lambda is apparently. Then I'll take your "opinions" seriously, but something tells me you'll go play with memory and threads instead
@@user-tx4wj7qk4t I considered writing a long reply to yours but honestly its not worth it. I have nothing to prove to someone who is clearly just out to pick a fight. The fact that you seemingly have a problem with threading and "memory plumbing" (btw, wtf does that mean?) and also use terms like soydev (had to look that one up) just shows how much of a reddit warrior you are. Given how much of a 10000x dev you seem to be, I am sure you are aware that Haskell uses threads internally under its STM abstraction and it also has a GC. You know, some languages use the term closure for all lambdas and vice versa. Swift for example calls all anonymous functions closures and most modern programming languages implement lambdas with the potential to work as closures because its generally safer to copy/clone an instance of the external variable then to reference it. You know, its not uncommon to use both terms interchangeably even if its technically wrong. This is a youtube comment section, it doesn't matter if the terms are perfect. Does it make you angry that there are people who write nothing but JavaScript for a living and they make more money then you probably ever will? Anyhow, have fun doing "serious programming"... Id love to see what you think is "serious programming"... By all means, enlighten my ignorant self on how wrong I've been for the past 30 years of my career.
@@draakisback Wow if that's a short response, I wouldn't want to see a long one. Memory plumbing is when you focus on moving memory around instead of actually creating software that solves problems. It's like how a mechanic focuses on banging the carburetor instead of designing vehicles. Nope don't use reddit, they're the worst. In fact they're the mecca of soydevs and would ban you for using that word. Nice try though Yeah never said threads are bad lol, that's just a tool, not the job. "You know, some languages use the term closure for all lambdas and vice versa." No they don't, the soydevs who don't know the difference between all the words do. And closures have nothing to do with lambdas, two different concepts entirely. A named function is still a closure in Haskell and probably most of those languages too. "it's ok to use wrong words on youtube" lol the goalpost moving is hilarious "Does it make you angry that there are people who write nothing but JavaScript for a living and they make more money then you probably ever will? " Ugh why would a soydev with a 4 month bootcamp who does something a teenager in India does make more money than me? Like please explain that logic because if that were true I could at go learn the latest javascript framework in a week and get hired making that same amount. You have to think out your insults better brother. "Anyhow, have fun doing "serious programming"... Id love to see what you think is "serious programming"... By all means, enlighten my ignorant self on how wrong I've been for the past 30 years of my career." LOL 30 years and you don't even know what a lambda or closure are. Geez. What have you been doing for 30 years, sitting around? But yes in general it's the old guys who are the absolute worst, they learned some meme imperative nonsense back in the before-times and they never change because "I've been doing this for 30 years". Maybe go actually learn computer science after 3 decades if you have some self respect instead of playing around with pointers.
