[scarfacedeb]

Arrogant is the most accurate word to describe Elm and its leadership. I tried to use Elm in production between 0.14 and 0.18 versions and it was fun and mind expanding experience. I'm truly grateful that I've used it because it introduced a lot of functional stuff to me. But I no longer use it myself or recommend it for any serious work.

Breaking changes were negligible in the beginning. But I got fed up with rewriting the app after the 3rd Elm upgrade. I think it's irresponsible to advertise the language to be used in production and break it every fucking year. Speeches about finding the perfect solution are great for academical discussions and toy languages, but you can't just remove the stuff that your community uses without offering any alternative. It all stems from the arrogance and cult-like behavior of the core team. I'm sure that they're wonderful and very smart people who do their best to create the best version of the language that they can. But their management style is too dictatorial and they don't respect their community.

For me, the split started with elm formatter discussion on github. I disagreed with some of decisions that the core devs made and I wanted to see what other developers have been saying about it. On of the issues was the preference for 4-space indentations instead of 2-space. I understand that it's important to have a single source of formatting for the language. But at that time there was no consensus on what amount of spaces to use. Basically, the community divided almost 50/50 between the two. Moreover, a lot of core libraries and example code still used 2-space indentation. (that's why I preferred it). Due to lack of consensus, there was a suggestion to add a flag to formatter to set the indentation. It required to change some parts of code to pass the flag to the formatting module. At that moment, one of the core devs stepped up and closed the discussion because he didn't approve of this decision and he just said that 2-space people should adapt to the new 4-space default (that wasn't supported by any majority). It was the first time when I felt that the Elm management is too strict and I don't want to have anything to do with people with such attitude.

[cthor]

Tab width arguments are amusing, because it's always between 2 and 4.

There’s actually a number between 2 and 4. For some reason it's never considered.

I've got a summary of all the indentation arguments here: https://cthor.me/Indentation

[davidcuddeback]

I had a CS professor in college who required assignments to be submitted with 3-space indentation.

[trevor-e]

I can't tell if this is satire or not. Just because a language is open source does not mean it's a perfect democracy.

[marcus_holmes]

isn't this the exact problem that tabs solve?

[dkersten]

Yep! If people used tabs, then everyone can display it how they like and these stupid discussions wouldn’t be necessary. Alas, for some reason the world has rallied behind spaces. Sigh.

[jcranmer]

It doesn't really solve the problem. How do you format this code with tabs:

  <TAB><TAB>function name(arg1, arg2,
  <TABs or spaces?????>   arg3 <-- align with arg1)

The other issue is with maximum line length. If you have a maximum line length of 80, do tabs count as 2 spaces, 4 spaces, or 8 spaces towards meeting that line length?

Using spaces ensures that it at least looks consistent, independent of your tabstop settings.

[dkersten]

Indent with tabs, align with spaces. Alignment never follows any "N number of spaces" style guide, since by definition its to align with something else.

