Newest at the top
| 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? |
| 2024-05-12 11:00:12 +0200 | <mauke> | doesn't even have to be "middle" or "top" |
| 2024-05-12 11:00:05 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-05-12 10:59:44 +0200 | <sandbag> | ah, that makes sense. so i can get away by not passing arguments to some middle function which points to a top function which has the same argument |
| 2024-05-12 10:58:17 +0200 | <mauke> | just as in 'f x = g x' you can "cancel" the x on both sides, so in 'html_ content = (el "html") content' you can cancel the content on both sides |
| 2024-05-12 10:57:58 +0200 | <sandbag> | im new to functional programming. forgive me for any kind of silly questions :) |
| 2024-05-12 10:57:09 +0200 | <sandbag> | your snippet makes sense. so the one I sent is similar? |
| 2024-05-12 10:56:57 +0200 | <mauke> | it comes to the same thing |
| 2024-05-12 10:56:54 +0200 | <mauke> | fundamentally, it's like writing 'f = g' instead of 'f x = g x' |
| 2024-05-12 10:56:30 +0200 | <mauke> | because all it does is forward its argument to another function |