Newest at the top
| 2025-03-17 04:06:19 +0100 | Guest16 | (~Guest16@168.92.227.70) (Client Quit) |
| 2025-03-17 04:05:34 +0100 | <davean> | monochrom: I feel Fox News has gotten a lot done. |
| 2025-03-17 04:05:16 +0100 | Guest16 | (~Guest16@168.92.227.70) |
| 2025-03-17 04:04:44 +0100 | bilegeek | (~bilegeek@2600:1008:b041:b61:4489:3f6f:340a:78f6) (Ping timeout: 260 seconds) |
| 2025-03-17 04:03:24 +0100 | bilegeek__ | (~bilegeek@2600:1008:b042:764a:da27:cd1a:86b4:69a4) bilegeek |
| 2025-03-17 04:03:11 +0100 | <monochrom> | Economically, I would not hire people who spend time exclaiming things instead of getting things done. Like, are you hiring them for programming or are you hiring them for Fox News? |
| 2025-03-17 04:02:36 +0100 | <haskellbridge> | <Liamzee> anyways, conclusion: braces and semicolons can be used to mark code within a Haskell codebase, what braced code (use parens for pure functions) means is up to you |
| 2025-03-17 04:01:45 +0100 | <davean> | I have very mixed feelings on significant whitespace. It sure isn't hard to move between though |
| 2025-03-17 04:01:19 +0100 | <int-e> | davean: wdym?! everybody loves significant whitespace!!!1eleven |
| 2025-03-17 04:00:56 +0100 | <haskellbridge> | <Liamzee> yes, they did as well |
| 2025-03-17 04:00:52 +0100 | <davean> | I didn't say I liked significant whitespace |
| 2025-03-17 04:00:49 +0100 | <geekosaur> | do they say the same about Python? about make? if not, I call BS |
| 2025-03-17 03:59:52 +0100 | <haskellbridge> | <Liamzee> and yeah, there are non-haskellers who regularly exclaim their reason for hating Haskell is significant whitespace |
| 2025-03-17 03:58:43 +0100 | <haskellbridge> | <Liamzee> 1, 5 if there's a CLI (I think there already is one) that does so automatically |
| 2025-03-17 03:58:41 +0100 | <davean> | I don't think it took me that long |
| 2025-03-17 03:58:25 +0100 | <davean> | If it takes over 600 seconds to get comfortable with one from the other I'd be shocked. |
| 2025-03-17 03:58:08 +0100 | <davean> | Liamzee: How many seconds can you honestly expect it to take for people to convert between braces and indentation style? |
| 2025-03-17 03:57:45 +0100 | <geekosaur> | (as I've mentioned before, I've done that oen as well: Prolog prototype, C production) |
| 2025-03-17 03:57:29 +0100 | <haskellbridge> | <Liamzee> also, you're more likely to have juniors and people you trained be more used to braces, so it makes things easier for them to adjust to while simultaneously letting everyone know who wrote it |
| 2025-03-17 03:57:25 +0100 | <geekosaur> | unless you count the different-languages thing |
| 2025-03-17 03:56:42 +0100 | <davean> | lol I find the idea of making prototype code visually distinct amusing |
| 2025-03-17 03:55:32 +0100 | <int-e> | but the premise that layout has a noticable cost compared to all the other things that the compiler is doing is quite laughable |
| 2025-03-17 03:55:13 +0100 | <EvanR> | why is your bait so bad |
| 2025-03-17 03:54:43 +0100 | <int-e> | you can't switch back to layout mode inside explicit braces |
| 2025-03-17 03:54:33 +0100 | <haskellbridge> | <Liamzee> well, thanks for the vote of approval, even if the procedure is different: prototype in braces, be serious in traditional layout |
| 2025-03-17 03:51:28 +0100 | <EvanR> | so I don't know about the performance narrative there |
| 2025-03-17 03:51:27 +0100 | <int-e> | { IRC does have that effect `on` people; } |
| 2025-03-17 03:51:12 +0100 | <EvanR> | the parsing stage that inserters semicolons and braces still has to run even if you put them |
| 2025-03-17 03:51:03 +0100 | <monochrom> | I am happy to read {;} code if it also uses layout (doesn't have to strictly follow Haskell layout rules) to help me. Like, I have been reading C like that all my life already. |
| 2025-03-17 03:50:14 +0100 | <EvanR> | it has the advantage of naturally triggering the stop reading reflex without prior agreement |
| 2025-03-17 03:49:21 +0100 | <EvanR> | haskell code fully braced and semicoloned out could indicate you didn't intend for anyone to actually read your code, in which case they could stop reading if they knew this convention, saving time, or if they just hate it |
| 2025-03-17 03:48:50 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2025-03-17 03:48:31 +0100 | <monochrom> | I don't think you will have any luck enforcing a black-and-white divide between prototyping and production by any means except... The one single success story I ever heard was with entirely two different languages, matlab for prototyping and C++ for production. |
| 2025-03-17 03:44:13 +0100 | <monochrom> | Although, I have only done the opposite: A Haskell program that outputs Java code. :) |
| 2025-03-17 03:43:46 +0100 | <monochrom> | Yeah mechanical output of Haskell code is vastly simpler with {;}. |
| 2025-03-17 03:42:14 +0100 | <int-e> | braces are also nice for lazy code generators... and I seem to recall an account that they have an accessibility benefit in connection with screen readers (which IIUC basically skip whitespace) |
| 2025-03-17 03:40:36 +0100 | <haskellbridge> | <Liamzee> No, I'm trying to build a prototype of an Upwork clone (major feature: having the lowest fees attached) in Haskell. One of the plans is to have a team that does prototyping as well as a team that does engineering. This would distinguish whether the code is intended to be kept or needs to be eventually rewritten. |
| 2025-03-17 03:40:35 +0100 | Guest23 | (~Guest23@2601:45:500:5c10:39d7:6224:4126:8f39) |
| 2025-03-17 03:40:22 +0100 | <int-e> | (it seems that monochrom knows a lot about overthinking) |
| 2025-03-17 03:40:20 +0100 | <haskellbridge> | <dmjio> I think the braces were just to make the syntax context free, to make happy happy |
| 2025-03-17 03:39:52 +0100 | <monochrom> | "blue shirt means blue collar right? but is software engineering blue collar? or is category theory blue collar? or is SPJ a burgeous middle class who pretends to befriend blue collars?" |
| 2025-03-17 03:39:14 +0100 | Square | (~Square@user/square) (Ping timeout: 260 seconds) |
| 2025-03-17 03:38:49 +0100 | <monochrom> | "SPJ wears a blue shirt in his picture. There must be either a category theory reason or a software engineering reason!" |
| 2025-03-17 03:38:31 +0100 | notdabs | (~Owner@2600:1700:69cf:9000:8c4a:1bad:bb61:8f8d) (Read error: Connection reset by peer) |
| 2025-03-17 03:37:26 +0100 | <monochrom> | You're overthinking it. I quit. |
| 2025-03-17 03:37:17 +0100 | <geekosaur> | although even SPJ doesn't use braces religiously |
| 2025-03-17 03:37:05 +0100 | <geekosaur> | imo they make code harder to read (sorry SPJ) |
| 2025-03-17 03:36:50 +0100 | <geekosaur> | or not so pragmatic |
| 2025-03-17 03:36:15 +0100 | <haskellbridge> | <Liamzee> I mean, you could use braces to indicate prototyping, but that should slow down prototyping, no? But you could make an alternative argument that significant whitespace is idiomatic in Haskell, and stubbornly insisting on braces means you're doing improper Haskell for pragmatic reasons. |
| 2025-03-17 03:35:23 +0100 | <haskellbridge> | <Liamzee> No, but braces are fully supported by GHC and the Haskell report. Optional braces can be used as a means of expressing... something. |