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