| 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 |