You are very lucky that day 9 was perfect for a recursive solution, which fits nicely with haskell, but still.. you've never programmed in haskell and wrote this? That's impressive!
MUCH easier than Haskell. He is a C programmer with a channel called low Level Learning and high level procedural languages like assembly and C are just bread and butter. VHDL would probably be a better language. (you have to create the computer).
it took me a very long time before i finally "got" haskell, now that I have though it is very elegant and problems that are like 20 lines at least in rust are like 4 lines in haskell.
@@JonathanFraser-i7h That's the great thing - you don't have to use them if you don't want to, and if you want a clearer name, it's literally two lines to redefine it (three if you want infix to work with a custom precedence).
@@Adowrathuntil you need to use a library that went operator happy and all the example use only operators. It's not just your code you need to worry about.
Damn.. I read the title and thought of my first reaction to Haskell at uni: "How are you supposed to do anything without loops and ifs". Took me a full afternoon to wrap my head around that. It clicked eventually, but it also unclicked a few years later... I think you got extremely lucky. Day 9 seems very suitable for Haskell. Imagine doing day 10...
Haskell conditionals (without libraries or extensions): if-then-else: Equivalent to ternaries. if (cond) then (result 1) else (result 2) (cond) ? (result 1) : (result 2) guards: myFunction arg1 arg2 ... | cond1 = result1 | cond2 = result2 top-level pattern matching: myFunction Match1 = result1 myFunction Match2 = result2 myFunction Match3 | cond4 = result 3 You can combine top-level pattern matching and guards. case expressions (expression-level pattern matching): case foo of Match1 -> result1 Match2 -> result2 Match3 | cond4 -> result3 pattern guards: foo | cond1, cond2, Match3 result1 | cond2 -> result2 *** I guess the real issue with Haskell is that it's a more expression-oriented language than either Scala or Rust. Whereas in most languages, expressions live in statements, in Haskell, statements live in expressions (statements, within the language spec, only exist within do notation and represent monadically typed values for do notation to stitch together).
The great thing about functional languages is it's not unusual for them to work on the first try. But let's not talk about how long that first try takes, or how easy it is to pick back up a month later.
Ever since chatgpt came out, whenever I tell my wife I did something cool in a programming language, she says, ohh you just used chatgpt, you're a cheater....... Welcome to the club, also, truly enjoying these videos, thanks for making them@@LowLevelTV
I started doing Haskell for an Intel 8081 disassembler as a play example, and my experience has been "once you can stop arguing with the compiler, it just works"
Dude. In other languages I hadn't worked with before, I eventually started to understand your code by the end of the video. Haskell is still looking like gibberish to me after this video.
Don't sweat the recursion too much; 80% of the time the recursion is handled for you by higher-order functions (for in Data.Traversable and for_ in Data.Foldable, are essentially for-each or iterator loops, implemented via laziness, recursion, and folds). It is a good place to get really familiar with recursion, though, until you find out that people tend to automate the recursion away with functions. *** In reality, Haskell is sort of Pythonic, insofar as it comes down to getting libraries that interface with low-level stuff, stealing their functions, and using various function composition operators / higher-order functions to stitch them together to transform the incoming data the way you want or throw the side effects you want. For instance, your definition of sub? Many Haskellers would write it as sub = flip (-) -- parens around a lone operator turns it into a function; all operators in Haskell are functions and all functions can be made into operators with backticks. flip here just says, for a given function taking at least two arguments, let's switch the first two arguments around. But in fact, there is the subtract function in Prelude that already does what you need. *** Thanks for giving Haskell a shot, it's a fun past-time that really deserves better tooling and libraries, as well as more production use.
I started learning programming with BASIC, then moved to binary code (inlines in the BASIC code) which was quite hard to do for obvious reasons. Then moved to Assembly for ZX 80. And that was a lot of fun. Next was Pascal, a lot of fun too. After that C - that was a bit of WTF moments, then Fortran and so on and so forth. From all that experience of learning different lingos I can tell that anything you are unfamiliar with can look a bit like WTF. But your attitude can not only make the process fun but also open your eyes. Or the opposite 😂 Haskell is awesome.
@@peppybocan well compilers don't always have to be fast, and as long as you target an efficient enough runtime you should be fine, i'm targeting is a VM I wrote in C , not the most efficient but hey, it kinda works :), the thing with haskell is that it's much easier to write parsers in, (and maybe even typecheckers due to pattern matching).
You should try with the book "Learn you a Haskell for great good". Whe you really understand it, is a really fun experience tp work with and really changes your perspective in solving some problems
@@0LoneTech I meant it for more general usage, it's always preferred to have a total function than a partial one (outside of IO anyway) all returns True on an empty list, so the program won't be stuck in a recursion loop anyway
I love how powerful Haskell is with lists. I also love that so many things are lists and numbers in Haskell. I learned to appreciate recursion, currying, and lambda functions with Haskell. I just wish it was a bit easier to read. Some functions have had a bit too much influence from mathematicians.
It's dangerous to go alone! Take this solve :: ([Int] -> Int -> Int) -> [[Int]] -> Int solve f = foldr f 0 part1 :: [[Int]] -> Int part1 = solve f where f xs y = last xs + y part2 :: [[Int]] -> Int part2 = solve f where f xs y = head xs - y prepare :: [[Integer]] -> [[Int]] prepare = map (map (fromInteger)) input = [[0,0],[2,2,2],[0,2,4,6],[3,3,5,9,15],[10,13,16,21,30,45]] part1 . prepare $ input part2 . prepare $ input
Don't know what you mean. Haskell is lots of fun. If the package management was better I would be gladly using it more often. But you know what should be on the wheel (can't read the darker fields, maybe it already is): Common Lisp
@@0LoneTech A lot of times it can lead to conflicts. It kills the fun if you have to spend an afternoon to debug the failing of the package system, instead of writing code.
My mistake when trying to learn Haskell is I was trying to parse content from the internet. Then you are dealing with Haskell's absurd multi-dimensional array of string types while all the libraries that are available want you to make use of the extended operators. And networking is inherently going to have side effects, which I was not prepared to do on day one.
Now you're thinking with types! Though I can't imagine writing Haskell without obsessively inspecting everything's type from moment to moment - they whisper the answers. Next step is writing your own Haskell EDSL with free monads.
That's a really good thought process if you want to do anything in Haskell and are just starting out: Think about each step, what are the types/values involved, write a function for it, then assemble into a larger function. You can even use dummy return values to just have something compilable/semi-testable at first. Only once you're done should you go over the code and merge some of the tiny functions into the places they are used.
@@Adowrath I see: all my comments with links are getting auto-deleted. Well - for the third time - you can create dummy types too, or types with dummy parameters; all you need to do is enable the PartialTypeSignatures extension at the top of the file (really it ought to be enabled by default).
Haskell is amazing if you let go of the low level mindset for a second... but I understand that's pretty hard if imperative/OO is all you've known and your channel's literally called "Low Level Programming" 😅 Glad you made it, and I hope it's not as scary as it used to be. See it as "You've been learning European languages as an English speaker up to this point, now you've started learning Chinese/Hindi" which is COMPLETELY different, yes, but will give you amazing insights into how languages work and what you can do with them 😄
@@NiDeCo I am using GHC and packages llvm-tf and llvm-extra from Hackage. Example applications are patch-image and synthesizer-llvm, also released on Hackage.
Try bc, dc, sed and C. If you use C you are not allowed to use any prepocessor. You have to use a linter. If you use splint it is enough to use splint -weak file.i If you use gcc use this splint -weak file.i && gcc -Wall -Wextra -Werror -O2 file.i -o file You are not allowed to use any options that make the aformentioned options obsolete.
This is what I love about Haskell. You spent a long time scrambling thinking about a nice algorithm to build this in. Then you put it in your typesystem and when the compiler accepts it, it works and you are proud of yourself
The thing I like about Haskell, or generally functional languages is that once you know how to work with them they feel a lot more declarative, you just describe what problem you want to have solved rather than how to solve it. However, I understand that it's just super jarring if you are used to procedural or object oriented development.
I'm pretty new to Haskell. Could solve this problem easy, but still pretty new. I find it very beautiful. Its refreshing just saying what is what instead of writing instructions. Its refreshing typing "read $ word line" and its refreshing only non alnum char you type is operators and occasional ()
Day 9 like the platonic ideal of a recursive problem lol I enjoyed learning Haskell but mostly as an academic pursuit. Moved on to OCaml and then Elixir for more pragmatic things.
You are miles better than I am at C and similar low level languages. However, seeing you not using few motions in visual mode and move around in insert mode with vim hurts my soul. Deeply.
I'm an inveterate C++ and now C# programmer. On the side I do music. I find learning the violin to be sufficiently soul sucking so I don't have to try programming in Haskell.
As a guy who does AoC using haskell for two years, that's impressive on the first try tho. I totally forgot how frustrating it was at the beginning nowadays... This is my solution on AoC 2023 day 09 part 1 type History = [Int] type Input = [History] type Output = Int difference :: Num a => [a] -> [a] difference series = zipWith subtract series (tail series) extrapolate :: History -> Int extrapolate history | all (== 0) history = 0 | otherwise = last history + extrapolate (difference history) solution :: Solution String Input Output solution = Solution { parser = many (int `sepBy` char ' '
The idiomatic haskell way to write this would be the one-liner: main = readFile "sample.txt" >>= print . foldr ((+) . foldr ((+) . last) 0 . takeWhile (any (/= 0)) . iterate (zipWith (-) tail id) . map read . words) 0 . lines Then, simply run it from within the same directory containing both solve.hs and sample.txt with: $ runhaskell solve.hs
I'm very happy you got a problem so well suited for Haskell. You didn't get to see any of the stuff that makes us love haskell so much, like monads or lenses or data kinds. I'll tell you a useful library most haskell programmers don't mention: the ST monad let's you have mutable variables in a pure function.
I've dabbled in haskell on and off for literal years and I *still* have never encountered a use for lenses. I usually write like 2-5 haskell programs a year, since ~2013, although I've slowed down in recent years.
I like Haskell. It's a good way to challenge your brain to think differently (or at least for me that's the case). Don't know how practical it is, though.
Hi @LowLevelLearning i checked your website and i want to enroll for the ARM course which is still not up .... Also add a rust course this will also help a lot of people. Hope u can bring the ARM course as fast as possible
The last exam I took in my master's of computer engineering was called "principles of programming languages", where you had to learn Scheme, Haskell and Fortran. It was the most grueling experience of my life. Also, the "do" monad was not allowed and it had to be solved on paper
I have 2 problems with haskell. The first problem is information density. You might be able to do a lot more things in fewer lines but those fewer lines still have to carry all that information, so for me it becomes hard to mentally parse. The second problem in the language for me is indenting. Haskell is whitespace sensitive and I generally dislike that. A lot of the time you will do something with the state monad and you end up with a "code tornado". Frequently you will end a do block with a "case" construct to pattern match the default cases in a recursive do block, because the language is whitespace sensitive you end up indenting 4-5 levels some of the time. It doesn't help that I like to have 8 wide indentation.
yeah, i don't really think 8 wide indentation is viable in haskell. one compromise i often use to reduce the excessive indentation levels is to use half-level indentation for single-line keywords like do and case etc. if i use 4 spaces of indentation i would indent the "do" keyword 2 spaces. another option is to put the keyword at the end of the previous line. of course, neither of these will help with the information density problem. however, for me there is some reduction of information as well, at least as long as you stop thinking low level operationally but more higher level "what is the result?". For example, if I see in C code a for-loop that calculates the sum of an array, that carries a lot of details about how the sum is performed, which I may not care about, so just calling the "sum" function (or even "foldl' (+) 0") has less uninteresting details and boilerplate.
Information density is higher, but you just have to get out of the habit of just glimpsing at a line to know what it does since in most other language that's all it takes. You have to take your time to read and understand each line. You'll feel slow but all in all you're understanding the program at the same speed (once you're proficient), it is just much more compact. I like whitespace sensitivity but in Haskell it's optional, you can use braces and semicolon instead if you prefer. Of course that won't help with code written by others… And 8 spaces indentation is just too much !! 4 spaces is more viable and just as easy to parse visually, IMHO.
The only code I understood was the stuff chatgpt wrote, because it reminds me of how I solved things in lisp during university. Everything else broke my brain; the $ still scares me; I looked it up and I still can't follow why they are where in your code. I have no idea what's going on.
The '$' operator has a precedence level that basically let's you replace the parenthesis on the right half of your expression map (+1) (getList myData) Could become map (+1) $ getList myData It handles applying the argument myData to the function getList, and then has that value become the second argument to map
I feel like I’m in the minority here, but this mostly made sense to me aside from weird operators I’m not used to(haven’t done anything with any language that isn’t object oriented ever), maybe I should try it at some point
The best starting point is imo the Elm guide! Because the language is still very much Haskell-like, yet small and rather simple it gently introduces you to the syntax style, basic techniques and what purely functional programming is about in general. It will take you a few hours max. After that you can dive into more advanced topics in Haskell or something like PureScript, Idris, and so on.
Functional programming clicks better for some people than others. And likewise with Object Oriented and pretty much any other form of programming. I would give it a try to see if it suits you better. But I will warn you that if your job is object oriented programming your coworkers will start to hate you for bringing in functional programming gibberish and they won't be wrong :P
The fact that you knew about folds/reduces and such but not about the term "adjacent difference" ('adjDiff xs = zipWith (-) xs (tail xs))' maybe flip the - or tail vs non-tail) is wild to me. xD
Aaaaaaaaaaaaa! Just reading that code was painful Here you go. This should be much easier to understand. Even though it's Idris and not Haskell, here it's basically the same thing. import Data.List import Data.List1 import Data.String -- List1 - a non-empty list differences : List1 Integer -> List Integer differences xs = zipWith (-) (tail xs) (init xs) generateAllRows : List1 Integer -> List (List1 Integer) generateAllRows xs = if all (== 0) xs then [xs] else xs :: case fromList (differences xs) of Nothing => [] Just nonempty => generateAllRows nonempty predict : List1 Integer -> Integer predict = sum . map last . generateAllRows main : IO () main = do line main -- an empty input line needs to be skipped printLn (predict numbers) main
Cniles be like: We're gonna modify the ASM from memory on the fly in order to store the return pointer and creating a jump to the new function. Also Cniles: Nooooo, recursion is tooo hard. I don't want to learn new FP concepts and it's the fault of FP.
I like the concept of haskell, but the syntax always drives me insane; which is why I prefer ocaml. There is something to be said for a language that has mapping built directly into it, it allows you to easily deal with collections of data in a way that is somewhat more intuitive than using loops. I don't know if you've ever worked with APL or any of the other array-based languages, Haskell has a lot of those features even if it's not a true array based language. It's very much a research language, it doesn't make much sense when people use it in prod for enterprise solutions but some people are masochistic I suppose.
Honestly, the very weird syntax is the only reason I haven't used Ocaml outside of 2-3 code Katas I did once. Haskell really reads well for me in comparison, the only thing I wish it had was (.member) like syntax (like Idris has).
@@Adowrath it's funny, I used to like elm (before the community exploded) which uses a Haskell like syntax but it's syntax is much cleaner than Haskell itself. Idris too, has a much cleaner syntax when compared to Haskell. Ocaml reads like rust but with functional programming. A lot of people blame the issue with Haskell on functional programming, but I started with fp instead of oo or imperative languages. The syntax just has too many points where it changes from prefix to infix and it has these bizarre operators which idiomatically don't use parentheses etc. even when I was contributing to cardano, I just didn't like using Haskell.
@@draakisback I love coding in Idris (wrote an experimental backend to Hasell for it lmao) but I actually, despite the foundational ideas, really didn't enjoy my time with Elm as much as I hoped to - a mix of elm-format being quite ugly, the non-existence of multiple clauses in function definitions, no typeclasses, and the choice of not allowing unprefixed usage of functions from other modules made it kind of a pain to use in that uni project once. The one thing that is really confusing though is the ginormous list of precedence levels in Haskell compared to Idris, I'll give you that. I practically always try to write my code where infix operators are unambiguous in priority without using too many parentheses.
@@Adowrath I can understand that. For me elm was interesting because of the idioms and how clean it's syntax was. I know a lot of people didn't like that it was a fairly small and opinionated language. It's part of why the community exploded, so many people wanted to use it full stack and the main dev didn't want that.
@@draakisback Oh, that's what you meant by exploded, I thought you meant like they got really big. And yeah, it's definitely a great language if you can come to like it, the puzzle pieces of my brain just weren't the right shapes.
3:55 - denial
5:37 - anger
6:05 - bargaining
6:42 - depression
10:04 - acceptance
yeah it does that to you 😭
So terribly sad...
Haskell first experience in short:
- This is terrible, this is not a fun experience. 5:42
- Wait, did I just made it? 8:36
It's a good language when you have to question if you have actually built something before you see it run.
You are very lucky that day 9 was perfect for a recursive solution, which fits nicely with haskell, but still.. you've never programmed in haskell and wrote this? That's impressive!
Im very impressed too.
But it did take him 3 hours ( from the stream VOD ), which is a lot more than the ones where he used a familiar language
kijetesantakalu lon o toki
@@incredulity toki a! :D
tenpo mute la mi lukin e ni: toki pali Asuke li musi tawa jan pi toki pona.
Day 9 was a good choice for a functional language. The recursion was pretty easy to figure out
I've been doing them all in Haskell, and yeah, there isn't a better problem for him to spin Haskell on.
Amazing! Here's hoping you add RISC-V Assembly to the board
And I thought I was cruel thinking that now that we've got Haskell I wanna see Lisp
fr
this
MUCH easier than Haskell. He is a C programmer with a channel called low Level Learning and high level procedural languages like assembly and C are just bread and butter.
VHDL would probably be a better language. (you have to create the computer).
@@theultrahorseman
Verilog.. it's like C, but without the CPU part.
it took me a very long time before i finally "got" haskell, now that I have though it is very elegant and problems that are like 20 lines at least in rust are like 4 lines in haskell.
Its very succinct.
@@torarinvik4920 The succinctness is okay the prefusion of operators to make it unnecessarily terse is not.
@@JonathanFraser-i7h 90% of operator uses are one of $ : >>= I think 6 operators is reasonable to learn.
@@JonathanFraser-i7h That's the great thing - you don't have to use them if you don't want to, and if you want a clearer name, it's literally two lines to redefine it (three if you want infix to work with a custom precedence).
@@Adowrathuntil you need to use a library that went operator happy and all the example use only operators.
It's not just your code you need to worry about.
Way to go for confronting all this unknown and exposing us to your learning process. It is very brave to challenge yourself in such a public fashion.
Damn.. I read the title and thought of my first reaction to Haskell at uni: "How are you supposed to do anything without loops and ifs". Took me a full afternoon to wrap my head around that. It clicked eventually, but it also unclicked a few years later...
I think you got extremely lucky. Day 9 seems very suitable for Haskell. Imagine doing day 10...
Haskell conditionals (without libraries or extensions):
if-then-else:
Equivalent to ternaries.
if (cond) then (result 1) else (result 2)
(cond) ? (result 1) : (result 2)
guards:
myFunction arg1 arg2 ...
| cond1 = result1
| cond2 = result2
top-level pattern matching:
myFunction Match1 = result1
myFunction Match2 = result2
myFunction Match3 | cond4 = result 3
You can combine top-level pattern matching and guards.
case expressions (expression-level pattern matching):
case foo of
Match1 -> result1
Match2 -> result2
Match3 | cond4 -> result3
pattern guards:
foo
| cond1, cond2, Match3 result1
| cond2 -> result2
***
I guess the real issue with Haskell is that it's a more expression-oriented language than either Scala or Rust. Whereas in most languages, expressions live in statements, in Haskell, statements live in expressions (statements, within the language spec, only exist within do notation and represent monadically typed values for do notation to stitch together).
@@Instrdamn I didn’t even know about pattern guards
"we can do this recursively … I just don’t want to". I felt that.
The great thing about functional languages is it's not unusual for them to work on the first try. But let's not talk about how long that first try takes, or how easy it is to pick back up a month later.
now imagine coding haskell without chatgpt
definition of nightmare:
No
@@LowLevelTVsolution: build zig with haskell
Ever since chatgpt came out, whenever I tell my wife I did something cool in a programming language, she says, ohh you just used chatgpt, you're a cheater....... Welcome to the club, also, truly enjoying these videos, thanks for making them@@LowLevelTV
@@LowLevelTVno part 2? 😂
I started doing Haskell for an Intel 8081 disassembler as a play example,
and my experience has been "once you can stop arguing with the compiler, it just works"
Dude. In other languages I hadn't worked with before, I eventually started to understand your code by the end of the video. Haskell is still looking like gibberish to me after this video.
Don't sweat the recursion too much; 80% of the time the recursion is handled for you by higher-order functions (for in Data.Traversable and for_ in Data.Foldable, are essentially for-each or iterator loops, implemented via laziness, recursion, and folds).
It is a good place to get really familiar with recursion, though, until you find out that people tend to automate the recursion away with functions.
***
In reality, Haskell is sort of Pythonic, insofar as it comes down to getting libraries that interface with low-level stuff, stealing their functions, and using various function composition operators / higher-order functions to stitch them together to transform the incoming data the way you want or throw the side effects you want.
For instance, your definition of sub? Many Haskellers would write it as sub = flip (-) -- parens around a lone operator turns it into a function; all operators in Haskell are functions and all functions can be made into operators with backticks. flip here just says, for a given function taking at least two arguments, let's switch the first two arguments around. But in fact, there is the subtract function in Prelude that already does what you need.
***
Thanks for giving Haskell a shot, it's a fun past-time that really deserves better tooling and libraries, as well as more production use.
Would love to see ASM on that Wheel. Or at least give a bit of mercy and see FORTH or COBOL on there. ADA would also be fun.
Ada would be nice as it promises to deliver correct code like Haskell does.
I started learning programming with BASIC, then moved to binary code (inlines in the BASIC code) which was quite hard to do for obvious reasons. Then moved to Assembly for ZX 80. And that was a lot of fun. Next was Pascal, a lot of fun too. After that C - that was a bit of WTF moments, then Fortran and so on and so forth. From all that experience of learning different lingos I can tell that anything you are unfamiliar with can look a bit like WTF. But your attitude can not only make the process fun but also open your eyes. Or the opposite 😂
Haskell is awesome.
I came from various BASICs, Z80 and MC68000 assembly, Modula II and 3 to Haskell, eventually.
I’m writing a compiler in Haskell, and yesterday I had a meltdown, but it’s very well suited for such tasks :)
For metldowns, that is? :D
using applicative for parsers is fun
you know, writing a compiler in C is much better!
@@peppybocan well compilers don't always have to be fast, and as long as you target an efficient enough runtime you should be fine, i'm targeting is a VM I wrote in C , not the most efficient but hey, it kinda works :), the thing with haskell is that it's much easier to write parsers in, (and maybe even typecheckers due to pattern matching).
@@Fritz131415 for both 😂
This guy taught me how to code in high school, really cool dude, loving the content 👍
You should try with the book "Learn you a Haskell for great good".
Whe you really understand it, is a really fun experience tp work with and really changes your perspective in solving some problems
That create pairs is so necessary. You should zip the list with the tail of itself as in "createPairs lst = zip lst (tail lst)"
use drop 1 instead of tail, since tail fails on empty lists
@@0LoneTech I meant it for more general usage, it's always preferred to have a total function than a partial one (outside of IO anyway)
all returns True on an empty list, so the program won't be stuck in a recursion loop anyway
@@atijohn8135 just as a sidenote, in this exact case, zip is right lazy so "zip xs (tail xs)" won't fail. but yea drop 1 better
Or using NonEmpty list for a new type-accurate headache :)
Or you can do it pointfree:
createPairs = zip drop 1
it finally happened 😂😂😂
part1 :: String -> Int
part1 = solve ((+) . last)
part2 :: String -> Int
part2 = solve ((-) . head)
solve :: ([Int] -> Int -> Int) -> String -> Int
solve f = sum . map (predict . map read . words) . lines
where
predict xs
| all (== 0) xs = f xs 0
| otherwise = f xs $ predict $ zipWith (-) (tail xs) xs
This looks like ancient aliens runes to me and I write rust lmfao - how tf do people read this stuff… writing it is one thing but reading it? Oh boi
I love how powerful Haskell is with lists. I also love that so many things are lists and numbers in Haskell. I learned to appreciate recursion, currying, and lambda functions with Haskell. I just wish it was a bit easier to read. Some functions have had a bit too much influence from mathematicians.
@@tietosanakirja one that still confuses me is whatever this thing is “ “ or similar- like… why is there a flying saucer in my code 🤣🤣
@@Hellbending It will beam you to the next level.
It's dangerous to go alone! Take this
solve :: ([Int] -> Int -> Int) -> [[Int]] -> Int
solve f = foldr f 0
part1 :: [[Int]] -> Int
part1 = solve f
where
f xs y = last xs + y
part2 :: [[Int]] -> Int
part2 = solve f
where
f xs y = head xs - y
prepare :: [[Integer]] -> [[Int]]
prepare = map (map (fromInteger))
input = [[0,0],[2,2,2],[0,2,4,6],[3,3,5,9,15],[10,13,16,21,30,45]]
part1 . prepare $ input
part2 . prepare $ input
Don't know what you mean. Haskell is lots of fun. If the package management was better I would be gladly using it more often.
But you know what should be on the wheel (can't read the darker fields, maybe it already is): Common Lisp
@@0LoneTech A lot of times it can lead to conflicts. It kills the fun if you have to spend an afternoon to debug the failing of the package system, instead of writing code.
Cabal with its new Nix-style builds is pretty ok.
My mistake when trying to learn Haskell is I was trying to parse content from the internet. Then you are dealing with Haskell's absurd multi-dimensional array of string types while all the libraries that are available want you to make use of the extended operators. And networking is inherently going to have side effects, which I was not prepared to do on day one.
Now you're thinking with types! Though I can't imagine writing Haskell without obsessively inspecting everything's type from moment to moment - they whisper the answers.
Next step is writing your own Haskell EDSL with free monads.
That's a really good thought process if you want to do anything in Haskell and are just starting out: Think about each step, what are the types/values involved, write a function for it, then assemble into a larger function. You can even use dummy return values to just have something compilable/semi-testable at first. Only once you're done should you go over the code and merge some of the tiny functions into the places they are used.
@@Adowrath I see: all my comments with links are getting auto-deleted. Well - for the third time - you can create dummy types too, or types with dummy parameters; all you need to do is enable the PartialTypeSignatures extension at the top of the file (really it ought to be enabled by default).
@@zachary123212 PTS and Holes are game changers, really.
@@zachary123212 I think Haskell supports typed holes now, doesn't it?
@@mskiptr Typed holes yes. But not holes in types - afaik that requires the (very confusingly named) extension.
Something really funny about the problem statement starting with "You ride a (o)Camel"
Haskell is amazing if you let go of the low level mindset for a second... but I understand that's pretty hard if imperative/OO is all you've known and your channel's literally called "Low Level Programming" 😅
Glad you made it, and I hope it's not as scary as it used to be. See it as "You've been learning European languages as an English speaker up to this point, now you've started learning Chinese/Hindi" which is COMPLETELY different, yes, but will give you amazing insights into how languages work and what you can do with them 😄
I do low-level programming with Haskell and LLVM. It's a machine-independent strongly typed assembler. Pretty cool.
@@amigalemming
Do you use GHC? And which libraries for the low-level parts? I'm kind of interested now.
@@NiDeCo I am using GHC and packages llvm-tf and llvm-extra from Hackage. Example applications are patch-image and synthesizer-llvm, also released on Hackage.
Oh god, I returned to my university years learning Haskell
Try bc, dc, sed and C. If you use C you are not allowed to use any prepocessor. You have to use a linter. If you use splint it is enough to use
splint -weak file.i
If you use gcc use this
splint -weak file.i && gcc -Wall -Wextra -Werror -O2 file.i -o file
You are not allowed to use any options that make the aformentioned options obsolete.
To understand what recursion is, you first need to understand what recursion is ...welcome to Haskell
This is what I love about Haskell. You spent a long time scrambling thinking about a nice algorithm to build this in. Then you put it in your typesystem and when the compiler accepts it, it works and you are proud of yourself
The thing I like about Haskell, or generally functional languages is that once you know how to work with them they feel a lot more declarative, you just describe what problem you want to have solved rather than how to solve it.
However, I understand that it's just super jarring if you are used to procedural or object oriented development.
Haskell existing gives me daily stress without it being on any spinny wheel xD
Might have to try it out to get it out of the way.
I'm pretty new to Haskell. Could solve this problem easy, but still pretty new. I find it very beautiful. Its refreshing just saying what is what instead of writing instructions. Its refreshing typing "read $ word line" and its refreshing only non alnum char you type is operators and occasional ()
Day 9 like the platonic ideal of a recursive problem lol
I enjoyed learning Haskell but mostly as an academic pursuit. Moved on to OCaml and then Elixir for more pragmatic things.
About the error of the last expression not being IO, I recommend to finish `main` with `return ()`. Just note that `return` is different here :).
You got lucky this day was so well suited for haskell, but congrats nonetheless!
Haskell is the greatest language to exist.
Haskell and C are my two favorite programming languages! And I love embedded programming!!
I do low-level programming with Haskell via LLVM.
Will you do the missed days?
nextvalue :: Num a => [a] -> a -> a
nextvalue [] acc = acc
nextvalue x@(y:ys) acc = nextvalue (zipWith (-) x ys) (y+acc)
computeNext list = nextvalue (reverse list) 0
The shortened format for this one doesn't do Haskell any favors as I quickly got lost in the sauce.
You are miles better than I am at C and similar low level languages.
However, seeing you not using few motions in visual mode and move around in insert mode with vim hurts my soul.
Deeply.
I’m smart enough to realise that a purely functional language could be really cool, but not smart enough to get my brain out of its imperative rut.
6:39 Felt the "Wait, its recursive" in my soul from when I started to learn OCaml
I forgot how beautifil this language is
5:35 I thought I was listening to ThePrimeagen for one moment.
"Of course it's recursive." That's practically the Haskell motto.
I'm an inveterate C++ and now C# programmer. On the side I do music. I find learning the violin to be sufficiently soul sucking so I don't have to try programming in Haskell.
As a guy who does AoC using haskell for two years, that's impressive on the first try tho. I totally forgot how frustrating it was at the beginning nowadays...
This is my solution on AoC 2023 day 09 part 1
type History = [Int]
type Input = [History]
type Output = Int
difference :: Num a => [a] -> [a]
difference series = zipWith subtract series (tail series)
extrapolate :: History -> Int
extrapolate history
| all (== 0) history = 0
| otherwise = last history + extrapolate (difference history)
solution :: Solution String Input Output
solution = Solution
{ parser = many (int `sepBy` char ' '
The idiomatic haskell way to write this would be the one-liner:
main = readFile "sample.txt" >>= print . foldr ((+) . foldr ((+) . last) 0 . takeWhile (any (/= 0)) . iterate (zipWith (-) tail id) . map read . words) 0 . lines
Then, simply run it from within the same directory containing both solve.hs and sample.txt with:
$ runhaskell solve.hs
initial = [6, 9, 4, 2, 0 {-etc-}]
deltas xs = zipWith (-) xs (tail xs)
-- not formatted
answer = takeWhile (not . null) $ iterate deltas initial
oh i didnt wait to hear out the whole problem lol
I'm very happy you got a problem so well suited for Haskell. You didn't get to see any of the stuff that makes us love haskell so much, like monads or lenses or data kinds.
I'll tell you a useful library most haskell programmers don't mention: the ST monad let's you have mutable variables in a pure function.
I've dabbled in haskell on and off for literal years and I *still* have never encountered a use for lenses. I usually write like 2-5 haskell programs a year, since ~2013, although I've slowed down in recent years.
If anyone wants to learn more / see more about haskell, I can recommend Tsodings old haskel videos. he used to be a haskell enthusiast
Another reason why Haskell is amazing: it enforces hexagonal architecture without the user even knowing
i have no idea what’s going on
Recursion is for beginners. A pro would define:
createPairs xs = zip xs (drop 1 xs)
Ty for doing these videos. I love them, but also take care of yourself. Don't burnout!
Flashbacks of learning to think in Common Lisp in uni in the 90's. Good times!
I like Haskell. It's a good way to challenge your brain to think differently (or at least for me that's the case). Don't know how practical it is, though.
do part 2, it's easy
Congratulations, you're well on the road to becoming a productive programmer!
Hi @LowLevelLearning i checked your website and i want to enroll for the ARM course which is still not up .... Also add a rust course this will also help a lot of people.
Hope u can bring the ARM course as fast as possible
what happened to days 6-8?
Speed ran them on twitch to catch up.
The last exam I took in my master's of computer engineering was called "principles of programming languages", where you had to learn Scheme, Haskell and Fortran. It was the most grueling experience of my life.
Also, the "do" monad was not allowed and it had to be solved on paper
"do" isn't a monad. It's a keyword that works with any monad. And you can always rewrite do {x >= \x -> b.
Low Level Learning do not like high level language. Huh.
I have 2 problems with haskell.
The first problem is information density. You might be able to do a lot more things in fewer lines but those fewer lines still have to carry all that information, so for me it becomes hard to mentally parse.
The second problem in the language for me is indenting. Haskell is whitespace sensitive and I generally dislike that. A lot of the time you will do something with the state monad and you end up with a "code tornado". Frequently you will end a do block with a "case" construct to pattern match the default cases in a recursive do block, because the language is whitespace sensitive you end up indenting 4-5 levels some of the time. It doesn't help that I like to have 8 wide indentation.
yeah, i don't really think 8 wide indentation is viable in haskell. one compromise i often use to reduce the excessive indentation levels is to use half-level indentation for single-line keywords like do and case etc. if i use 4 spaces of indentation i would indent the "do" keyword 2 spaces. another option is to put the keyword at the end of the previous line.
of course, neither of these will help with the information density problem. however, for me there is some reduction of information as well, at least as long as you stop thinking low level operationally but more higher level "what is the result?". For example, if I see in C code a for-loop that calculates the sum of an array, that carries a lot of details about how the sum is performed, which I may not care about, so just calling the "sum" function (or even "foldl' (+) 0") has less uninteresting details and boilerplate.
Information density is higher, but you just have to get out of the habit of just glimpsing at a line to know what it does since in most other language that's all it takes. You have to take your time to read and understand each line. You'll feel slow but all in all you're understanding the program at the same speed (once you're proficient), it is just much more compact.
I like whitespace sensitivity but in Haskell it's optional, you can use braces and semicolon instead if you prefer. Of course that won't help with code written by others…
And 8 spaces indentation is just too much !! 4 spaces is more viable and just as easy to parse visually, IMHO.
I doubt that I will ever understand the appeal of pure or nearly-pure functional programming languages.
Hey, I like your nvim theme! Would you mind sharing which one it is?
The only code I understood was the stuff chatgpt wrote, because it reminds me of how I solved things in lisp during university. Everything else broke my brain; the $ still scares me; I looked it up and I still can't follow why they are where in your code. I have no idea what's going on.
The '$' operator has a precedence level that basically let's you replace the parenthesis on the right half of your expression
map (+1) (getList myData)
Could become
map (+1) $ getList myData
It handles applying the argument myData to the function getList, and then has that value become the second argument to map
most recursionable functions are easily done with lists and scans…
this was like the IDEAL problem to do in haskell. but damn... that solution is ugly
🤣I have been using Haskell for about two years. Essentially, it teaches you to think functional, and that should be the main reason for using it.
Great, now you can publish a whitepaper!
For real though, I love Haskell-inspired features in Rust.
Hi, great video
What editor are you using? And what is the website where you find the problems?
This is making me want to try Haskell again.
Would you prefer to code in assembly? You're low level learning after all
Put Swift on the wheel.
I swear I'm watching a 21st Century Infocom game like Zork or Starcross. I expect one of the directions to be "You are likely to be eaten by a grue."
You could have done this much more mathematically with Lagrange interpolation. It would have been so easy it feels like cheating.
Congratulations man. You have gotten rid of your nightmare
5:50 : Jiminy Cricket from Puss in Boots: The Last Wish explains Haskell
P.S. Love your vids. Classic banger.
Dude, the OG LLG folks demanding something in Assembly?! C'mon, a cheeky little easy-day solution in Arm Assembly! :)
I can hear you have some nice linear switches (?) Did you build the keyboard yourself? Sounds pretty thocky.
The next language should be APL
I feel like I’m in the minority here, but this mostly made sense to me aside from weird operators I’m not used to(haven’t done anything with any language that isn’t object oriented ever), maybe I should try it at some point
The best starting point is imo the Elm guide!
Because the language is still very much Haskell-like, yet small and rather simple it gently introduces you to the syntax style, basic techniques and what purely functional programming is about in general. It will take you a few hours max. After that you can dive into more advanced topics in Haskell or something like PureScript, Idris, and so on.
Functional programming clicks better for some people than others. And likewise with Object Oriented and pretty much any other form of programming. I would give it a try to see if it suits you better. But I will warn you that if your job is object oriented programming your coworkers will start to hate you for bringing in functional programming gibberish and they won't be wrong :P
The fact that you knew about folds/reduces and such but not about the term "adjacent difference" ('adjDiff xs = zipWith (-) xs (tail xs))' maybe flip the - or tail vs non-tail) is wild to me. xD
Or deltas as they're commonly called. You can use the subtract function to avoid having to flip (-).
I had to spend so long on this one, mostly because I thought difference meant |x - y| and not just x - y
Be careful: Haskell can be additive. You feel so damn good when you figure something out after several hours, you gotta go back for another hit.
loops are an anti-pattern
Aaaaaaaaaaaaa!
Just reading that code was painful
Here you go. This should be much easier to understand. Even though it's Idris and not Haskell, here it's basically the same thing.
import Data.List
import Data.List1
import Data.String
-- List1 - a non-empty list
differences : List1 Integer -> List Integer
differences xs = zipWith (-) (tail xs) (init xs)
generateAllRows : List1 Integer -> List (List1 Integer)
generateAllRows xs = if all (== 0) xs
then [xs]
else xs :: case fromList (differences xs) of
Nothing => []
Just nonempty => generateAllRows nonempty
predict : List1 Integer -> Integer
predict = sum . map last . generateAllRows
main : IO ()
main = do
line main -- an empty input line needs to be skipped
printLn (predict numbers)
main
Cniles be like: We're gonna modify the ASM from memory on the fly in order to store the return pointer and creating a jump to the new function.
Also Cniles: Nooooo, recursion is tooo hard. I don't want to learn new FP concepts and it's the fault of FP.
where can i find exercises like this?
C#'s LINQ makes this brutally easy.
I guess worst thing about this code that you should read it in reverse to understand.
I like the concept of haskell, but the syntax always drives me insane; which is why I prefer ocaml. There is something to be said for a language that has mapping built directly into it, it allows you to easily deal with collections of data in a way that is somewhat more intuitive than using loops. I don't know if you've ever worked with APL or any of the other array-based languages, Haskell has a lot of those features even if it's not a true array based language. It's very much a research language, it doesn't make much sense when people use it in prod for enterprise solutions but some people are masochistic I suppose.
Honestly, the very weird syntax is the only reason I haven't used Ocaml outside of 2-3 code Katas I did once. Haskell really reads well for me in comparison, the only thing I wish it had was (.member) like syntax (like Idris has).
@@Adowrath it's funny, I used to like elm (before the community exploded) which uses a Haskell like syntax but it's syntax is much cleaner than Haskell itself. Idris too, has a much cleaner syntax when compared to Haskell. Ocaml reads like rust but with functional programming.
A lot of people blame the issue with Haskell on functional programming, but I started with fp instead of oo or imperative languages. The syntax just has too many points where it changes from prefix to infix and it has these bizarre operators which idiomatically don't use parentheses etc. even when I was contributing to cardano, I just didn't like using Haskell.
@@draakisback I love coding in Idris (wrote an experimental backend to Hasell for it lmao) but I actually, despite the foundational ideas, really didn't enjoy my time with Elm as much as I hoped to - a mix of elm-format being quite ugly, the non-existence of multiple clauses in function definitions, no typeclasses, and the choice of not allowing unprefixed usage of functions from other modules made it kind of a pain to use in that uni project once.
The one thing that is really confusing though is the ginormous list of precedence levels in Haskell compared to Idris, I'll give you that. I practically always try to write my code where infix operators are unambiguous in priority without using too many parentheses.
@@Adowrath I can understand that. For me elm was interesting because of the idioms and how clean it's syntax was. I know a lot of people didn't like that it was a fairly small and opinionated language. It's part of why the community exploded, so many people wanted to use it full stack and the main dev didn't want that.
@@draakisback Oh, that's what you meant by exploded, I thought you meant like they got really big. And yeah, it's definitely a great language if you can come to like it, the puzzle pieces of my brain just weren't the right shapes.
So Pascal's triangle but upside down?
TBH that my reaction whenever I get an AOC solution first try 10:18
Hmm...maybe THAT is why someone would program in Haskell!
and whats just as nuts is the second part is literally just as easy LOL