6 ms·
Maybe after trying it out for five minutes you make up your mind - but mine was decidedly for it
by ludamad 7y ago
Maybe after trying it out for five minutes you make up your mind - but mine was decidedly for it
- thelazydogsback 7y agoYeah, I'd much rather look at Python or F# than Java code all day.
- cannam 7y agoF# uses significant whitespace? I didn't know that. What does it use it for? SML and (I think) Ocaml don't, and I had assumed F# was like Ocaml, since its syntax is largely the same. In the tiny bit of F# I tried writing once I don't remember having had to pay any attention to whitespace. Significant whitespace is one of the things I didn't enjoy about Haskell and Idris. Life's too short to indent code by hand.
- _bxg1 7y agoI didn't think Haskell had significant whitespace; it doesn't have blocks really, and nested expressions can be wrapped in parentheses, right?
- jeremyjh 7y agoWhitespace is significant in Haskell. In do notation and other forms, you have blocks. You can actually use braces and semi-colons instead but I've never seen that except in some very short one-liners. https://en.wikibooks.org/wiki/Haskell/Indentation https://en.wikibooks.org/wiki/Haskell/Indentation
- desert_boi 7y agoBlocks are handled via indentation. let function1() = for i in 1 .. 10 do printf "%d " i printfn "" function1() borrowed from https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/loops-for-in-expression https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...
- viklove 7y agoJava isn't a scripting language, python is. Why not compare apples to apples? At the very least compare Python to JS...
- throwaway_pdp09 7y agoAlways liked the idea of whitespace-only indenting but always suspicious of it. Problems I've found are that automatically generated code can't just be dumped in with { and } around it. A colleague spent a few hours tracking down a python bug caused by a bad merge that messed up the indent without it outright causing the code to crash, just produce wrong output. That's IMO too expensive a bug type to permit just to save a few keystrokes. But YMMV as they say.
- _bxg1 7y agoAnd then there's tabs vs spaces (you can't tell just by looking whether or not the syntax is correct), and the fact that a block expression can't be nested inside anything else, etc.
- zenhack 7y ago+1 for the bit about machine generated code. I think if you're going to have significant whitespace, Haskell does the right thing here: the indentation rules are specified in terms of automatic insertion of braces and semicolons. Almost nobody is them in by hand, but they make codegen easier. Re: the bad merge, that can happen the other way to: this was the cause of Apple's infamous goto fail bug. I think block structured languages should do what go and some others do: braces on conditionals and loops are mandatory, parens are optional.
- mixmastamyk 7y agoIt is a great deal, millions of keystrokes and code reading impediments avoided over decades vs. one exception a colleague of someone on a discussion board had once. That’s a 1000x advantage in my book. Not mention exceptions are often avoided with a professional editor with whitespace highlighting and indentation guides.
- viklove 7y ago> one exception a colleague of someone on a discussion board had once You're not even trying to have a reasonable discussion about this, are you. At least this guy has a datapoint. You just have a hunch that you can write code faster if it's formatted slightly differently. I don't think it's true -- I don't think typing semicolons and curly braces slows down my coding enough to warrant omitting them. Most of my time coding is spent thinking and reading, probably less than 15% of my time is spent typing. So if I only type semicolons and commas 5% of that time, that means I'm saving 0.75% of my time by not typing them, which is about 14 hours a year if I work 40 hour weeks. I've definitely debugged a yaml error or two due solely to formatting in the past year, which probably cost me at least 4 hours of productivity. If my entire codebase was formatted solely by indents and returns, I imagine that number would balloon significantly, which is why I opt to use semicolons and other formatting characters. Also, they're not "reading impediments," at least not universally. Being able to use my code-editor to jump to the end of a code block (by matching a { or }) has been immensely useful in my experience.