So in this case:

  <TAB><TAB>function name(arg1, arg2,
  <TAB><TAB>              arg3

since we were talking about indention, not alignment, I don't see how anything changes. If I want my indent to be 3 spaces and you want 8, we can set our tab width and arg3 will still be aligned correctly for both of us.

Or you live with misaligned arguments (its a bit of a smell imho to have so many arguments that you need to split them over many lines, although it for sure does happen) and just use tabs for both.

My main point is that with tab, each individual has some control over their preferences, even if not perfect for alignment, while with spaces everyone has to live with the standard and nobody has control over their preference. That is, tabs is "mostly people get what they want", spaces is "nobody gets what they want unless they happen to want the style guide imposed on them". The former seems a lot better to me!

[stickfigure]

You learn to live without precisely aligned arguments!

Really this is a peculiar kind of OCD. You don't need to have arg3 precisely lined up with arg1. Or better yet, indent all the arguments in a nice column - if there's so many that they can't fit horizontally, render them vertically. Most IDEs default to two indentations for continuation.

[secondaryditto]

I've had some discussions with folks on projects who are very... focused on linting and formatting rules. They've reformatted my code in the past, and have insisted on blocking code that doesn't pass all their listing rules.

Them: "We have to use these tools to avoid disagreements about spacing and formatting choices".

Me: "But... I wasn't having any in the first place. It's only the 3 of you that were having these disagreements. And now you're spending ridiculous time planning reformat of entire codebase, instead of actually... moving the project forward.

Please don't bitch about me using $x = new Temp(); in a test file. I'm the only person on the project even making test files, and you're blocking my TEST file because you don't like variable name style..."

They got in to a quandary when trying to inline some JS in to a PHP view file. The PHP standard is 4 spaces, and the person doing some of the JS had defined 2 spaces for JS ("so we can all agree on it") and ... all hell broke loose trying to determine what the style/formatting should be for JS-inside-PHP files. 4 spaces? 2 spaces?

[ggregoire]

> It doesn't really solve the problem. How do you format this code with tabs:

  <TAB><TAB>function name(arg1, arg2,
  <TABs or spaces?????>   arg3 <-- align with arg1)

Just wondering… do you realign the parameters every time you rename a function?

[mikewhy]

    <TAB><TAB>function name(
    <TAB><TAB><TAB>arg1,
    <TAB><TAB><TAB>arg2,
    <TAB><TAB><TAB>arg3,
    <TAB><TAB>)

That means this never comes up, and you don't need to change adjacent lines because you've renamed a function.

[jlokier]

That wastes a lot of vertical space if you have a lot of function calls. If you're one of those who prefer that, it's ok. I much prefer:

    function name(arg1, arg2, arg3,
                  arg4, arg5, arg6);

[samvher]

Not the person you're responding to but I do, or actually spacemacs does. The sequence would be $ -> J -> i -> ENTER -> ESC and I guess it's muscle memory.

I agree that this kind of indentation might not make sense on a collaborative project because different people have different standards, but if I'm the only one working on a piece of code I really think precise alignment makes the code a lot more readable.

[benibela]

If the editor would support elastic tabstops you could do:

     <TAB><TAB>function name(<TAB>arg1, arg2,
     <TAB><TAB><TAB>arg3)

[jcranmer]

I don't actually personally do this kind of alignment, but it was the easiest example for me to come up with to illustrate the problem of needing to align text on different lines.

[1-more]

In elm you'd do one of two things: keep all the arguments on one line, or put each on its own line. At least, according to the formatter's opinion (which is honestly so nice to use when it just snaps everything into place every time you hit cmd-s). Of course, this convention is violated all the time when listing all the public exports of a package (with good reason IMHO; it lets your group similar things onto lines together) so it's not much of a convention: https://github.com/rundis/elm-bootstrap/commit/e412efe628854...

[marcus_holmes]

Go does this with tabs by either having each arg on its own line, or all on one line. Which totally makes sense.

[mrgriffin]

I wouldn't do it, but this works perfectly fine. The rule is "use tabs to indent blocks of code, use spaces to align within those blocks".

  <TAB><TAB>function name(arg1, arg2,
  <TAB><TAB>              arg3)

[samatman]

My main objection to using tabs has always been that the Tab key is heavily overloaded: it navigates (one Tab press to move the cursor to the correct indentation point), selects (tab completion), and it puts a variable-width character into my monospace-defined text file.

I'd rather drop the insertion part and have my editor handle adding an appropriate number of spaces.

Let me add this: there's actually nothing stopping you from displaying a four-space indented file as a two-space indented file. Just parse, replace indentation-dictated groups of four spaces with two spaces, you're done.

I don't know of a plugin that does this for $your-favorite-editor but it's, y'know, software. There's nothing which prevents it.

[marcus_holmes]

yeah, but then your Version Control system thinks that you changed the file and it needs to commit that change.

Which is a ton more hassle than inserting tabs.

You could always make CapsLock insert a tab character so you keep the functions of the tab key separate from inserting a tab.

[jjgreen]

both?

[dkersten]

What do you mean?

[markrages]

Tabs for indentation, spaces for alignment. It is called "smart tabs" and good text editors already implement it.

[edflsafoiewq]

If you use spaces, you can check that files are okay by forbidding \t.

If you use tabs, you can check that files are okay by forbidding /^\t* /.

If you use tabs for indentation, spaces for alignment, ??????

[jjgreen]

is a joke: https://bigc.at/tabs-vs-spaces.orz

[billman]

You might as well ask if he likes vim or emacs :)

[1337shadow]

You can't compare vim and emacs, because emacs is more like nano.

[scarfacedeb]

Vim all the way >:)

[stronglikedan]

nano or nothin'!

[scarfacedeb]

well, yeah. That'll be one way to solve it.

[tobyhede]

I would have shut that down too. I feel for the maintainers in this case. The stakes are so low.