Newest at the top
| 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. |
| 2025-03-17 03:34:53 +0100 | MyNetAz | (~MyNetAz@user/MyNetAz) MyNetAz |
| 2025-03-17 03:34:42 +0100 | <geekosaur> | the popularity of python for scientific programming shoots that one down anyway |
| 2025-03-17 03:33:16 +0100 | <monochrom> | And with that, also out with "layout means script kiddies". |
| 2025-03-17 03:33:00 +0100 | <monochrom> | Today no editor has an issue. Come on this is 2025 already. |
| 2025-03-17 03:32:43 +0100 | <monochrom> | I am talking about 20 years ago. |
| 2025-03-17 03:32:26 +0100 | <haskellbridge> | <Liamzee> So, there's actually a pragmatic reason to use braces in Haskell, simply to make your code compile less than 1% faster. Got it. |
| 2025-03-17 03:32:24 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 265 seconds) |
| 2025-03-17 03:31:39 +0100 | <monochrom> | I tried that, but that's only when my editor haskell mode was primitive and couldn't do good indentation without braces. |
| 2025-03-17 03:29:35 +0100 | <haskellbridge> | Now if you wanted to build your own Haskell compiler that only uses braces you could bypass the layout pass (and dreaded parse-error case) |
| 2025-03-17 03:29:34 +0100 | <haskellbridge> | <dmjio> Well braces automatically get inserted after the layout pass, so you might be saving the layout pass some work. |
| 2025-03-17 03:27:53 +0100 | MyNetAz | (~MyNetAz@user/MyNetAz) (Remote host closed the connection) |
| 2025-03-17 03:27:53 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-17 03:25:38 +0100 | ljdarj1 | ljdarj |
| 2025-03-17 03:25:38 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2025-03-17 03:24:25 +0100 | <haskellbridge> | <Liamzee> there's a point to it, since I like treating Haskell as a scripting language and non-idiomatic Haskell, if you're writing in braces you're implying you're being serious and actually caring about engineering quality. But then again, braces aren't that idiomatic either. |