Newest at the top
| 2024-05-12 11:20:11 +0200 | Sgeo_ | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-05-12 11:19:36 +0200 | <mauke> | ^ like this thing. just two lines of code, fairly short; doesn't use any crazy language extensions; and yet ... wtf even is that |
| 2024-05-12 11:19:09 +0200 | <Hecate> | glguy: do you accept compat PRs for https://github.com/glguy/language-lua ? I need to work with GHC 9.8 |
| 2024-05-12 11:18:55 +0200 | <mauke> | loeb :: Functor f => f (f a -> a) -> f a; loeb x = y where y = fmap (\f -> f y) x |
| 2024-05-12 11:17:38 +0200 | <sandbag> | i never really understood the importance of OOP. it is just there to complicate things |
| 2024-05-12 11:16:43 +0200 | <sandbag> | mauke: absolutely! java is extremely verbose |
| 2024-05-12 11:16:12 +0200 | <sandbag> | oh, that's interesting |
| 2024-05-12 11:16:06 +0200 | <mauke> | java is also famous for being needlessly verbose |
| 2024-05-12 11:15:19 +0200 | <mauke> | to me, haskell is unique because you can stack abstractions on top of each other to create absolutely brain-breaking code in 3 or 4 lines |
| 2024-05-12 11:14:51 +0200 | <sandbag> | mauke: yeah, perl as well. so is it mostly from C or some other language? |
| 2024-05-12 11:13:07 +0200 | <mauke> | which also applies to perl |
| 2024-05-12 11:12:49 +0200 | <mauke> | I'd say what python and haskell have in common is fairly high-level abstractions (no need for explicit or manual memory allocation, for example) and an ecosystem of reusable modules |
| 2024-05-12 11:12:35 +0200 | <sandbag> | mauke: absolutely. |
| 2024-05-12 11:11:28 +0200 | <sandbag> | [Leary]: true |
| 2024-05-12 11:10:59 +0200 | <sandbag> | for python, I can understand because of lots of abstraction. is it similar in haskell? |
| 2024-05-12 11:10:51 +0200 | <mauke> | depends on the task and the language |
| 2024-05-12 11:10:14 +0200 | <sandbag> | functional languages do look a bit similar to python (mostly syntax and less amount of code). if you look at C or Go, you are writing a lot of code. but in python or haskell, it's less |
| 2024-05-12 11:10:14 +0200 | <[Leary]> | The MLs do share Haskell's parametric polymorphism and some syntax, but Haskell being both pure and lazy is somewhat of an island; there are no widely used programming languages that are genuinely similar. |
| 2024-05-12 11:09:39 +0200 | <mauke> | but not lazy and not pure (ad-hoc side effects allowed everywhere) |
| 2024-05-12 11:08:56 +0200 | <mauke> | very similar syntax and type system |
| 2024-05-12 11:08:53 +0200 | <sandbag> | ah, that's great. i will pick it up after writing some haskell |
| 2024-05-12 11:08:02 +0200 | <mauke> | pretty similar in many ways |
| 2024-05-12 11:07:54 +0200 | <sandbag> | btw, completely offtopic but is ocaml similar to haskell or completely different? |
| 2024-05-12 11:06:41 +0200 | <sandbag> | that's interesting |
| 2024-05-12 11:06:21 +0200 | <mauke> | or in our case, to eliminate the need for naming arguments in lambda functions |
| 2024-05-12 11:06:09 +0200 | <mauke> | "Combinatory logic is a notation to eliminate the need for quantified variables in mathematical logic." |
| 2024-05-12 11:06:09 +0200 | mikess | (~mikess@user/mikess) (Quit: mikess) |
| 2024-05-12 11:06:03 +0200 | <sandbag> | i will resume my journey on functional programming |
| 2024-05-12 11:05:49 +0200 | <mauke> | if you want to get scared, https://en.wikipedia.org/wiki/Combinatory_logic |
| 2024-05-12 11:05:25 +0200 | <sandbag> | anywho, thanks for the explanation. it's much clear now |
| 2024-05-12 11:05:19 +0200 | cafkafk | (~cafkafk@fsf/member/cafkafk) (Quit: WeeChat 4.2.2) |
| 2024-05-12 11:04:48 +0200 | <sandbag> | and i suck at math |
| 2024-05-12 11:04:43 +0200 | <sandbag> | looks like a very complex math equation :| |
| 2024-05-12 11:04:40 +0200 | <mauke> | and now you can write all functions without arguments :-) |
| 2024-05-12 11:04:19 +0200 | <mauke> | commonly known as S and K, defined as: K x y = x; S x y z = (x z) (y z) |
| 2024-05-12 11:03:57 +0200 | <sandbag> | true |
| 2024-05-12 11:03:38 +0200 | <mauke> | but it turns out you can always do it if you allow some simple helper functions |
| 2024-05-12 11:03:38 +0200 | euleritian | (~euleritia@ip-185-104-138-28.ptr.icomera.net) |
| 2024-05-12 11:03:23 +0200 | <sandbag> | so, if you are referencing or using some other function, at that time arguments aren't required |
| 2024-05-12 11:03:10 +0200 | <mauke> | you can't directly get the 'x' out of the middle of an expression |
| 2024-05-12 11:02:53 +0200 | <mauke> | or even just \x -> f x 42 |
| 2024-05-12 11:02:44 +0200 | <sandbag> | yeah |
| 2024-05-12 11:02:21 +0200 | <mauke> | here we use the argument x not just as the last argument to some other function |
| 2024-05-12 11:02:00 +0200 | <mauke> | consider \x -> f x x |
| 2024-05-12 11:01:46 +0200 | <mauke> | not completely |
| 2024-05-12 11:01:27 +0200 | <mauke> | \x -> (... anything here ...) x |
| 2024-05-12 11:01:27 +0200 | <sandbag> | in that manner, doesn't that eliminate the need of arguments then? |
| 2024-05-12 11:01:20 +0200 | <mauke> | well, and the thing it's applying the (inner) function to is the argument of the (outer) function |
| 2024-05-12 11:01:00 +0200 | <mauke> | any time you have a function whose outermost expression (in the function body) is a function application |
| 2024-05-12 11:00:43 +0200 | <sandbag> | oh, could be any function? |