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!
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).
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).
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.
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"
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
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.
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.
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.
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
@@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).
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.
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).
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.
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.
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 ()
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.
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.
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.
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.
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.
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
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 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.
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
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.
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 ' '
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
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.
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.
*Program compiles and returns correct answer on the first try* "Why would anyone use this terrible language?" Cause it works, bruh... There's kinda no easier way to write algorithms. Wish it was as fast as C but it has a GC unfortunately.
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.
Very, very impressive actually, Im a FP guy, to me it seems that your a natural! F# and Ocaml are languages much like Haskell but without the pain and suffering that Haskell can bring. F# is my fav language, but the problem with FP languages is that languages like Rust, Swift and Kotlin gives you all the awesome goodies from FP language plus much more. And they are also more efficient. That basically means that FP languages will never be mainstream.
OCaml can be much more efficient than Kotlin, and in professional hands could be made to approach the level of Swift in some domains. F# is about the same as the equivalent Kotlin
Oh please, traverse print [1..100], what's the problem? traverse fizzBuzz [1..100] fizzBuzz :: Int -> IO () fizzBuzz num | num `mod` 3 == 0 && num `mod` 5 == 0 = putStrLn "FizzBuzz" | num `mod` 3 == 0 = putStrLn "Fizz" | num `mod` 5 == 0 = putStrLn "Buzz" fizzBuzz num = print num vs: def fizzBuzz(): for num in range(1,101): if not num % 3 and not num % 5: print("FizzBuzz") else if not num % 3: print("Fizz") else if not num % 5: print("Buzz") else: print(num)
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
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.
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
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.
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
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.
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.
"we can do this recursively … I just don’t want to". I felt that.
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.
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"
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? 😂
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.
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.
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.
wtf is this language, man
(XD)
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
This guy taught me how to code in high school, really cool dude, loving the content 👍
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 😂
it finally happened 😂😂😂
"Of course it's recursive." That's practically the Haskell motto.
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.
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.
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
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.
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.
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.
Oh god, I returned to my university years learning Haskell
You got lucky this day was so well suited for haskell, but congrats nonetheless!
Haskell is the greatest language to exist.
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 ()
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.
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.
About the error of the last expression not being IO, I recommend to finish `main` with `return ()`. Just note that `return` is different here :).
Will you do the missed days?
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.
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.
If anyone wants to learn more / see more about haskell, I can recommend Tsodings old haskel videos. he used to be a haskell enthusiast
Haskell and C are my two favorite programming languages! And I love embedded programming!!
I do low-level programming with Haskell via LLVM.
To understand what recursion is, you first need to understand what recursion is ...welcome to Haskell
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.
Ty for doing these videos. I love them, but also take care of yourself. Don't burnout!
6:39 Felt the "Wait, its recursive" in my soul from when I started to learn OCaml
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.
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.
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
Another reason why Haskell is amazing: it enforces hexagonal architecture without the user even knowing
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
Congratulations, you're well on the road to becoming a productive programmer!
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
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.
Flashbacks of learning to think in Common Lisp in uni in the 90's. Good times!
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.
The shortened format for this one doesn't do Haskell any favors as I quickly got lost in the sauce.
Dude, the OG LLG folks demanding something in Assembly?! C'mon, a cheeky little easy-day solution in Arm Assembly! :)
this was like the IDEAL problem to do in haskell. but damn... that solution is ugly
This is making me want to try Haskell again.
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.
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 ' '
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."
When you write in a declarative language but you do and abstract it imperatively, of course you will have this much trouble lol.
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
I forgot how beautifil this language is
Hey, I like your nvim theme! Would you mind sharing which one it is?
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.
I doubt that I will ever understand the appeal of pure or nearly-pure functional programming languages.
5:50 : Jiminy Cricket from Puss in Boots: The Last Wish explains Haskell
P.S. Love your vids. Classic banger.
Hi, great video
What editor are you using? And what is the website where you find the problems?
🤣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.
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.
what happened to days 6-8?
Speed ran them on twitch to catch up.
5:35 I thought I was listening to ThePrimeagen for one moment.
Congratulations man. You have gotten rid of your nightmare
I can hear you have some nice linear switches (?) Did you build the keyboard yourself? Sounds pretty thocky.
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
*Program compiles and returns correct answer on the first try* "Why would anyone use this terrible language?" Cause it works, bruh... There's kinda no easier way to write algorithms. Wish it was as fast as C but it has a GC unfortunately.
There's no point in being fast as C if you're not doing low level though
Sheer commitment or a love for bdsm I dunno which. I would’ve never ever done it, so you have my respect!✊🏿
C#'s LINQ makes this brutally easy.
Great, now you can publish a whitepaper!
For real though, I love Haskell-inspired features in Rust.
Recursion is for beginners. A pro would define:
createPairs xs = zip xs (drop 1 xs)
yeah chatgpt is not so great at haskell I have noticed
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.
Very, very impressive actually, Im a FP guy, to me it seems that your a natural! F# and Ocaml are languages much like Haskell but without the pain and suffering that Haskell can bring. F# is my fav language, but the problem with FP languages is that languages like Rust, Swift and Kotlin gives you all the awesome goodies from FP language plus much more. And they are also more efficient. That basically means that FP languages will never be mainstream.
Depends on how you define efficient.
@@MrPoselsky True, its a little bit in the argue category.
OCaml can be much more efficient than Kotlin, and in professional hands could be made to approach the level of Swift in some domains. F# is about the same as the equivalent Kotlin
@@AnthonyBullard I agree. I believe that Ocaml has gotten some recent solid upgrades as well in the compiler. So I stand corrected!
Oh please, traverse print [1..100], what's the problem?
traverse fizzBuzz [1..100]
fizzBuzz :: Int -> IO ()
fizzBuzz num
| num `mod` 3 == 0 && num `mod` 5 == 0 = putStrLn "FizzBuzz"
| num `mod` 3 == 0 = putStrLn "Fizz"
| num `mod` 5 == 0 = putStrLn "Buzz"
fizzBuzz num = print num
vs:
def fizzBuzz():
for num in range(1,101):
if not num % 3 and not num % 5: print("FizzBuzz")
else if not num % 3: print("Fizz")
else if not num % 5: print("Buzz")
else: print(num)
and whats just as nuts is the second part is literally just as easy LOL
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 (-).
most recursionable functions are easily done with lists and scans…
where can i find exercises like this?
Good on you and well done!
Would you mind to share your nvim config?
Thanks
"C programmer" that's enough to make me cry
do part 2, it's easy
Language Acquisition Syndrome, Gear Acquisition Syndrome for programmers : )
Thanks for the videos. What Vim colorscheme are you using?
onedark
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.
Hmm...maybe THAT is why someone would program in Haskell!
the best thing about haskell is that you dont have to use it
TBH that my reaction whenever I get an AOC solution first try 10:18
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
Low Level Learning do not like high level language. Huh.
looks like my notes after 1 month
Put Swift on the wheel.