| 2024-12-28 00:00:32 +0100 | <mauke> | progress! |
| 2024-12-28 00:00:42 +0100 | <monochrom> | "one more turn" |
| 2024-12-28 00:01:45 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) (Ping timeout: 260 seconds) |
| 2024-12-28 00:03:27 +0100 | <Zenen> | it's just around this corner, i swear |
| 2024-12-28 00:06:28 +0100 | <OftenFaded> | I've heard haskell isn't as performant as some languages like C, is this a unsubstantial nitpick or an outdated assessment? |
| 2024-12-28 00:06:57 +0100 | <geekosaur> | graph reduction is always a bit slower than direct execution |
| 2024-12-28 00:07:05 +0100 | <geekosaur> | but it's also what enables full laziness |
| 2024-12-28 00:07:23 +0100 | rekahsoft | (~rekahsoft@76.69.85.220) rekahsoft |
| 2024-12-28 00:07:55 +0100 | <homo> | well, there are bangpatterns that strip laziness part |
| 2024-12-28 00:08:01 +0100 | <OftenFaded> | so ultimately there is no intent to make haskell a performant language from the start? |
| 2024-12-28 00:08:39 +0100 | <monochrom> | You don't hear that about Python, yet it's true. The meta-question is why people talk about Haskell performance but not Python performance? Javascript performance? |
| 2024-12-28 00:09:20 +0100 | <OftenFaded> | very true. I also want answers to these metaquestions |
| 2024-12-28 00:09:41 +0100 | <geekosaur> | not really, you can think of it as being more methodical in the name of laziness and sharing, vs. C's charging bull |
| 2024-12-28 00:09:44 +0100 | prasad | (~Thunderbi@c-73-75-25-251.hsd1.in.comcast.net) (Ping timeout: 260 seconds) |
| 2024-12-28 00:09:46 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 00:10:05 +0100 | <geekosaur> | but speed isn't everything: people use Python for a reason, despite it being fairly slow compared to C |
| 2024-12-28 00:10:16 +0100 | <monochrom> | Even slower than Haskell. |
| 2024-12-28 00:10:45 +0100 | <Clint> | if you ignore program startup, haskell outperforms just about everything |
| 2024-12-28 00:11:07 +0100 | <monochrom> | And C, in turn, slower than Fortran. |
| 2024-12-28 00:11:08 +0100 | <Zenen> | well that's a pretty cool statement |
| 2024-12-28 00:12:17 +0100 | <monochrom> | The truth is that people first arbitrarily choose a language they like and then manufacture "reasons". |
| 2024-12-28 00:12:23 +0100 | <Zenen> | ayy it compiled! |
| 2024-12-28 00:13:01 +0100 | <OftenFaded> | monochrom: but what about after that? what do people go to after they see through their 'reasons'? |
| 2024-12-28 00:13:15 +0100 | <Zenen> | I have been writing in Python for quite a while now, largely because I'm trying to write code that is good for teaching others |
| 2024-12-28 00:13:38 +0100 | <Zenen> | and also because computers are generally crazy fast and well written code will work well, even on slow programming languages |
| 2024-12-28 00:13:43 +0100 | <monochrom> | Haha they see through their own manufactured "reasons"? |
| 2024-12-28 00:14:02 +0100 | <OftenFaded> | on a long enough timeline surely they do |
| 2024-12-28 00:14:04 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-28 00:14:15 +0100 | <Zenen> | that said, I like the idea of being able to think and program functionally, and I don't want to program in Python forever |
| 2024-12-28 00:14:32 +0100 | <geekosaur> | well, there's also for example that any data structure more involved than a simple array absolutely sucks in C |
| 2024-12-28 00:14:51 +0100 | <geekosaur> | most notably: strings |
| 2024-12-28 00:15:11 +0100 | ubert1 | (~Thunderbi@p200300ecdf117c91b816f4b90c54fbf2.dip0.t-ipconnect.de) ubert |
| 2024-12-28 00:15:24 +0100 | ubert | (~Thunderbi@p200300ecdf117c4260f23471b0d1d1bb.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2024-12-28 00:15:24 +0100 | ubert1 | ubert |
| 2024-12-28 00:15:43 +0100 | <homo> | isn't there python interpreter written in subset of python and compiler for that subset of python to achieve performance while interpreting python? |
| 2024-12-28 00:15:50 +0100 | <OftenFaded> | It's just curious to me how haskell remains in this 'academic-only' view. Shouldn't the most academic language also be the most practical in some sense? |
| 2024-12-28 00:18:03 +0100 | <mauke> | "is this a unsubstantial nitpick or an outdated assessment?" <- no |
| 2024-12-28 00:19:06 +0100 | <mauke> | the problem with C is that it's so far removed from hardware, making it hard to write efficient code |
| 2024-12-28 00:19:14 +0100 | <homo> | also how does one measure speed of language when different implementations produce different benchmarks? you can even make C compiler that produces slower binaries than gcc |
| 2024-12-28 00:19:44 +0100 | <monochrom> | Presumably you can compare the fastest implementations available. |
| 2024-12-28 00:20:00 +0100 | <monochrom> | This is actually not hard because a lot of languages have unique implementations. |
| 2024-12-28 00:20:13 +0100 | <mauke> | processors aren't getting any faster and getting C programs to use multiple cores efficiently is no fun |
| 2024-12-28 00:20:35 +0100 | <homo> | in case with python, you can take rpython as fastest, but does anyone seriously use it in production? |
| 2024-12-28 00:20:54 +0100 | <monochrom> | A few have multitudes, but after decades of competition and sharing, the multitudes perform pretty much the same. |
| 2024-12-28 00:21:57 +0100 | <monochrom> | Or yeah, compare the most used implementations. |
| 2024-12-28 00:22:18 +0100 | <homo> | https://pypy.org/ it is written in python and claims to be 4.4 times faster than cpython |
| 2024-12-28 00:23:21 +0100 | <OftenFaded> | you guys are making me feel silly for caring about the perceived performance of a language |
| 2024-12-28 00:23:53 +0100 | <homo> | well, if you want slow haskell binaries, microhs is the way to go :) |
| 2024-12-28 00:24:41 +0100 | <monochrom> | It was actually unclear that you cared about performance, as opposed to, you cared about what other people said about performance. |
| 2024-12-28 00:25:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 00:25:24 +0100 | <OftenFaded> | I'm an idiot, so the truth of these things is only accessible via humble wizards like most in this room |
| 2024-12-28 00:27:00 +0100 | <OftenFaded> | I'm a unacademic hobbyist trying to build/automate things in haskell, and learning how to create 'well-written' code is tough as a self-taught individual |
| 2024-12-28 00:27:29 +0100 | <Zenen> | well written code will generally be performant |
| 2024-12-28 00:27:34 +0100 | <Zenen> | or at least, easy to optimize |
| 2024-12-28 00:28:50 +0100 | <Zenen> | I think that the real danger is 'clever' code that becomes difficult to use when you forget about how it works after a year |
| 2024-12-28 00:29:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 00:31:26 +0100 | <homo> | the worrisome question: can you trust ghc if you cannot build it with any other haskell implementation |
| 2024-12-28 00:31:58 +0100 | <Zenen> | !! This sounds like some spicy haskell drama |
| 2024-12-28 00:32:29 +0100 | <Zenen> | Isn't GHC the original compiler though? |
| 2024-12-28 00:33:08 +0100 | <Zenen> | oh wait... you're talking about the bootstrap process? |
| 2024-12-28 00:33:17 +0100 | <homo> | yes, bootstrap |
| 2024-12-28 00:34:14 +0100 | <Zenen> | that is one of the reasons that golang susses me out |
| 2024-12-28 00:34:25 +0100 | <geekosaur> | how many other C compilers are there? |
| 2024-12-28 00:34:56 +0100 | <mauke> | isn't gcc written in GNU C++? |
| 2024-12-28 00:35:01 +0100 | <Zenen> | gccgo seems to have addressed the issue, but I kind of give special privilege to gcc |
| 2024-12-28 00:35:22 +0100 | <geekosaur> | that's the problem, though |
| 2024-12-28 00:35:59 +0100 | <homo> | https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/ |
| 2024-12-28 00:36:15 +0100 | <geekosaur> | gcc has almost died a couple of times, and the number of people who could pick it up and keep it going gets smaller with every fancy optimization they add |
| 2024-12-28 00:36:39 +0100 | <Zenen> | i was unaware of this |
| 2024-12-28 00:36:41 +0100 | <homo> | #bootstrappable folks can make full source bootstrap starting with 357 byte binary (which recently got reduced in size) |
| 2024-12-28 00:37:24 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 264 seconds) |
| 2024-12-28 00:37:37 +0100 | <homo> | haskell is still in todo |
| 2024-12-28 00:38:02 +0100 | <Zenen> | I've always considered gcc to be the lynchpin between hardware and software |
| 2024-12-28 00:39:07 +0100 | <Zenen> | like, I don't have to worry about anything beyond compiling to C because gcc offers a unified interface to all the different architectures |
| 2024-12-28 00:39:08 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2024-12-28 00:39:39 +0100 | <Zenen> | and I can't really hold space in my brain to think about different hardware architectures |
| 2024-12-28 00:39:43 +0100 | <homo> | there was an attempt to bootstrap ghc from nhc98, but it failed https://elephly.net/posts/2017-01-09-bootstrapping-haskell-part-1.html |
| 2024-12-28 00:40:50 +0100 | <geekosaur> | no, pretty sure you needed to go MLTon->LML->HBC->GHC (not sure what you need to bootstrap MLTon. SML/NJ?) |
| 2024-12-28 00:41:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 00:41:18 +0100 | <geekosaur> | and one of those is currently only available as i386 binaries that probably don't even run on modern systems |
| 2024-12-28 00:41:18 +0100 | <Zenen> | oh goodness |
| 2024-12-28 00:41:30 +0100 | <geekosaur> | (sadly) |
| 2024-12-28 00:42:01 +0100 | <homo> | there is complaint on #bootstrappable that ghc 0.26 requires ghc, ghc 0.24 was compileable with hbc, but the source code of ghc 0.24 has completely disappeared from the internet |
| 2024-12-28 00:42:42 +0100 | <Zenen> | so like... where does one go from this point? |
| 2024-12-28 00:42:42 +0100 | <haskellbridge> | <loonycyborg> can ghc entirely compile itself to C? |
| 2024-12-28 00:43:27 +0100 | <homo> | currently guix uses generated C code to compile ghc, but that is not a clean bootstrap, generated code is dirty no matter whether it is C code or machine code |
| 2024-12-28 00:44:02 +0100 | <geekosaur> | loonycyborg, if you build ghc in unregisterised mode it will generate ANSI C |
| 2024-12-28 00:44:20 +0100 | <geekosaur> | the result is very slow but very portable |
| 2024-12-28 00:44:40 +0100 | <haskellbridge> | <loonycyborg> ye I assume it's useful for porting to new platforms |
| 2024-12-28 00:44:41 +0100 | <Zenen> | Can you use that ghc to build faster GHCs? |
| 2024-12-28 00:45:00 +0100 | <Zenen> | i'm suspicious of haskell now |
| 2024-12-28 00:45:03 +0100 | <geekosaur> | generally you use it as a starting point to write a registerised/asm backend, yes |
| 2024-12-28 00:45:16 +0100 | <Zenen> | this is why I don't think about compilers too much |
| 2024-12-28 00:45:41 +0100 | <haskellbridge> | <loonycyborg> unregistered refers to cpu registers? |
| 2024-12-28 00:45:54 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 00:46:08 +0100 | <geekosaur> | originally, yes |
| 2024-12-28 00:46:10 +0100 | <homo> | another complained on #bootstrappable is that ghc maintainers require too much extensions to compile ghc, which makes it impossible to build not just with other implementations, but also with ghc itself |
| 2024-12-28 00:46:19 +0100 | <homo> | like you cannot compile ghc 9 with ghc 4 |
| 2024-12-28 00:46:31 +0100 | <homo> | s/complained/complaint/ |
| 2024-12-28 00:47:08 +0100 | <geekosaur> | in the old days ghc generated modified C source which had to be asm-d and then run through a thing called the Evil Mangler which translated the register assignments from platform standard to what the STG engine uses |
| 2024-12-28 00:48:06 +0100 | <haskellbridge> | <loonycyborg> sounds mindbending |
| 2024-12-28 00:48:10 +0100 | <OftenFaded> | evil mangler...what a glorious name |
| 2024-12-28 00:48:45 +0100 | <Zenen> | I might just go pick up Erlang |
| 2024-12-28 00:49:22 +0100 | <homo> | the bootstrap chain is very long and only recently they fixed bootstrap gap in 7.x where compiled ghc 7.4 segfaulted while trying to build itself |
| 2024-12-28 00:49:24 +0100 | <mauke> | and the mangler was written in (pretty bad) perl |
| 2024-12-28 00:49:34 +0100 | <mauke> | possibly perl4 |
| 2024-12-28 00:50:01 +0100 | <homo> | which makes a real mystery where upstream 7.x binaries come from |
| 2024-12-28 00:51:05 +0100 | <geekosaur> | at one poimnt there was a hard rule that it had to be built with the most recent release of the previous version |
| 2024-12-28 00:51:33 +0100 | <geekosaur> | that has been extended to "past two versions" and there is some effort for the same version, but not officially supported |
| 2024-12-28 00:52:52 +0100 | <homo> | but that not only creates very long bootstrap chain, but also is very hostile to other implementations of haskell, it is a race for extensions that alternative implementations cannot win |
| 2024-12-28 00:53:32 +0100 | <haskellbridge> | <loonycyborg> what are current most active non-ghc haskell implementations? |
| 2024-12-28 00:53:41 +0100 | <geekosaur> | MicroHS |
| 2024-12-28 00:53:48 +0100 | <homo> | and blynn compiler |
| 2024-12-28 00:54:06 +0100 | <geekosaur> | and that's about it. Hugs still holds on in manintenance mode because there are universities that use it |
| 2024-12-28 00:54:44 +0100 | <homo> | what maintenance mode? it hasn't been updated for quite a long time |
| 2024-12-28 00:55:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 00:55:35 +0100 | <geekosaur> | and yeh, ghc's pretty extension-happy. we keep getting people writing code for Cabal who trip up over our 5-year support window, meaning their favorite modern extensions don't pass CI |
| 2024-12-28 00:55:46 +0100 | <haskellbridge> | <sm> hell is like a nano haskell, also active |
| 2024-12-28 00:55:49 +0100 | <geekosaur> | someone keeps it compiling, apparently |
| 2024-12-28 00:56:01 +0100 | <geekosaur> | (barely) |
| 2024-12-28 00:56:46 +0100 | <homo> | what is the latest version of ghc is compileable with microhs considering that microhs supports about 50 extensions? |
| 2024-12-28 00:57:45 +0100 | <geekosaur> | I don't think anyone has tried |
| 2024-12-28 00:58:19 +0100 | <geekosaur> | but MicroHS is deliberatelyh missing alkl the type level extensions, which would bring iut to a very fast halt because of TreesThatGrow |
| 2024-12-28 00:58:45 +0100 | <geekosaur> | sorry about all the errors there |
| 2024-12-28 00:59:00 +0100 | <geekosaur> | I should back out of convos while trying to eat dinner 🙂 |
| 2024-12-28 01:00:21 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-12-28 01:00:39 +0100 | <haskellbridge> | <sm> matrix edits are a godsend |
| 2024-12-28 01:01:43 +0100 | <OftenFaded> | monochrom: you have me in a spiral of doubt with your 'manufactured reasons' point. Is the reason for choosing a language truly arbitrary? And if so, why are we here? Why do we have a liking for haskell over others if it's truly arbitrary? |
| 2024-12-28 01:02:40 +0100 | <OftenFaded> | Like I enjoy learning haskell through xmonad, but would I be better off learning python in a qtile environment? one must be better than the other, no? |
| 2024-12-28 01:02:44 +0100 | <geekosaur> | it's not arbitrary. it's referring to various anti-Haskell memes that don't even begin to hold up to reality |
| 2024-12-28 01:03:17 +0100 | <homo> | the reasons to like haskell: strong static typing, IO monad, lazy evaluations and syntax is cuter than that of lisp, haxe and erlang |
| 2024-12-28 01:03:25 +0100 | <OftenFaded> | maaan, got got on a meme again. where is the rickroll link hiding |
| 2024-12-28 01:04:00 +0100 | <homo> | in guix I write lisp on daily basis, so I know lisp is pain to read and write |
| 2024-12-28 01:04:20 +0100 | <OftenFaded> | also how long has this room been bridged to matrix? |
| 2024-12-28 01:05:48 +0100 | <geekosaur> | mm, don't recall when I started running the predecessor to this bridge. although even that was the second time; back on freenode #haskell:matrix.org was bridged to the fn version of this channel, and I have no idea how long that was true |
| 2024-12-28 01:05:49 +0100 | <homo> | it's impossible to enjoy any other functional language without those 4 basic features that haskell has |
| 2024-12-28 01:06:30 +0100 | <geekosaur> | it was discontinued on the move to libera, and only came back when I brought up matterbridge. then that broke on me earlier this year and I moved to heisenbridge |
| 2024-12-28 01:06:34 +0100 | <haskellbridge> | <loonycyborg> most notable to me is that exact order of statements doesn't matter |
| 2024-12-28 01:06:38 +0100 | <geekosaur> | I think it's been around a year total |
| 2024-12-28 01:06:51 +0100 | <geekosaur> | well, 13 months |
| 2024-12-28 01:07:32 +0100 | <haskellbridge> | <loonycyborg> that way you can write a program in some order that matters to you |
| 2024-12-28 01:07:43 +0100 | <haskellbridge> | <loonycyborg> maybe for clarity for example |
| 2024-12-28 01:08:37 +0100 | <geekosaur> | top down vs. bottom up has been a feud that probably goes back to Ada Lovelace 😛 |
| 2024-12-28 01:08:59 +0100 | <OftenFaded> | haven't heard of heisenbridge, I'mma have to check this out to see if I can reconnect with discord homies |
| 2024-12-28 01:10:43 +0100 | <homo> | loonycyborg reminds me that in go you can split same module into multiple files, like file1.go contains "package mymodule" file2.go contains "package mymodule" file3.go also contains "package mymodule", I've never seen haskell modules being split like that |
| 2024-12-28 01:12:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 01:12:15 +0100 | aerphanas | (~aerphanas@user/aerphanas) aerphanas |
| 2024-12-28 01:12:16 +0100 | <monochrom> | homo: It is possible to like Racket for its delimited continuation, dynamic typing, and s-expression syntax. I almost did. |
| 2024-12-28 01:13:26 +0100 | <monochrom> | "Fortunately", it breaks currying, so I headed back to Haskell. >:) |
| 2024-12-28 01:13:29 +0100 | <homo> | monochrom I have enough of dynamic typing in guile and it is a big pain |
| 2024-12-28 01:14:02 +0100 | <monochrom> | Oh, I don't actually use dynamic typing. |
| 2024-12-28 01:14:04 +0100 | <geekosaur> | still better than C… |
| 2024-12-28 01:14:25 +0100 | <homo> | not to mention how it's impossible to understand error message produced by dynamic typing |
| 2024-12-28 01:14:28 +0100 | <haskellbridge> | <loonycyborg> you haven't seen dynamic typing until you tried a language that allows you to add number to a string |
| 2024-12-28 01:14:48 +0100 | <homo> | do you mean javascript? |
| 2024-12-28 01:14:49 +0100 | <monochrom> | haha |
| 2024-12-28 01:14:50 +0100 | <haskellbridge> | <loonycyborg> iirc it was lua |
| 2024-12-28 01:15:27 +0100 | <monochrom> | Stronger: you haven't seen dynamic typing until you see the javascript trinity. >:) |
| 2024-12-28 01:15:40 +0100 | <homo> | do it add number to the number in the string or does it contatenate number to the string? |
| 2024-12-28 01:15:43 +0100 | <geekosaur> | or php |
| 2024-12-28 01:15:55 +0100 | <haskellbridge> | <loonycyborg> I don't remember |
| 2024-12-28 01:16:12 +0100 | <haskellbridge> | <loonycyborg> I would assume it would try to show the string |
| 2024-12-28 01:16:26 +0100 | <haskellbridge> | <loonycyborg> maybe doesn't even apply to current versions |
| 2024-12-28 01:16:46 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-28 01:16:49 +0100 | <homo> | tbh thanks to haskell I no longer understand imperative languages |
| 2024-12-28 01:16:50 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 265 seconds) |
| 2024-12-28 01:17:02 +0100 | <homo> | imperative languages are so counter-intuitive |
| 2024-12-28 01:17:22 +0100 | <jle`> | imperative programming in haskell makes so much sense that imperative programming in imperative languages seems weird |
| 2024-12-28 01:17:30 +0100 | <monochrom> | We need to make a joke language that defines number+string to be this: convert the number to string, convert the string to number with default 0 then convert back to string, then concatenate. |
| 2024-12-28 01:17:31 +0100 | <homo> | yes! |
| 2024-12-28 01:17:54 +0100 | <monochrom> | then convert back to number! |
| 2024-12-28 01:18:03 +0100 | <monochrom> | So for example 4 + "a" = 40 |
| 2024-12-28 01:19:38 +0100 | <Zenen> | 4:"t":"a" -> "four":"t":"a" -> "fourty" -> 40 |
| 2024-12-28 01:19:50 +0100 | <homo> | anyway, speaking of bootstrapping, ghc depends way too much on its own extensions, it depends on extensions to implement itself, I like haskell as a language, but I am not a fan of its toolchain ecosystem |
| 2024-12-28 01:20:25 +0100 | <monochrom> | Yeah I don't get why people don't like monad for imperative programming and make it sound like it's additional and unnatural. The explicit >>= clarifies what's really going on. |
| 2024-12-28 01:20:55 +0100 | <monochrom> | whereas the misleading syntax "print(getchar())" is the confusing one. |
| 2024-12-28 01:21:26 +0100 | <monochrom> | "oh it's so academic" No, it's more honest. |
| 2024-12-28 01:21:34 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) emmanuelux |
| 2024-12-28 01:21:47 +0100 | <haskellbridge> | <loonycyborg> I tend to see monads as something like Command pattern |
| 2024-12-28 01:21:50 +0100 | <monochrom> | Also what's wrong with being academic? OOP started out as purely academic, too. So what. |
| 2024-12-28 01:22:21 +0100 | <homo> | funny enough I see haskell as OOP |
| 2024-12-28 01:23:35 +0100 | <OftenFaded> | academia doesn't have the best image currently |
| 2024-12-28 01:23:58 +0100 | <homo> | I was taught that OOP has 4 pillars: abstraction, encapsulation, polymorphism and inheritance, name one pillar that haskell doesn't have |
| 2024-12-28 01:24:04 +0100 | <OftenFaded> | lots of 'woke cultural marxists poisoning the youth with gender theories' and whatnot |
| 2024-12-28 01:24:35 +0100 | <monochrom> | Maybe not very generalizable to other disciplines, but in the context of PL, you can count on academia being honest about complexity, and you can count on self-identified "practical" people being liars hiding their complexities and denying that they have made footguns. |
| 2024-12-28 01:25:33 +0100 | <haskellbridge> | <loonycyborg> if they rely on trade secrets and the like to get ahead of competition then of course they would have to lie a lot |
| 2024-12-28 01:25:41 +0100 | <haskellbridge> | <loonycyborg> with at least lies of omission |
| 2024-12-28 01:25:48 +0100 | <monochrom> | Haskell doesn't have their polymorphism. Haskell has the opposite kind. |
| 2024-12-28 01:26:13 +0100 | <homo> | loonycyborg you forgot about narcissism |
| 2024-12-28 01:27:42 +0100 | <haskellbridge> | <loonycyborg> though anyone can do their learning and result doesn't depend on whether it's in academia or not |
| 2024-12-28 01:27:48 +0100 | <haskellbridge> | <loonycyborg> only on effort put in |
| 2024-12-28 01:28:08 +0100 | <homo> | OftenFaded don't know what you are talking about, in my experience school youth is poisoned with close-minded hateful christianity |
| 2024-12-28 01:28:30 +0100 | <OftenFaded> | superb counterpoint I can't argue with at all |
| 2024-12-28 01:28:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 01:28:59 +0100 | <OftenFaded> | jeebus is truth evolution is black magic |
| 2024-12-28 01:29:16 +0100 | iteratee | (~kyle@162.218.222.207) (Read error: Connection reset by peer) |
| 2024-12-28 01:29:28 +0100 | iteratee | (~kyle@162.218.222.207) iteratee |
| 2024-12-28 01:29:33 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) |
| 2024-12-28 01:31:43 +0100 | <OftenFaded> | Need to leave soon folks, does anyone have a matrix room link by chance? |
| 2024-12-28 01:33:02 +0100 | <haskellbridge> | <Bowuigi> #haskell:matrix.org (https://matrix.to/#/#haskell:matrix.org) this? I wonder if IRC displays it properly lol |
| 2024-12-28 01:33:30 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-12-28 01:33:41 +0100 | <OftenFaded> | works for me! merci! |
| 2024-12-28 01:34:32 +0100 | <geekosaur> | it does |
| 2024-12-28 01:34:56 +0100 | <geekosaur> | but the link for *this* room is https://matrix.to/#/%23haskell-irc%3Amatrix.org?via=matrix.org&via=kf8nh.com&via=kde.org |
| 2024-12-28 01:35:10 +0100 | OftenFaded | (~OftenFade@user/tisktisk) (Quit: Client closed) |
| 2024-12-28 01:35:19 +0100 | <geekosaur> | #haskell:matrix.org was linked on freenode but declined to re-establish the link on libera, as I said earlier |
| 2024-12-28 01:36:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 01:38:17 +0100 | <homo> | while digging hugs's source code, I was surprised to find it contains implementation of prolog |
| 2024-12-28 01:38:24 +0100 | <homo> | prolog implemented in haskell... |
| 2024-12-28 01:38:42 +0100 | <Zenen> | [rationality intensifies] |
| 2024-12-28 01:38:49 +0100 | <geekosaur> | wouldn't have been related to functional dependencies, would it? |
| 2024-12-28 01:39:05 +0100 | <geekosaur> | they're more or less prolog in haskell's type system |
| 2024-12-28 01:39:28 +0100 | <haskellbridge> | <Bowuigi> I think it is related to MPTC and overlapping instances |
| 2024-12-28 01:39:41 +0100 | <haskellbridge> | <Bowuigi> I don't remember Hugs having fundeps, lemme check |
| 2024-12-28 01:40:15 +0100 | <geekosaur> | pretty sure it had both MPTC and fundeps (which are pretty much mandatory to make MPTC usable) |
| 2024-12-28 01:40:45 +0100 | <geekosaur> | (well, you can also do it with associated type families, but Hugs definitely doesn't have those) |
| 2024-12-28 01:40:51 +0100 | <homo> | it is hard for me to understand source code of hugs, I am trying to patch src/parser.y in order to add bangpatterns, but it appears I cannot add them in one short line :( |
| 2024-12-28 01:41:00 +0100 | IamPyu | (~IamPyu@static209-34-105-235.r.rev.accesscomm.ca) |
| 2024-12-28 01:41:00 +0100 | IamPyu | (~IamPyu@static209-34-105-235.r.rev.accesscomm.ca) (Changing host) |
| 2024-12-28 01:41:00 +0100 | IamPyu | (~IamPyu@user/IamPyu) IamPyu |
| 2024-12-28 01:41:25 +0100 | <monochrom> | Oh, bang pattern is a cross-cutting concern, yeah. |
| 2024-12-28 01:41:26 +0100 | <homo> | I want to bootstrap microhs from hugs and it requires bangpatterns, I would rather not remove bangpatterns from microhs's source |
| 2024-12-28 01:41:37 +0100 | <haskellbridge> | <Bowuigi> Oh it has fundeps https://www.haskell.org/hugs/pages/hugsman/exts.html |
| 2024-12-28 01:41:47 +0100 | euandreh | (~Thunderbi@2804:d59:8929:cc00:c70d:53a7:f44e:6c64) euandreh |
| 2024-12-28 01:42:19 +0100 | <homo> | all other extensions that microhs requires are already (partially?) supported by hugs, so there is hope to get better implementation than hugs bootstrappable |
| 2024-12-28 01:42:44 +0100 | <homo> | it's interesting how much of haskell2010 hugs supports |
| 2024-12-28 01:43:07 +0100 | <geekosaur> | not very; 2010 only added like two things to H98 (and removed one) |
| 2024-12-28 01:43:29 +0100 | <homo> | npk patterns, a simulation of logical programming |
| 2024-12-28 01:43:54 +0100 | <geekosaur> | ignoring FFI and hierarchical modules, which were widely supported and (semi-)official extensions |
| 2024-12-28 01:44:05 +0100 | sprotte24 | (~sprotte24@p200300d16f4a7c0031dcae6904c3663c.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2024-12-28 01:44:35 +0100 | IamPyu | (~IamPyu@user/IamPyu) (Client Quit) |
| 2024-12-28 01:44:56 +0100 | <homo> | it's interesting how only haskell's type-system is logic programming, but functional patterns like in curry language are impossible |
| 2024-12-28 01:45:30 +0100 | <homo> | last (xs ++ [x]) = x |
| 2024-12-28 01:45:40 +0100 | Sisyphean | (~Sisyphean@user/Sisyphean) Sisyphean |
| 2024-12-28 01:46:16 +0100 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) |
| 2024-12-28 01:48:09 +0100 | <haskellbridge> | <Bowuigi> Because that's a term level function, not a type level one |
| 2024-12-28 01:48:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 01:48:46 +0100 | <haskellbridge> | <Bowuigi> A similar thing can be done at the type level, tho it doesn't look like that |
| 2024-12-28 01:49:14 +0100 | <homo> | microhs is the only hope to bootstrap ghc, as unfortunately ghc maintainers have no interest to make ghc buildable with smaller haskell implementations :( |
| 2024-12-28 01:51:42 +0100 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 276 seconds) |
| 2024-12-28 01:52:35 +0100 | <haskellbridge> | <Bowuigi> Hmmm would a simple text replacement command deleting every ! work? |
| 2024-12-28 01:52:59 +0100 | <haskellbridge> | <Bowuigi> "tr -d '!'" on Linux/POSIX |
| 2024-12-28 01:53:04 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-28 01:54:35 +0100 | <homo> | speaking of smaller, https://github.com/blynn/compiler is an interesting quest where minimal compiler written in C compiles tiny subset of haskell, so next compiler is written in that tiny subset to implement bigger subset, then another compiler is written in bigger subset... |
| 2024-12-28 01:54:57 +0100 | <geekosaur> | tr'd [] = []; tr'd ('!':xs) = tr'd xs |
| 2024-12-28 01:55:07 +0100 | Sisyphean | (~Sisyphean@user/Sisyphean) (Read error: Connection reset by peer) |
| 2024-12-28 01:55:33 +0100 | <homo> | Bowuigi I don't want to do that because bangpatterns are very important for optimization, they might even prevent hugs from segfaulting |
| 2024-12-28 01:55:38 +0100 | <geekosaur> | uh, no |
| 2024-12-28 01:56:01 +0100 | <c_wraith> | you could always use seq directly. |
| 2024-12-28 01:56:23 +0100 | <homo> | this is why I'm trying to figure out how to add bangpatterns to hugs instead of removing every ! from microhs's code |
| 2024-12-28 01:56:26 +0100 | Sisyphean | (~Sisyphean@user/Sisyphean) Sisyphean |
| 2024-12-28 01:57:06 +0100 | <geekosaur> | tr'd xs = go xs "" where go [] ys = ys; go ('!':xs) ys = go xs ys; go (x:xs) = go xs (ys ++ [x]) |
| 2024-12-28 01:57:21 +0100 | <geekosaur> | faster wouuld be to prepend to ys and reverse it at the end |
| 2024-12-28 01:57:58 +0100 | <homo> | sed s/!//g |
| 2024-12-28 01:59:50 +0100 | <haskellbridge> | <Bowuigi> geekosaur it might be faster to use a Cayley-ish abstraction |
| 2024-12-28 02:03:11 +0100 | <haskellbridge> | <Bowuigi> "tr'd xs = go xs "" where go [] = id; go ('!':xs) = go xs; go (x:xs) = (x:) . go xs" |
| 2024-12-28 02:05:27 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-12-28 02:06:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 02:07:39 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) |
| 2024-12-28 02:08:36 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds) |
| 2024-12-28 02:10:34 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-12-28 02:11:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2024-12-28 02:11:25 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) |
| 2024-12-28 02:12:44 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-12-28 02:13:48 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) |
| 2024-12-28 02:15:46 +0100 | <homo> | btw, #guix channel has bot "sneek" and you can ask it "sneek later tell username your message" and it will do that the moment that user sends message, is there similar bot in this channel? |
| 2024-12-28 02:17:14 +0100 | euandreh | (~Thunderbi@2804:d59:8929:cc00:c70d:53a7:f44e:6c64) (Remote host closed the connection) |
| 2024-12-28 02:17:50 +0100 | euandreh | (~Thunderbi@2804:d59:8929:cc00:c70d:53a7:f44e:6c64) euandreh |
| 2024-12-28 02:18:20 +0100 | <geekosaur> | lambdabot has @tell / @ask |
| 2024-12-28 02:20:17 +0100 | <geekosaur> | also I think libera still operates a memoserv, but sender and recipient must both be registered with nickserv |
| 2024-12-28 02:22:52 +0100 | <homo> | @tell OftenFaded I think negative part about haskell being academic is that its development cycle is not business-friendly, companies want lts releases of compilers, libraries and everything else, they want stable API and ABI that doesn't break on updates, which is not the case with haskell ecosystem as it's in process of constant research and refactoring |
| 2024-12-28 02:22:52 +0100 | <lambdabot> | Consider it noted. |
| 2024-12-28 02:22:57 +0100 | <homo> | thanks |
| 2024-12-28 02:27:20 +0100 | <geekosaur> | the odd thing there is a lot of the changes are driven by … businesses |
| 2024-12-28 02:28:19 +0100 | <homo> | have you never noticed projects using bundled libraries? |
| 2024-12-28 02:28:33 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 02:29:25 +0100 | <homo> | when I create packages for distro, I have to make sure they don't build nor link to bundled libraries and instead link to system-wide libraries |
| 2024-12-28 02:30:17 +0100 | <homo> | some projects (palemoon) are so hostile that they threaten with lawsuit if you don't use bundled libraries |
| 2024-12-28 02:31:56 +0100 | <fp> | So I've heard that first year CS students at Edinburgh University are taught haskell as the first programming language, supposedly because it evens the playing field between students who have never programmed before and those that have. I wonder if people here have thoughts on that |
| 2024-12-28 02:33:13 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-12-28 02:33:20 +0100 | <c_wraith> | I suspect it's more about leveling the playing field between script kiddies and the inexperienced, without calling them out as such... |
| 2024-12-28 02:33:21 +0100 | <geekosaur> | there is a recurrent meme that it's easier to learn Haskell if you don't know other programming languages. the factual evidence for that is mixed, as I understand it; I think I recall someone actually teaching Haskell to children and finding it was no easier for them than common programming languages, for example |
| 2024-12-28 02:34:05 +0100 | <c_wraith> | The fact is, knowing how to organize your thoughts formally is the same skill no matter what programming language is involved. |
| 2024-12-28 02:34:06 +0100 | <geekosaur> | (which doesn't surprise me enormously as you prpbably need a baseline level of math for it to make any sense) |
| 2024-12-28 02:34:14 +0100 | <geekosaur> | and that |
| 2024-12-28 02:34:56 +0100 | <homo> | when I had job with functional programming, unfortunately it was not haskell, it was a clone of haxe created by customer that segfaults on recursion, and I had to adjust my code just because compiler is incompetent |
| 2024-12-28 02:36:22 +0100 | <homo> | I told customer that bug needs to be fixed in compiler instead of me adjust my code, for that reason I lost that job and I am so happy |
| 2024-12-28 02:37:08 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-12-28 02:40:07 +0100 | <homo> | geekosaur before haskell I programmed in lua, C, go and tcl, little bit of perl, python and rust, I confirm that haskell is easy to learn |
| 2024-12-28 02:40:13 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-28 02:40:34 +0100 | <homo> | so easy that I forgot how to program in those languages |
| 2024-12-28 02:42:00 +0100 | <Sisyphean> | homo: can you write all those languages fluently? |
| 2024-12-28 02:42:34 +0100 | <c_wraith> | honestly, forgetting other languages when you're doing solely Haskell is a real thing. |
| 2024-12-28 02:42:46 +0100 | <homo> | Sisyphean after several years of not touching them? highly doubt it |
| 2024-12-28 02:42:54 +0100 | <c_wraith> | I spent like 18 months working *only* in Haskell, and I forgot how line-by-line execution works. |
| 2024-12-28 02:43:13 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 248 seconds) |
| 2024-12-28 02:43:17 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f3024b97f8e6af9334e.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2024-12-28 02:44:00 +0100 | <homo> | haskell creates addiction to declarative programming |
| 2024-12-28 02:45:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 02:45:17 +0100 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) |
| 2024-12-28 02:46:14 +0100 | <homo> | my former customer said that they cloned haxe because they don't want C/C++ programmers to learn new syntax... |
| 2024-12-28 02:46:28 +0100 | <homo> | functional programming language with C syntax doesn't make any sense |
| 2024-12-28 02:48:31 +0100 | <homo> | they are looking for programmers willing to learn new, but they don't want programmers to learn new syntax... |
| 2024-12-28 02:49:38 +0100 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 265 seconds) |
| 2024-12-28 02:50:07 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 02:51:33 +0100 | <Sisyphean> | homo: how many C/C++ programmers even exist now? |
| 2024-12-28 02:51:43 +0100 | <Sisyphean> | aren't the majority of them now in their 60s and 70s? |
| 2024-12-28 02:52:41 +0100 | <homo> | I even had a co-worker who asked me "if in haskell you don't type ';' in your code, how do you separate statements?" :D |
| 2024-12-28 02:53:01 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2024-12-28 02:53:08 +0100 | <Sisyphean> | that's surprising ... hm |
| 2024-12-28 02:53:34 +0100 | <homo> | Sisyphean you'd be surprised to learn how young they were in company I worked for |
| 2024-12-28 02:53:46 +0100 | <geekosaur> | may I note that Gtk is C? |
| 2024-12-28 02:54:01 +0100 | <geekosaur> | although I'll cop to the 60s comment 🙂 |
| 2024-12-28 02:54:41 +0100 | <int-e> | @quote o.v.r.a.l |
| 2024-12-28 02:54:41 +0100 | <lambdabot> | cjs says: I have to explain this shit to people. I mean, I start out right, "Hey, you know how you always have these bugs because what you thought was in the variable is not there?" And I get all of |
| 2024-12-28 02:54:41 +0100 | <lambdabot> | these nods of agreement. "Well, I've found a new language that solves that problem." Audience: "Ooooh! How?" Me: "There's no variables!" And then they all start moving away from me slowly.... |
| 2024-12-28 02:56:28 +0100 | <homo> | gnome is a combination of C, css, javascript and rust... |
| 2024-12-28 02:56:49 +0100 | <homo> | won't be surprising if part of gtk is already in rust |
| 2024-12-28 02:58:28 +0100 | <homo> | I don't understand hype behind rust, is it because haskell is not loudly advertized as safe language? |
| 2024-12-28 02:59:41 +0100 | <geekosaur> | people insist C is the fastest. rust offers those people the speed of C with more safety |
| 2024-12-28 03:00:05 +0100 | <homo> | or rather C+++ with more safety |
| 2024-12-28 03:00:49 +0100 | <geekosaur> | please, no. C+ maybe. no templates and thank whoever's in charge for that |
| 2024-12-28 03:01:02 +0100 | sayurc | (~sayurc@169.150.203.34) sayurc |
| 2024-12-28 03:01:40 +0100 | <homo> | C is very minimal language, both C++ and rust are extremely bloated, too much language features |
| 2024-12-28 03:02:28 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 03:03:43 +0100 | <c_wraith> | C is a lot less "minimal" thank people think. |
| 2024-12-28 03:03:56 +0100 | <homo> | I guess the main difference between haskell and rust is that in rust you can write entire operating system kernel |
| 2024-12-28 03:04:03 +0100 | <geekosaur> | C hasn't been minimal since early pcc |
| 2024-12-28 03:04:17 +0100 | <geekosaur> | if not earlier |
| 2024-12-28 03:04:22 +0100 | <homo> | there used to be HOUSE as attempt to have operating system in haskell, but it used way too much cbits in its source code |
| 2024-12-28 03:06:04 +0100 | <homo> | geekosaur does C offer a lot of features from other programming paradigms making it difficult to choose which features to use and work with other projects? |
| 2024-12-28 03:06:52 +0100 | <geekosaur> | early pcc certainly didn't |
| 2024-12-28 03:07:20 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2024-12-28 03:07:20 +0100 | <geekosaur> | ansi C… has grown a bit, and occasionally of late has turf wars with C++ |
| 2024-12-28 03:07:48 +0100 | talismanick | (~user@2601:644:937c:ed10::ae5) (Read error: Connection reset by peer) |
| 2024-12-28 03:08:04 +0100 | <homo> | still, it is much smaller than both C++ and rust, those 2 languages are feature creeps that say "yes" to every feature request |
| 2024-12-28 03:08:15 +0100 | <geekosaur> | most of that, though, has stuck to C-but… languages (C++ in particular but also Objective-C) |
| 2024-12-28 03:09:18 +0100 | <geekosaur> | (objc seemed to me like it wanted to be smalltalk) |
| 2024-12-28 03:09:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 03:11:15 +0100 | <Sisyphean> | homo: Isn't that similar to logical positivism? It seems like you're suggesting that you only need a small subset of modern languages to accomplish anything meaningful. |
| 2024-12-28 03:11:58 +0100 | <haskellbridge> | <loonycyborg> you can accomplish something meaningful even with direct use of assembly |
| 2024-12-28 03:12:21 +0100 | <haskellbridge> | <loonycyborg> after that it's matter of taste how many abstraction layers over that you'd apply |
| 2024-12-28 03:14:58 +0100 | <geekosaur> | hell, you can bang bits. doesn't mean it's a good idea |
| 2024-12-28 03:15:37 +0100 | <geekosaur> | I gave up on x86 back in the i386 days, never mind modern x86_64 |
| 2024-12-28 03:15:38 +0100 | <homo> | Sisyphean multi-paradigm programming languages are very clumsy, because they absorb features from every other language, they have very detailed hard to read and write syntax, it is harder to make consistent API with them and hard to work with other projects |
| 2024-12-28 03:16:41 +0100 | <homo> | try functional programming in rust and compare it to haskell, which one is cleaner to the eyes? |
| 2024-12-28 03:16:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 03:16:42 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-12-28 03:17:00 +0100 | <homo> | hell, try functional programming in C++ or java or javascript |
| 2024-12-28 03:17:06 +0100 | <geekosaur> | PL/I never quite dies, does it? |
| 2024-12-28 03:17:20 +0100 | <haskellbridge> | <loonycyborg> I like template metaprogramming in C++ |
| 2024-12-28 03:17:56 +0100 | <haskellbridge> | <loonycyborg> in C++ you'd never have trouble getting a compile time variable, unlike haskell with its dependent types that are coming tomorrow :P |
| 2024-12-28 03:18:00 +0100 | <homo> | I like when language's syntax is very clean, haskell's syntax makes sense only to functional programming, prolog's syntax makes sense only to logic programming |
| 2024-12-28 03:18:10 +0100 | <haskellbridge> | <loonycyborg> * variable at runtime, |
| 2024-12-28 03:19:08 +0100 | <haskellbridge> | <loonycyborg> and both have some large amount of emergent paradigms. |
| 2024-12-28 03:19:18 +0100 | <haskellbridge> | <loonycyborg> Caused by features that are arguably missing |
| 2024-12-28 03:19:20 +0100 | <Sisyphean> | homo: why can't I choose the subset of features that solves my problem? |
| 2024-12-28 03:19:35 +0100 | <Sisyphean> | or are you saying I'm incapable of that and most users need to be spoonfed? |
| 2024-12-28 03:19:53 +0100 | <Sisyphean> | or are you implying some kind of inconsistency (which I don't get since the language must compile) |
| 2024-12-28 03:20:18 +0100 | <haskellbridge> | <loonycyborg> Like singletons and libs based on them very much remind me boost.mpl and other c++ template metaprogramming libs |
| 2024-12-28 03:20:55 +0100 | <geekosaur> | PL/I was IBM's attempt at an "everything" programming language, originally unifying FORTRAN and COBOL and later adding SNOBOL and other languages. It was a huge, bloated nightmare |
| 2024-12-28 03:21:11 +0100 | <homo> | Sisyphean that "subset" is the reason I prefer using different languages so that code looks very clean to the eyes, every time I open up .java, .rs, .cpp in the editor I think I am getting eye cancer because of how ugly they look |
| 2024-12-28 03:21:45 +0100 | <haskellbridge> | <loonycyborg> I still think it's mostly matter of taste |
| 2024-12-28 03:21:58 +0100 | <geekosaur> | the problem with subset of features is you may find yourself limited to the libraries that support the same interface, unless the compiler and runtime are very clever about being able to combine the features at the RTS level |
| 2024-12-28 03:22:46 +0100 | <homo> | and consistency is about working with other projects |
| 2024-12-28 03:23:03 +0100 | <geekosaur> | for a minor example, in Haskell's FFI all values must be forced and all constructors removed because C can't deal with them, and conversely constructors must be added to C values |
| 2024-12-28 03:23:49 +0100 | <homo> | I was about to rewrite my message and accidentally hit enter :) |
| 2024-12-28 03:25:00 +0100 | <homo> | I actually want to play with haskell on plan9, because there ffi doesn't make sense, all you have to do is open a file and start reading and writing to that file |
| 2024-12-28 03:25:41 +0100 | <homo> | do you want haskell to render stuff on the screen? open file /dev/draw and write draw commands |
| 2024-12-28 03:26:25 +0100 | <geekosaur> | you're reminding me of porting plan9's window system to sco unix 🙂 |
| 2024-12-28 03:26:57 +0100 | <homo> | plan9's window system cannot be ported to unix because unix doesn't have network-transparent namespaces |
| 2024-12-28 03:28:15 +0100 | <geekosaur> | someone did a hack-up at one point |
| 2024-12-28 03:28:29 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 2024-12-28 03:28:29 +0100 | <geekosaur> | I recall everything under it being done by echoing escape sequences |
| 2024-12-28 03:28:30 +0100 | <homo> | with 9P, namespaces and files as REST API resources there is too much flexibility to do anything without ffi |
| 2024-12-28 03:28:40 +0100 | <geekosaur> | opening windows, drawing graphics, etc. |
| 2024-12-28 03:28:46 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 03:28:58 +0100 | <homo> | do you mean a hack-up used in plan9port? |
| 2024-12-28 03:29:11 +0100 | <homo> | it works only for tools internal to plan9port |
| 2024-12-28 03:30:50 +0100 | <geekosaur> | no, I'm talking about a hacked-up port to *BSD back in the 1990s |
| 2024-12-28 03:31:43 +0100 | <homo> | hurd might be the only exception, as they say hurd's translators are same thing as plan9's file servers, but I don't know anything about hurd besides it's being microkernel, and I don't know where hurd offers network-transparent namespaces |
| 2024-12-28 03:32:09 +0100 | <homo> | s/where/whether/ |
| 2024-12-28 03:32:16 +0100 | Zenen | (~Zenen@node-1w7jr9uk45pdylasbk2itgwn9.ipv6.telus.net) (Quit: Client closed) |
| 2024-12-28 03:32:53 +0100 | Sisyphean | (~Sisyphean@user/Sisyphean) (Read error: Connection reset by peer) |
| 2024-12-28 03:33:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-28 03:34:50 +0100 | Sisyphean | (~Sisyphean@user/Sisyphean) Sisyphean |
| 2024-12-28 03:44:30 +0100 | <Sisyphean> | plan 9 |
| 2024-12-28 03:44:38 +0100 | <Sisyphean> | wasn't that in the 70s? |
| 2024-12-28 03:44:44 +0100 | <Sisyphean> | what does that have to do with today? |
| 2024-12-28 03:44:56 +0100 | <Sisyphean> | or am I crazy? |
| 2024-12-28 03:45:44 +0100 | <homo> | Sisyphean anyway, I didn't mean to offend you, I have personal struggle with multi-paradigm languages because of how unpleasant their syntax looks to the point it's necessary to use auto-completion plugins in the editor and how hard it is to understand someone else's code, instead it's much easier to read when there are separate languages for every paradigm, I recommend to watch "public static void" and "simplicity is complicated" talks by Rob Pike |
| 2024-12-28 03:45:56 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 03:46:04 +0100 | <homo> | unix was born in the 70s, plan9 is not that old |
| 2024-12-28 03:46:24 +0100 | <homo> | plan9 is haskell of operating systems |
| 2024-12-28 03:46:27 +0100 | <Sisyphean> | yeah I stand corrected mid-80s |
| 2024-12-28 03:48:23 +0100 | <Sisyphean> | homo, makes sense. I think that'd be ideal. I still think there's always going to be naturally many languages and we just have to deal with it. |
| 2024-12-28 03:48:33 +0100 | <Sisyphean> | but I could be wrong. |
| 2024-12-28 03:49:30 +0100 | <homo> | many languages are wonderful when they offer thinking from different perspective not available in other languages |
| 2024-12-28 03:50:25 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-12-28 03:53:00 +0100 | <fp> | I'm trying to write a parser with megaparsec and I want to read in input up to a delimiter. The delimiter can be a few different characters, but I'd also like for it to be EOF. However, the char parsing is of type =Parser Char=, but EOF is =Parser ()=. How can I make a single parser that capture both characters and EOF |
| 2024-12-28 03:53:08 +0100 | <homo> | go's abstraction is CSP-style concurrency, you don't need library for that, make's abstraction is dependency management, again you don't need separate library for that, prolog's abstraction is search, once again no library is needed for that |
| 2024-12-28 03:53:46 +0100 | <homo> | it's when such abstractions are separated in different languages they are easy to read and write |
| 2024-12-28 03:55:21 +0100 | <homo> | tcl offers a clean syntax to quickly prototype gui with tk |
| 2024-12-28 04:00:41 +0100 | haver | (~Enviosity@2.219.56.221) (Ping timeout: 265 seconds) |
| 2024-12-28 04:02:03 +0100 | <Sisyphean> | yea I agree, surely CSP-style comm is how the Universe works |
| 2024-12-28 04:02:08 +0100 | l_k | (~student@85.172.76.246) (Ping timeout: 265 seconds) |
| 2024-12-28 04:02:29 +0100 | <homo> | Sisyphean anyway, what plan9 and haskell have in common is that they both are academic, they both are relevant today, the difference is that lawyers destroyed further development of plan9, after everyone got scared away by its license it got proper free software license 3 years ago |
| 2024-12-28 04:02:30 +0100 | <Sisyphean> | diff strokes for diff folks. long live the many-languages-many-paradigms approach |
| 2024-12-28 04:02:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 04:03:05 +0100 | <homo> | more than 30 years of tyrant license and it is finally under mit license |
| 2024-12-28 04:03:26 +0100 | <Sisyphean> | homo: do you think it can catch up? |
| 2024-12-28 04:03:52 +0100 | l_k | (~student@85.172.76.246) |
| 2024-12-28 04:05:37 +0100 | <homo> | Sisyphean yes, and from the beginning it has features that make it more advanced than other operating systems, even on gnu/linux I still use plan9port because I don't know of replacement other than inferno-os |
| 2024-12-28 04:06:39 +0100 | <Sisyphean> | ok good to know I'm not alone in thinking the future was written 40 years ago. I will read more about plan9, I obviously misjudged. |
| 2024-12-28 04:06:41 +0100 | <homo> | 3 ideas from which everything is build - transparent window and sound systems, vpn, containers, cloud, etc. |
| 2024-12-28 04:07:11 +0100 | <Sisyphean> | transparent window? |
| 2024-12-28 04:07:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-12-28 04:07:24 +0100 | <geekosaur> | "there are more things in heaven and earth, Horatio, than are dreamt of in your philosophy" |
| 2024-12-28 04:07:41 +0100 | <homo> | transparent window system, not transparent window |
| 2024-12-28 04:07:45 +0100 | <Sisyphean> | geekosaur, wow |
| 2024-12-28 04:07:50 +0100 | <Sisyphean> | is that Hamlet? |
| 2024-12-28 04:07:54 +0100 | <geekosaur> | yep |
| 2024-12-28 04:09:14 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) emmanuelux |
| 2024-12-28 04:09:18 +0100 | Katarushisu | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) (Quit: Ping timeout (120 seconds)) |
| 2024-12-28 04:09:30 +0100 | housemate | (~housemate@pa49-183-76-50.pa.vic.optusnet.com.au) housemate |
| 2024-12-28 04:09:36 +0100 | Katarushisu | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) Katarushisu |
| 2024-12-28 04:10:58 +0100 | <homo> | transparent in the sense of network transparency |
| 2024-12-28 04:11:42 +0100 | <homo> | it's possible because of namespaces |
| 2024-12-28 04:13:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 04:14:45 +0100 | <Sisyphean> | yeah namespaces. |
| 2024-12-28 04:14:51 +0100 | <Sisyphean> | never heard that before |
| 2024-12-28 04:14:57 +0100 | <Sisyphean> | so like hierarchy? |
| 2024-12-28 04:15:13 +0100 | <Sisyphean> | amazing |
| 2024-12-28 04:15:48 +0100 | <homo> | well, think about them as namespaces in programming languages |
| 2024-12-28 04:16:55 +0100 | <homo> | for example, there is file /dev/audio , it can be provided by kernel, by sound server and even by remote machine, but to your programs it looks like local file |
| 2024-12-28 04:18:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 04:18:25 +0100 | <homo> | if your router runs plan9, you can bind its /net to /net of your laptop and get access to internet without nat |
| 2024-12-28 04:18:45 +0100 | <homo> | that is, you don't need ipv6 to eliminate nat |
| 2024-12-28 04:18:47 +0100 | <Sisyphean> | ok I guess that's a good thing |
| 2024-12-28 04:19:03 +0100 | <Sisyphean> | appreciate you explaining it |
| 2024-12-28 04:19:28 +0100 | <homo> | you can find research papers from cat-v.org, but that site is currently down |
| 2024-12-28 04:20:01 +0100 | housemate | (~housemate@pa49-183-76-50.pa.vic.optusnet.com.au) (Ping timeout: 265 seconds) |
| 2024-12-28 04:20:34 +0100 | <homo> | this is tour of acme, plan9's ide https://www.youtube.com/watch?v=dP1xVpMPn8M |
| 2024-12-28 04:21:10 +0100 | <Sisyphean> | internet is too centralized now |
| 2024-12-28 04:22:26 +0100 | <Sisyphean> | but it's easy to just talk about it |
| 2024-12-28 04:22:31 +0100 | <Sisyphean> | people have been doing that for 50 years lol |
| 2024-12-28 04:22:49 +0100 | <Sisyphean> | net neutrality, etc |
| 2024-12-28 04:24:12 +0100 | <Sisyphean> | talking about it before clearly did shit |
| 2024-12-28 04:24:52 +0100 | <homo> | https://web.archive.org/web/20240922064812/https://doc.cat-v.org/plan_9/4th_edition/papers/ I recommend to read at the very least introduction papers, then https://web.archive.org/web/20240522195315/http://doc.cat-v.org/plan_9/3rd_edition/rio/ https://web.archive.org/web/20240303195542/http://doc.cat-v.org/bell_labs/concurrent_window_system/ https://web.archive.org/web/20240521085627/http://doc.cat-v.org/bell_labs/transparent_wsys/ https://web.archive.org/web/2024 |
| 2024-12-28 04:24:52 +0100 | <homo> | 0718051824/http://doc.cat-v.org/bell_labs/good_bad_ugly/ |
| 2024-12-28 04:25:30 +0100 | <Sisyphean> | ok |
| 2024-12-28 04:25:44 +0100 | <Sisyphean> | I'll read those papers, appreciate it |
| 2024-12-28 04:26:35 +0100 | notzmv | (~umar@user/notzmv) (Ping timeout: 260 seconds) |
| 2024-12-28 04:27:14 +0100 | Sisyphean | (~Sisyphean@user/Sisyphean) (Leaving) |
| 2024-12-28 04:27:59 +0100 | <homo> | symlinks, sockets, ioctl() and many other things you find in linux and bsd are considered harmful, plan9 has replacement for them, on top of that instead of dbus and env variables like EDITOR there is plumber (is this punchline on unix pipes?) |
| 2024-12-28 04:28:48 +0100 | Sisyphean | (~Sisyphean@user/Sisyphean) Sisyphean |
| 2024-12-28 04:29:01 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 04:29:59 +0100 | <homo> | btw, if you like jokes, in plan9 there are manpages for vi(1) and emacs(1) |
| 2024-12-28 04:31:37 +0100 | hueso | (~root@user/hueso) (Ping timeout: 265 seconds) |
| 2024-12-28 04:32:02 +0100 | hueso | (~root@user/hueso) hueso |
| 2024-12-28 04:33:25 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-28 04:34:29 +0100 | <homo> | "I'm not alone in thinking the future was written 40 years ago." it's because software systems research is abandoned, today we have companies milking money out of ads and microtransactions with users, nobody wants to pay for doing further systems research |
| 2024-12-28 04:36:27 +0100 | td_ | (~td@i53870935.versanet.de) (Ping timeout: 265 seconds) |
| 2024-12-28 04:37:19 +0100 | <Sisyphean> | homo: true |
| 2024-12-28 04:37:53 +0100 | <Sisyphean> | so what do you recommend? |
| 2024-12-28 04:37:59 +0100 | td_ | (~td@i5387093F.versanet.de) td_ |
| 2024-12-28 04:37:59 +0100 | <Sisyphean> | what's the answer |
| 2024-12-28 04:38:36 +0100 | <homo> | well, personally I'm having fun being different than everyone else |
| 2024-12-28 04:43:07 +0100 | <homo> | so, recommendation is throw your fears away and have fun thinking from perspectives that contradicts choices of majority, choose to do something that is not popular because it's fun to do |
| 2024-12-28 04:44:41 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 04:45:38 +0100 | <haskellbridge> | <loonycyborg> things become popular only because someone starts to tinker with them. |
| 2024-12-28 04:46:09 +0100 | <homo> | programming as hobby is so much better than programming as profession, a lot of flexibility to do things differently, to choose tools that suit you best |
| 2024-12-28 04:46:17 +0100 | <haskellbridge> | <loonycyborg> majority isn't a hive mind and things change all the time |
| 2024-12-28 04:47:14 +0100 | <haskellbridge> | <loonycyborg> therefore if you're chasing trends then you're always a distant second :P |
| 2024-12-28 04:47:42 +0100 | <Sisyphean> | sounds reasonable |
| 2024-12-28 04:48:05 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 248 seconds) |
| 2024-12-28 04:48:30 +0100 | <homo> | loonycyborg don't most thing become popular because of marketing? |
| 2024-12-28 04:49:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-12-28 04:49:34 +0100 | <homo> | for example, this is why dis is better than jvm https://web.archive.org/web/20240521004107/http://doc.cat-v.org/inferno/4th_edition/dis_VM_design |
| 2024-12-28 04:49:57 +0100 | <homo> | but jvm became popular because of marketing |
| 2024-12-28 04:50:58 +0100 | <haskellbridge> | <loonycyborg> Marketing total trash isn't worthwhile in most cases anyway. |
| 2024-12-28 04:51:06 +0100 | <haskellbridge> | <loonycyborg> that's why it's only one of reasons |
| 2024-12-28 04:51:36 +0100 | <haskellbridge> | <loonycyborg> all in all there's so much stuff happening there that it's hard to find a single reason |
| 2024-12-28 04:51:54 +0100 | <homo> | then why haskell is less popular than rust, java, c#? |
| 2024-12-28 04:52:03 +0100 | housemate | (~housemate@pa49-199-79-186.pa.vic.optusnet.com.au) housemate |
| 2024-12-28 04:52:37 +0100 | <haskellbridge> | <loonycyborg> I dunno, to me it seems pretty conceptually alien to people who started programming with C/python/basic etc |
| 2024-12-28 04:53:26 +0100 | <homo> | and haskell doesn't look to them as cleaner version of python... |
| 2024-12-28 04:54:10 +0100 | <homo> | on java and c# side too much marketing happenned, and rust is not different in safety propaganda |
| 2024-12-28 04:54:15 +0100 | talismanick | (~user@2601:644:937c:ed10::ae5) talismanick |
| 2024-12-28 04:54:19 +0100 | <homo> | but there are no aggressive ads for haskell |
| 2024-12-28 04:54:29 +0100 | <haskellbridge> | <loonycyborg> I'm not sure it's cleaner than python. |
| 2024-12-28 04:55:01 +0100 | Sisyphean | (~Sisyphean@user/Sisyphean) (Quit: Leaving) |
| 2024-12-28 04:55:09 +0100 | <haskellbridge> | <loonycyborg> especially given libs that overload various weird letter salad as operators. |
| 2024-12-28 04:56:38 +0100 | <haskellbridge> | <loonycyborg> but it's not matter of language itself but who uses it. |
| 2024-12-28 04:56:38 +0100 | <homo> | hah, you can tell that you can make haskell look like any language because of operators |
| 2024-12-28 04:56:46 +0100 | housemate | (~housemate@pa49-199-79-186.pa.vic.optusnet.com.au) (Remote host closed the connection) |
| 2024-12-28 04:56:55 +0100 | <haskellbridge> | <loonycyborg> if it empowers some important projects then it would become more popular |
| 2024-12-28 04:57:07 +0100 | <geekosaur> | there's at least one BASIC implementation (abusing operators and do notation) |
| 2024-12-28 04:57:23 +0100 | <homo> | go empowers important projects, but is not popular |
| 2024-12-28 04:57:26 +0100 | <haskellbridge> | <loonycyborg> homo: I don't think so, basic syntax is pretty restrictive |
| 2024-12-28 04:57:45 +0100 | <haskellbridge> | <loonycyborg> but if you use parsec with template haskell probably everything is possible |
| 2024-12-28 04:58:08 +0100 | <geekosaur> | pandoc's actually pretty popular, but hasn't really driven much haskell adoption. then again, nobody cares what language it's written in if they're interacting with a command line program |
| 2024-12-28 04:58:16 +0100 | <haskellbridge> | <loonycyborg> especially the way infix operators are handled |
| 2024-12-28 04:58:42 +0100 | <homo> | also don't forget that most people use windows and macos on desktops even if gnu/linux offers them superior alternatives |
| 2024-12-28 04:59:06 +0100 | <haskellbridge> | <loonycyborg> I mean lack of prefix/postfix except - |
| 2024-12-28 04:59:17 +0100 | <haskellbridge> | <loonycyborg> and that ghc extension seems to require () everywhere |
| 2024-12-28 04:59:46 +0100 | <haskellbridge> | <loonycyborg> probably it would be hard to make more general system though without adding lots of ambiguities |
| 2024-12-28 05:00:31 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 05:01:29 +0100 | <homo> | I don't know which today's trend is the most horrible: electron apps; subscriptions; microsoft recall; microtransactions in games |
| 2024-12-28 05:01:57 +0100 | <geekosaur> | chatgpt. |
| 2024-12-28 05:02:52 +0100 | <monochrom> | Sorry, what is wrong with electron apps again? |
| 2024-12-28 05:05:08 +0100 | <haskellbridge> | <sm> electron bad! |
| 2024-12-28 05:05:19 +0100 | <haskellbridge> | <sm> so negative! |
| 2024-12-28 05:06:16 +0100 | <geekosaur> | bloated, slow, leaky JS code, mostly |
| 2024-12-28 05:06:39 +0100 | <monochrom> | OK, that's just being lame, not horrible. |
| 2024-12-28 05:06:39 +0100 | <geekosaur> | I've had electron apps OOM my machine if left running overnight |
| 2024-12-28 05:06:58 +0100 | <homo> | I tried vscode once, I just removed 1 character in code and it got frozen for more than minute, couldn't type text at all |
| 2024-12-28 05:07:23 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 05:07:31 +0100 | <haskellbridge> | <sm> what kind of machine homo ? |
| 2024-12-28 05:08:49 +0100 | <homo> | it was 64-bit 4GB RAM laptop |
| 2024-12-28 05:09:01 +0100 | <glguy> | It's a useful to not let single events shape your whole reality |
| 2024-12-28 05:09:09 +0100 | <homo> | or was it 8GB RAM, I really forgot as I don't have it 2 years already |
| 2024-12-28 05:09:10 +0100 | <glguy> | useful thing* |
| 2024-12-28 05:09:47 +0100 | <homo> | back then I was doing unity game development and unity was so painfully slow I gave up |
| 2024-12-28 05:09:54 +0100 | <geekosaur> | 4GB i'd believe |
| 2024-12-28 05:09:58 +0100 | <haskellbridge> | <sm> I guess it was overloaded. I have a couple of terrific daily-use electron apps, but more memory to run them in |
| 2024-12-28 05:10:21 +0100 | <geekosaur> | I ripped apart a dead machine to scavenge its 16GB RAM to make a 4GB laptop I had usable |
| 2024-12-28 05:10:23 +0100 | <homo> | overloaded? I didn't even install any plugins, I ran with complete defaults |
| 2024-12-28 05:10:44 +0100 | <geekosaur> | imagine chrome in 4GB, if you will |
| 2024-12-28 05:10:44 +0100 | <haskellbridge> | <loonycyborg> I'm not sure what electron apps do under the hood. Can they share resources? |
| 2024-12-28 05:11:01 +0100 | <haskellbridge> | <loonycyborg> or it's always like running an extra browser per app |
| 2024-12-28 05:11:18 +0100 | <geekosaur> | I think it's the latter |
| 2024-12-28 05:11:52 +0100 | <haskellbridge> | <loonycyborg> ye I guess it's about having 64Gb ram everywhere now |
| 2024-12-28 05:12:06 +0100 | <haskellbridge> | <sm> your computer may have been running some other things as well. Also, the project you had open in VSC might have been a factor. Also, you might have been unlucky and hit a bug ? It sounds abd |
| 2024-12-28 05:12:12 +0100 | <haskellbridge> | <sm> * bad |
| 2024-12-28 05:12:25 +0100 | <haskellbridge> | <sm> but yes 4G isn't much for today's apps |
| 2024-12-28 05:12:44 +0100 | <haskellbridge> | <sm> +big |
| 2024-12-28 05:13:09 +0100 | <geekosaur> | the really extreme case was when I was temporarily limited to an old eee pc laptop. 600MHz Atom, 2GB |
| 2024-12-28 05:13:41 +0100 | <geekosaur> | minuscule screen |
| 2024-12-28 05:14:53 +0100 | <haskellbridge> | <sm> which in the grand scheme of things is an amazingly powerful machine, right?! It's just you've got to have software right sized / efficient enough for the hardware |
| 2024-12-28 05:15:57 +0100 | <haskellbridge> | <sm> I'm remembering my 1K ZX80 |
| 2024-12-28 05:16:31 +0100 | <geekosaur> | I can't really complain much, it had a good full life until its battery finally died (nobody makes batteries for it any more, of course) |
| 2024-12-28 05:17:07 +0100 | <homo> | so, when you need so much RAM, how much multi-tasking does your computer perform? can you keep more apps open today than you could 10 years ago? 20 years ago? |
| 2024-12-28 05:17:20 +0100 | <geekosaur> | although I actually still have it and it may yet ride again: unlike at least some modern machines, it works on AC power even without a battery installed |
| 2024-12-28 05:17:50 +0100 | <haskellbridge> | <sm> homo: depends on the apps, doesn't it |
| 2024-12-28 05:18:21 +0100 | <geekosaur> | and except for that brief-ish period trying to use it as an emergency backup laptop, it spent its later years as a fileserver |
| 2024-12-28 05:18:51 +0100 | <monochrom> | Certainly I can keep two ghci open today but I couldn't back then. :) |
| 2024-12-28 05:19:00 +0100 | haskellbridge | sm has 630 processes running here |
| 2024-12-28 05:19:36 +0100 | <monochrom> | Actually even two ghci open and one ghc compiling. |
| 2024-12-28 05:20:06 +0100 | <geekosaur> | my current machine is big enough that it only starts to breathe heavy when building ghc |
| 2024-12-28 05:20:13 +0100 | <monochrom> | couldn't do that with 4GB 7 years ago. |
| 2024-12-28 05:20:14 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 05:20:39 +0100 | <geekosaur> | and then only because I use -j12 |
| 2024-12-28 05:21:34 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) Feuermagier |
| 2024-12-28 05:21:48 +0100 | sayurc | (~sayurc@169.150.203.34) (Quit: Konversation terminated!) |
| 2024-12-28 05:24:44 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-12-28 05:27:15 +0100 | <homo> | another reason to have alternative haskell compiler: save resourses compiling it |
| 2024-12-28 05:28:55 +0100 | <homo> | what if ghc maintainers are secretly afraid that something can compile ghc faster than ghc compiles itself and that's why they make it impossible to bootstrap |
| 2024-12-28 05:29:57 +0100 | <haskellbridge> | <sm> a lighter haskell compiler would be great! try microhs and hell |
| 2024-12-28 05:30:46 +0100 | <homo> | another advantage of microhs is that it might be ported on more cpu architectures than ghc itself |
| 2024-12-28 05:31:10 +0100 | <homo> | if there is any special work required for porting that is |
| 2024-12-28 05:32:21 +0100 | <homo> | or even something crazyingly impossible for ghc: port microhs to plan9 and enjoy haskell2010 with 50 extensions |
| 2024-12-28 05:32:31 +0100 | <haskellbridge> | <sm> has microhs been compiled with ghc wasm yet I wonder |
| 2024-12-28 05:36:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 05:38:27 +0100 | <homo> | at the very least until ghc's bootstrap problem is solved, the biggest haskell one will get on guix on riscv and arm is microhs |
| 2024-12-28 05:39:59 +0100 | <homo> | to me it is important to always have darcs available |
| 2024-12-28 05:41:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-12-28 05:45:42 +0100 | giost | (~giost@pool-72-74-37-230.bstnma.fios.verizon.net) |
| 2024-12-28 05:46:55 +0100 | rekahsoft | (~rekahsoft@76.69.85.220) (Remote host closed the connection) |
| 2024-12-28 05:47:44 +0100 | fun-safe-math | (~fun-safe-@2601:1c2:1b7f:801f:83ce:3f54:3f3c:7c89) (Quit: No Ping reply in 180 seconds.) |
| 2024-12-28 05:49:00 +0100 | fun-safe-math | (~fun-safe-@2601:1c2:1b7f:801f:ece:4698:cd8b:41e1) fun-safe-math |
| 2024-12-28 05:54:32 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 05:58:43 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-12-28 06:05:31 +0100 | <haskellbridge> | <sm> ah, a darcs user! |
| 2024-12-28 06:08:31 +0100 | <homo> | yeah, so much different from the rest :) |
| 2024-12-28 06:10:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 06:11:12 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2024-12-28 06:15:14 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-28 06:16:52 +0100 | remedan_ | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2024-12-28 06:17:07 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) (Quit: Leaving) |
| 2024-12-28 06:19:24 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2024-12-28 06:20:34 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-12-28 06:27:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 06:30:57 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-12-28 06:31:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-28 06:37:00 +0100 | notzmv | (~umar@user/notzmv) notzmv |
| 2024-12-28 06:38:30 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2024-12-28 06:39:01 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2024-12-28 06:44:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 06:45:29 +0100 | ycp | (~znc@user/dragestil) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2024-12-28 06:45:57 +0100 | ycp | (~znc@user/dragestil) dragestil |
| 2024-12-28 06:50:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-12-28 06:53:06 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 244 seconds) |
| 2024-12-28 06:53:26 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2024-12-28 06:56:26 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2024-12-28 06:58:04 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 265 seconds) |
| 2024-12-28 06:58:04 +0100 | tnt2 | tnt1 |
| 2024-12-28 07:03:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 07:08:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 07:18:19 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-12-28 07:18:22 +0100 | notzmv | (~umar@user/notzmv) (Ping timeout: 265 seconds) |
| 2024-12-28 07:22:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 07:22:43 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-28 07:23:48 +0100 | <fp> | How, with megaparsec, does one represent an optional parser? The problem I'm solving is that I have a decimal literal, which can be like =1234= or =#d1234=, so the =#d= is optional and I don't care about the value. =optional= exists, but it creates a =Maybe= which I can't just throw away its value |
| 2024-12-28 07:25:30 +0100 | <haskellbridge> | <maerwald> maybeParser *> decimalParser |
| 2024-12-28 07:26:24 +0100 | <haskellbridge> | <maerwald> :t (*>) |
| 2024-12-28 07:27:01 +0100 | <haskellbridge> | <maerwald> (*>) :: f a -> f b -> f b |
| 2024-12-28 07:27:04 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 07:27:14 +0100 | <haskellbridge> | <maerwald> you run both effects, but discard the left value |
| 2024-12-28 07:27:22 +0100 | <c_wraith> | In particular, both (*>) and (<*) do just "throw away" things in exactly the way you'd want. (You use *> more standalone, <* more in applicative chains) |
| 2024-12-28 07:28:02 +0100 | <haskellbridge> | <maerwald> the effect of a parser is that it consumes input (or not) |
| 2024-12-28 07:29:53 +0100 | <fp> | So I don't want for decimalParser to be Maybe, like the grammar I want is like <decimal> ::= "#d"? [0-9]+, so I just want something like the ? |
| 2024-12-28 07:30:35 +0100 | <fp> | or is that what you're saying? |
| 2024-12-28 07:31:53 +0100 | <c_wraith> | optional (chunk "#d") <* some (satisfy isDigit) |
| 2024-12-28 07:32:07 +0100 | <c_wraith> | err. *> |
| 2024-12-28 07:35:17 +0100 | <haskellbridge> | <maerwald> The effect of a parser is consuming input or failing... a maybe parser never fails (but may backtrack, depending on how you defined it). You only care about the effect here, but not the value (Maybe). That's what (*>) does. |
| 2024-12-28 07:35:46 +0100 | <fp> | That still gives me a type error on the left side that it's Maybe and not Parser |
| 2024-12-28 07:36:12 +0100 | <fp> | looking at the type signature of (*>), I think both sides need to be of the same monad? |
| 2024-12-28 07:36:26 +0100 | <haskellbridge> | <maerwald> yes |
| 2024-12-28 07:36:27 +0100 | <c_wraith> | optional returns a parser. |
| 2024-12-28 07:36:36 +0100 | <c_wraith> | What are you doing to make it not? |
| 2024-12-28 07:36:41 +0100 | <haskellbridge> | <maerwald> show the real code |
| 2024-12-28 07:36:57 +0100 | <fp> | number <- optional string "#d" <* someTill decimalDigit (lookAhead delimiter) |
| 2024-12-28 07:37:10 +0100 | <c_wraith> | yeah, flip that to *> |
| 2024-12-28 07:37:19 +0100 | <fp> | same that way |
| 2024-12-28 07:37:23 +0100 | <haskellbridge> | <maerwald> missing parenthesis too I think |
| 2024-12-28 07:37:31 +0100 | <c_wraith> | oh, right. |
| 2024-12-28 07:37:38 +0100 | <c_wraith> | option (string "#d") |
| 2024-12-28 07:37:54 +0100 | <c_wraith> | I should stop trying to type correctly tonight. option*al*. |
| 2024-12-28 07:38:21 +0100 | <haskellbridge> | <maerwald> without parens, you have (optional string) "#d" |
| 2024-12-28 07:39:16 +0100 | <fp> | right yeah, that was it |
| 2024-12-28 07:39:19 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 07:39:30 +0100 | <fp> | now to figure out why that didn't solve my problem |
| 2024-12-28 07:39:31 +0100 | <haskellbridge> | <maerwald> that would then use the function applicative instance I believe |
| 2024-12-28 07:39:36 +0100 | <fp> | (unrelated to my question) |
| 2024-12-28 07:40:13 +0100 | <c_wraith> | If you're using megaparsec, you need to know when/why to use try |
| 2024-12-28 07:40:44 +0100 | <c_wraith> | not using it when you need to will make parses fail for no apparent reason. |
| 2024-12-28 07:40:46 +0100 | <haskellbridge> | <maerwald> I prefer attoparsec |
| 2024-12-28 07:41:21 +0100 | <haskellbridge> | <maerwald> it always backtracks on failure |
| 2024-12-28 07:42:07 +0100 | <fp> | I know it's not related to backtracking because the misbehaviour is at the beginning of the input |
| 2024-12-28 07:42:07 +0100 | <c_wraith> | well, sort of. It never discards input it might still choose to use. I don't believe it will actually backtrack on a successful parse if a future parse fails. |
| 2024-12-28 07:43:44 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-12-28 07:45:21 +0100 | haver | (~Enviosity@2.219.56.221) |
| 2024-12-28 07:48:53 +0100 | <c_wraith> | yeah, attoparsec doesn't backtrack either. parseOnly ((string "a" <|> string "aa") <* string "b") "aab" ----> Left "string" |
| 2024-12-28 07:50:05 +0100 | <c_wraith> | being able to parse that string with that parser is backtracking. Not needing to use try to avoid breaking is just not being broken. |
| 2024-12-28 07:51:27 +0100 | <haskellbridge> | <maerwald> it doesn't backtrack on failure of a single parser |
| 2024-12-28 07:51:40 +0100 | <haskellbridge> | <maerwald> *does |
| 2024-12-28 07:53:00 +0100 | <haskellbridge> | <maerwald> what you want is non-determinism, that's not what it does |
| 2024-12-28 07:54:41 +0100 | <c_wraith> | I want basic refactoring to work, which is not what it does. |
| 2024-12-28 07:56:32 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 07:57:11 +0100 | <haskellbridge> | <maerwald> no idea what that means |
| 2024-12-28 07:57:46 +0100 | <c_wraith> | If I have to know that ((a <*> b) <|> (a <*> c)) is the same as (a <*> (b <|> c)), but ((a <*> c) <|> (b <*> c)) is not the same as ((a <|> b) <*> c), it's gone off the rails. |
| 2024-12-28 07:58:32 +0100 | <c_wraith> | just give me simple distributive laws which don't have tons of cases. |
| 2024-12-28 08:00:19 +0100 | JamesMowery439 | (~JamesMowe@ip68-228-212-232.ph.ph.cox.net) (Quit: Goodbye) |
| 2024-12-28 08:00:35 +0100 | JamesMowery439 | (~JamesMowe@ip68-228-212-232.ph.ph.cox.net) JamesMowery |
| 2024-12-28 08:01:11 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-28 08:01:18 +0100 | <haskellbridge> | <maerwald> well, distributive laws don't hold for Alternative even in core libs |
| 2024-12-28 08:01:23 +0100 | housemate | (~housemate@pa49-199-79-186.pa.vic.optusnet.com.au) housemate |
| 2024-12-28 08:02:12 +0100 | <c_wraith> | But they do hold for the parser combinator library in base! |
| 2024-12-28 08:06:55 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2024-12-28 08:07:32 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2024-12-28 08:08:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 08:14:02 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2024-12-28 08:18:42 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-12-28 08:21:48 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 264 seconds) |
| 2024-12-28 08:24:39 +0100 | housemate | (~housemate@pa49-199-79-186.pa.vic.optusnet.com.au) (Ping timeout: 252 seconds) |
| 2024-12-28 08:25:37 +0100 | ephilalethes | (~noumenon@202.186.200.33) (Read error: Connection reset by peer) |
| 2024-12-28 08:27:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 08:32:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-28 08:43:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 08:44:01 +0100 | Milan | (~Milan@88.212.61.169) |
| 2024-12-28 08:44:19 +0100 | Milan | (~Milan@88.212.61.169) (Remote host closed the connection) |
| 2024-12-28 08:45:39 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2024-12-28 08:46:15 +0100 | Digit | (~user@user/digit) (Ping timeout: 244 seconds) |
| 2024-12-28 08:47:26 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) |
| 2024-12-28 08:48:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-12-28 08:49:10 +0100 | Flow | (~none@gentoo/developer/flow) (Ping timeout: 252 seconds) |
| 2024-12-28 08:50:12 +0100 | Digitteknohippie | (~user@user/digit) (Ping timeout: 265 seconds) |
| 2024-12-28 08:51:31 +0100 | Digit | (~user@user/digit) Digit |
| 2024-12-28 08:52:18 +0100 | Flow | (~none@gentoo/developer/flow) flow |
| 2024-12-28 08:59:51 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-12-28 09:00:04 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-12-28 09:00:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 09:00:43 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-12-28 09:04:20 +0100 | giost | (~giost@pool-72-74-37-230.bstnma.fios.verizon.net) (Leaving) |
| 2024-12-28 09:05:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-12-28 09:08:46 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-12-28 09:09:01 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) |
| 2024-12-28 09:09:27 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-12-28 09:14:46 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) |
| 2024-12-28 09:15:11 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-12-28 09:16:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 09:20:59 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-12-28 09:22:17 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) |
| 2024-12-28 09:23:09 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2024-12-28 09:23:33 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 265 seconds) |
| 2024-12-28 09:23:35 +0100 | tnt2 | tnt1 |
| 2024-12-28 09:27:24 +0100 | notzmv | (~umar@user/notzmv) notzmv |
| 2024-12-28 09:29:15 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-12-28 09:32:24 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 09:34:34 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-12-28 09:36:52 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) |
| 2024-12-28 09:39:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 09:43:59 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 272 seconds) |
| 2024-12-28 09:44:09 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) (Ping timeout: 252 seconds) |
| 2024-12-28 09:44:25 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-12-28 09:50:47 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) |
| 2024-12-28 09:51:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 09:56:37 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-12-28 09:56:45 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-12-28 10:08:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 10:14:18 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 10:16:55 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) |
| 2024-12-28 10:17:37 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2024-12-28 10:20:22 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2024-12-28 10:21:03 +0100 | Square | (~Square@user/square) Square |
| 2024-12-28 10:27:23 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 10:31:20 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) (Ping timeout: 264 seconds) |
| 2024-12-28 10:32:11 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 10:32:30 +0100 | manwithluck | (~manwithlu@194.177.28.164) manwithluck |
| 2024-12-28 10:35:05 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-12-28 10:42:56 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 10:45:13 +0100 | sawilagar | (~sawilagar@user/sawilagar) sawilagar |
| 2024-12-28 10:47:33 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-12-28 10:49:35 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2024-12-28 11:00:23 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 11:05:03 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 11:07:04 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2024-12-28 11:10:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 11:11:59 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2024-12-28 11:17:43 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-28 11:17:49 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2024-12-28 11:19:58 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f42bc4ebb891d7561a4.dip0.t-ipconnect.de) acidjnk |
| 2024-12-28 11:20:02 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-12-28 11:22:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 11:26:56 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-12-28 11:28:55 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) |
| 2024-12-28 11:30:41 +0100 | CiaoSen | (~Jura@2a05:5800:2ca:8300:ca4b:d6ff:fec1:99da) CiaoSen |
| 2024-12-28 11:40:26 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 11:45:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-12-28 11:47:03 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-12-28 11:51:06 +0100 | alp | (~alp@2001:861:8ca0:4940:8d4c:5a22:6b11:16da) (Remote host closed the connection) |
| 2024-12-28 11:55:17 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2024-12-28 11:58:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 12:02:40 +0100 | <SrPx> | tips and tricks to make cabal install not take 20s when developing / debugging? i just want to edit my haskell project and run it without having to wait 20s every damn time. that is completely killing my productivity. i wonder if runghc can be used for that perhaps? |
| 2024-12-28 12:03:32 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 12:03:43 +0100 | <int-e> | Hmm maybe `cabal repl` and :r gets you close enough? |
| 2024-12-28 12:04:40 +0100 | <Leary> | SrPx: ghcid/ghciwatch |