[RFC] Adopt elastic tabstops in the style guide and code.

technorama commented 9 years ago

Using elastic tabstops would solve a number of problems with existing programming styles that rely on spaces for indentation.

Proportional fonts can be used just like books, web, email, and everywhere else except programming.
Proportional fonts are easier to read making it easier to recognize words/identifiers.
Manual, editor, or auto formatter indentation changes are unnecessary.
Indentation changes won't mess up commits by modifying nearby lines when variable lengths change.
Tabs were always meant to be indent. 8 space tabs are a relic from IBM printers.
Personalize viewing. Each person can choose how much indentation they want to see (I prefer more).
Formatting tools are easier to implement (#309). They don't have to count variable names on multiple lines in order to align them.
Go and the linux kernel use them.

Spaces hold back progress (like proportional fonts). Future programs and languages are likely to adopt elastic tabstops once most programmers get past the resistance to change. Changes in style and formatting can be easily changed now. There are few projects using crystal.

Please read the following article before commenting: http://nickgravgaard.com/elastic-tabstops/ Additional reading: http://lea.verou.me/2012/01/why-tabs-are-clearly-superior/

jhass commented 9 years ago

Tabstops look horrible on every single code sharing website I've seen, including Github. That alone is giving a fat -1 from my side. I also found alignment to be generally harder with tabstops, most people end up mixing tabstops and spaces and then it looks horrible, so tabstops actually require a greater discipline when formatting source code.

asterite commented 9 years ago

I started the code formatter so hopefully all these discussions will vanish when I finish it :-)

refi64 commented 9 years ago

Tabs SUCK!! -1

asterite commented 9 years ago

(and the formatter will always use spaces, never tabs)

technorama commented 9 years ago

@asterite This discussion is to change the formatter to use tabs. Your formatter won't replace this discussion.

@jhass Greater discipline isn't required. The compiler can error if spaces and tabs are mixed. Some tools need improvement.

@kirbyfan64 Proportional fonts suck? Sorry, it's much easier to read proportional over monospaced. Example: http://home.myfairpoint.net/vzenu5ot/portfolio/sg_items/mono_propor_font_example.htm

Progress requires change. Small problems exist with elastic tabstops mostly because of display problems with some tools. Eventually more tools will support elastic tabstops but some projects need to make the jump first. Go already has and will push elastic tabstops forward.

If we don't want to make progress we shouldn't make crystal. C is good enough right? If not ruby certainly is. Shouldn't we stop working on this project?

refi64 commented 9 years ago

If we don't want to make progress we shouldn't make crystal. C is good enough right? If not ruby certainly is. Shouldn't we stop working on this project?

sigh You're kind of blowing this out of proportion a little...tabs aren't "progress". Plan 9's been using them forever. It's just a matter of opinion.

technorama commented 9 years ago

@asterite using spaces is a mistake that leaves us stuck in the 60's teletype mindset with monospaced fonts and manual indentation. My printer can output proportional fonts but I'm stuck coding with monospaced? You would think that some progress could be made in 50 years but apparently not.

technorama commented 9 years ago

Proportional vs monospaced isn't opinion. One is easier to read and the other harder. See the example above.

waj commented 9 years ago

Properly styled code in proportional font looks nice, and elastic tabstops is a great idea (I didn't know about it, but I just installed a SublimeText plugin and it works pretty well).

However, I wouldn't adopt a coding style that only looks nice in my editor. The world is already full of great ideas that just don't work because they require everybody to adopt it at the same time.

If you have the courage and time to start a movement, please go ahead. I'd start trying to convince GitHub to properly render source code using elastic tabstops. I don't know the next steps, but you must find a smooth transition path, otherwise you'll quickly get negative responses (like the ones you got so far here) because beautiful style code isn't required to continue producing software, but horrible aligned statements is a very unpleasant experience.

waterlink commented 9 years ago

I am strongly against proportional fonts for code. It makes my eyes very tired.

Best Regards, Alexey Fedorov, Sr Ruby, Clojure, Crystal, Golang Developer, Microservices Backend Engineer, +49 15757 486 476

2015-10-03 18:05 GMT+02:00 technorama notifications@github.com:

Proportional vs monospaced isn't opinion. One is easier to read and the other harder. See the example above.

— Reply to this email directly or view it on GitHub https://github.com/manastech/crystal/issues/1682#issuecomment-145261071.

technorama commented 9 years ago

@waterlink Elastic tabstops gives you a choice in fonts. You may use any font you wish. Spaces requires monospaced fonts and removes the option of using proportional fonts.

technorama commented 9 years ago

@waj I expect these sorts of comments. It's new territory for most people and they react instinctively negatively to anything different from what they're used to and think is correct (because they're used to it). Spaces for indentation was used historically due to hardware limitations. Now it's what programmers expect because that's what they learned with. They will think of any reason to attack it even if the arguments are weak and ignore the benefits of anything different.

I didn't start this movement, you can thank Nick Gravgaard. It's been many years and hardly anyone wants to move forward because everyone only knows about spaces. They don't want to do anything different or enhance existing tools.

They bring up old (and misinformed) arguments like "don't mix spaces and tabs, use spaces". Mixing spaces and tabs causes problems but the solution is to use either spaces or tabs. Neither has an advantage on this point.

"Tabs suck" that's an opinion. Proportional fonts make it easier to recognize unique words is not opinion. If it were an opinion some publishers would publish all their books in monospaced fonts. That doesn't happen.

"I don't want to use proportional fonts because I've trained myself to read monospaced faster". Elastic tabstops allows choice. Spaces don't. Keep using what you're comfortable with, I'll use proportional and so will most people who start learning with proportional.

I thought there were more forward thinkers but I guess anyone can fall in to the "defend what I know" trap. There are clear benefits in code readability and not screwing with commit history every time the indentation changes from a variable additional/removal/rename. Git blame is also ruined by auto indenters and formatting tools when name lengths change. Who added that variable? Instead of using git blame you need to read the entire commit history because it may have been reformatted 10 times. Before you say you need to read the history anyway my counterpoint will be the history is longer and much harder to read when multiple lines are reformatted just because you chose to use spaces for indentation.

Yes some formatting tools could use improvements. Go is using elastic tabstops. Github will probably change their code formatter just to support go sometime soon. If the formatter is open source I'll look at fixing it myself but quick googling didn't turn up anything. Pointers?

waterlink commented 9 years ago

@technorama Well, that is actually a different story then. From conversation I had an impression, that elastic tabs require one to use proportional fonts.

BTW, I haven't even noticed anything in my editor (VIM) when I'm using go and gofmt. Is it just that gofmt only simulates elastic tabstops behavior instead of actually using them?

Best Regards, Alexey Fedorov, Sr Ruby, Clojure, Crystal, Golang Developer, Microservices Backend Engineer, +49 15757 486 476

2015-10-03 19:01 GMT+02:00 technorama notifications@github.com:

@waj https://github.com/waj I expect these sorts of comments. It's new territory for most people and they react instinctively negatively to anything different from what they're used to and think is correct (because they're used to it). Spaces for indentation was used historically due to hardware limitations. Now it's what programmers expect because that's what they learned with. They will think of any reason to attack it even if the arguments are weak and ignore the benefits of anything different.

I didn't start this movement, you can thank Nick Gravgaard. It's been many years and hardly anyone wants to move forward because everyone only knows about spaces. They don't want to do anything different or enhance existing tools.

They bring up old (and misinformed) arguments like "don't mix spaces and tabs, use spaces". Mixing spaces and tabs causes problems but the solution is to use either spaces or tabs. Neither has an advantage on this point.

"Tabs suck" that's an opinion. Proportional fonts make it easier to recognize unique words is not opinion. If it were an opinion some publishers would publish all their books in monospaced fonts. That doesn't happen.

"I don't want to use proportional fonts because I've trained myself to read monospaced faster". Elastic tabstops allows choice. Spaces don't. Keep using what you're comfortable with, I'll use proportional and so will most people who start learning with proportional.

I thought there were more forward thinkers but I guess anyone can fall in to the "defend what I know" trap. There are clear benefits in code readability and not screwing with commit history every time the indentation changes from a variable additional/removal/rename. Git blame is also ruined by auto indenters and formatting tools when name lengths change. Who added that variable? Instead of using git blame you need to read the entire commit history because it may have been reformatted 10 times. Before you say you need to read the history anyway my counterpoint will be the history is longer and much harder to read when multiple lines are reformatted just because you chose to use spaces for indentation.

Yes some formatting tools could use improvements. Go is using elastic tabstops. Github will probably change their code formatter just to support go sometime soon. If the formatter is open source I'll look at fixing it myself but quick googling didn't turn up anything. Pointers?

— Reply to this email directly or view it on GitHub https://github.com/manastech/crystal/issues/1682#issuecomment-145265497.

waterlink commented 9 years ago

Now I see, elastic tabstop is actually pretty powerful. The only drawback is that my favorite editors (VIM, Emacs - "real editors" (c)) have no support for it and it doesn't look like there are any plugins (or can be created) for that, except for patches for editor code itself.

There is this discussion on neovim: https://github.com/neovim/neovim/issues/1419

So the next question of mine, what should someone like me do if elastic tabstops will be part official code style guide? Should I use different editor for my Crystal projects (read: less effective editor)?

And the next maybe-idea: What if adopting elastic tabstops by Crystal (and other languages) can make these features land faster to major editors?

Best Regards, Alexey Fedorov, Sr Ruby, Clojure, Crystal, Golang Developer, Microservices Backend Engineer, +49 15757 486 476

2015-10-03 19:14 GMT+02:00 Alex Fedorov waterlink000@gmail.com:

@technorama Well, that is actually a different story then. From conversation I had an impression, that elastic tabs require one to use proportional fonts.

BTW, I haven't even noticed anything in my editor (VIM) when I'm using go and gofmt. Is it just that gofmt only simulates elastic tabstops behavior instead of actually using them?

Best Regards, Alexey Fedorov, Sr Ruby, Clojure, Crystal, Golang Developer, Microservices Backend Engineer, +49 15757 486 476

2015-10-03 19:01 GMT+02:00 technorama notifications@github.com:

@waj https://github.com/waj I expect these sorts of comments. It's new territory for most people and they react instinctively negatively to anything different from what they're used to and think is correct (because they're used to it). Spaces for indentation was used historically due to hardware limitations. Now it's what programmers expect because that's what they learned with. They will think of any reason to attack it even if the arguments are weak and ignore the benefits of anything different.

I didn't start this movement, you can thank Nick Gravgaard. It's been many years and hardly anyone wants to move forward because everyone only knows about spaces. They don't want to do anything different or enhance existing tools.

They bring up old (and misinformed) arguments like "don't mix spaces and tabs, use spaces". Mixing spaces and tabs causes problems but the solution is to use either spaces or tabs. Neither has an advantage on this point.

"Tabs suck" that's an opinion. Proportional fonts make it easier to recognize unique words is not opinion. If it were an opinion some publishers would publish all their books in monospaced fonts. That doesn't happen.

"I don't want to use proportional fonts because I've trained myself to read monospaced faster". Elastic tabstops allows choice. Spaces don't. Keep using what you're comfortable with, I'll use proportional and so will most people who start learning with proportional.

I thought there were more forward thinkers but I guess anyone can fall in to the "defend what I know" trap. There are clear benefits in code readability and not screwing with commit history every time the indentation changes from a variable additional/removal/rename. Git blame is also ruined by auto indenters and formatting tools when name lengths change. Who added that variable? Instead of using git blame you need to read the entire commit history because it may have been reformatted 10 times. Before you say you need to read the history anyway my counterpoint will be the history is longer and much harder to read when multiple lines are reformatted just because you chose to use spaces for indentation.

Yes some formatting tools could use improvements. Go is using elastic tabstops. Github will probably change their code formatter just to support go sometime soon. If the formatter is open source I'll look at fixing it myself but quick googling didn't turn up anything. Pointers?

— Reply to this email directly or view it on GitHub https://github.com/manastech/crystal/issues/1682#issuecomment-145265497 .

technorama commented 9 years ago

More users = more demand = more support in common tools.

Someone has to lead. So far it's individual projects that adopt elastic tabstops regardless of language. All of my personal projects in the last 8 years have used elastic tabstops. To me it seems like common sense. For everyone recently exposed it takes time to see the benefits and realize why "the status quo sucks". If you look at the historical reasons why we do things the current way it sucks even more.

technorama commented 9 years ago

@waterlink I was mistaken about gofmt. I haven't used go since before gofmt was introduced. It uses tabs for indentation and spaces for alignment. That's why go code is aligned correctly on github.

refi64 commented 9 years ago

sigh again Look, I hate tabs. Them sucking is my opinion. Which is my point: tabs vs spaces is an opinion. No one can say one is better than the other because of "facts". Because it all depends on what qualities you prefer.

waterlink commented 9 years ago

From my point of view it is not about spaces vs tabs, but about spaces vs tabs vs elastic tabstops. They are entirely different from tabs as far as I understand, - am I correct?

Best Regards, Alexey Fedorov, Sr Ruby, Clojure, Crystal, Golang Developer, Microservices Backend Engineer, +49 15757 486 476

2015-10-03 20:53 GMT+02:00 Ryan Gonzalez notifications@github.com:

sigh Look, I hate tabs. Them sucking is my opinion. Which is my point: tabs vs spaces is an opinion. No one can say one is better than the other because of "facts". Because it all depends on what qualities you prefer.

— Reply to this email directly or view it on GitHub https://github.com/manastech/crystal/issues/1682#issuecomment-145278483.

jhass commented 9 years ago

@waterlink same character/codepoint, different rendering.

waterlink commented 9 years ago

I see.

waterlink commented 9 years ago

I have a feeling, that this idea would have had more appreciation if it have had its own character/codepoint..

vyp commented 9 years ago

@technorama I think you're 'cheating' with that example. I agree for proportional > monospace for prose. But for code? Barely readable to me.

About (elastic) tabs vs spaces. I read what you said, but it's still a big -1 to using tabs for me.

technorama commented 9 years ago

@vyp You aren't forced to use to use any particular font with elastic tabstops. I'm forced to use monospaced fonts with spaces. That's the problem.

vyp commented 9 years ago

Ah, that's true. I'm still against using tabs though. Imo it's just not worth the hassle: http://programmers.stackexchange.com/a/137294. For it to be acceptable to me, even basic tools like cat and less would have to support it really.

Also, any decent editor should handle automatic indentation (and re-alignment), even with spaces, if that's what you really want it for (e.g. using the </> commands in vim). But I think your main arguments I got from you are the ability to use proportional font (I don't care about using a proportional font for code, but I can understand that others can have a preference for it), and re-alignment making noise in diffs.

Again I understand I sound exactly like the old stubborn gray beard set in their ways and holding back progress like you're talking about, but it would just make it a lot harder for people like me (emacs/vim/cli user) to contribute to a project using elastic tabstops, which is the main reason I am still -1. If emacs had better support for it (does anyone know if that is the case? I tried searching but couldn't find much), I probably wouldn't have that much of an objection.

waterlink commented 9 years ago

Well, as far as I understand, elastic tabstop does not clobber diffs unless editor converts it too tabs+spaces and leaves the original elastic tabstop character there. So in editor you will see multiple lines changing alignment, but in actual bytes in the file, only one line were changed.

Of course that means, that:

version control systems need to know how to render them
major editors and IDEs need to know how to render them
major code viewers on web (github, bitbucket, paste, etc.) need to know how to render them

This is a quite long journey. What one could do is to only try to add these features to mentioned technologies by contribution.

About current topic, I don't think it is feasible to add elastic tabstops to language style guide, unless full ecosystem supports it. It would be fine with me if (or once):

Elastic tabstop use their own character (like vertical tab for example).
There will be plugin for emacs, vim and some major IDEs for crystal, that will enable usage of elastic tabstops. Or we might implement our own editor/IDE specifically for Crystal language that will have support for them.
At least github lands support for elastic tabstops.

While these are not yet true, it would be impossible to actually follow this code style rule for most of the people.

vyp commented 9 years ago

I personally feel like making another editor/ide for this is not worth the effort/time.

waterlink commented 9 years ago

Well, making IDE for Crystal, that will have all the specifics and power to work with Crystal ecosystem is a different goal :)

vyp commented 9 years ago

Ah right, correct. Btw, I agree with the points you have put forward. While I can see the potential advantages that @technorama talks about, I think overall this makes contribution more difficult just because of the current lack of support (I think?). What editors/ides/tools do support elastic tabstops right now btw? (if anyone knows)

waterlink commented 9 years ago

Looks like Gedit and Visual Studio have plugins. For visual studio you need to pay for one. This is what I can grab from googling and here: http://nickgravgaard.com/elastic-tabstops/news/

ysbaddaden commented 9 years ago

No, the Gedit plugin is broken. VIM and Emacs have no plan to implement this anytime soon. The SublimeText plugin implementation is wrong. CLI tools (cat, grep and alikes) don't support them, and don't even allow to specify the tab width, which kills the "I can use the indentation I like" argument, ...

waterlink commented 9 years ago

@ysbaddaden I think you are right.

Another thought about cat, grep, etc: they are not a big problem as long as you put another cli tool in a pipe, like: cat x.cr | grep something | etst, where etst is a convenience cli tool of future that automatically expands all elastic tabs. It should be used only for presenting to user, not for actual storing in files. This holds good with the unix spirit of "one tool does one job and does it great".

And I don't have any points on other problems, it is just a pity, that plugins are broken and vim and emacs (my favorite editors, "real editors" (c)) do not support and not going to support it any time soon.

ozra commented 9 years ago

@technorama I find it funny the discussion a bit funny in a way, seeing that that tabs was all I used since I started coding 28 years ago all the way up till about 4 years ago when I finally switched to using spaces for indent. Prejudice against space based indent. Elastic tabstops is of course a completely different beast than both tabs and spaces, and an interesting one, albeit, troublesome.

[ ed: Holy shit, when I start ranting it turns into a fucking book... the essence is under the heading "The Road Forward (TM)", I just have a hard time making myself delete all the crap I wrote... ]

The first fifteen years I used 8 char tab stops always. Just the last few years I got out of my prejudice towards space-based indent. I've worked with 4 and 2 spaces source bases this time.

Anyway, now that I've shown my age (and yes I've got a beard)

I agree 2 space indent is ridiculous (sorry Crystal code base)
4 places strikes a perfect balance, imho (I think 3 would be optimal, but going odds against evens is probably a nightmare in many editors (a main point regarding this whole discussion).
I've come to realize that code is a lot like poetry: form matters! That's why I finally went with spaces (and well, some projects where the standard was already set). The way different rows content is aligned with each other can make or break readability, and some coders are really good at shaping it just right.

(*) Confession: I admit - when I said I use two spaces in projects using it - I really replace to 4 spaces locally and then back - two-space sources are unreadable to me. It's not perfect for you @technorama, but /\s\s/\t/g -> reverse when done -> check in meld or w/ever diff-tool that project style form is intact. It might help you a bit at least, for the moment being?

Elastic tabs could be wonderful

The problems - (as already mentioned by many above: Support!

The obvious: it's not widely supported yet.
Rendering elastic tabs is a completely different beast to that of rendering regular tabs or simple spaces - this may make the employment rather slow in existing tools.

The Road Forward (TM)

I think the absolutely best thing you can do to break the current "stuck in spaces hiatus" is to:

Code elastic tabstops functionality for some popular editor(s) (vim comes to mind, even though I've sold out to sublime lately)
Code wrappers for cat, less, etc. that one can install at will - so the support ends up in the terminal (I less and vim code a lot in terminal, even when editing in sublime primarily - it would annoy me a lot if code didn't look the same in different places.)
Fork the Crystal formatter when it's done, and make a "elastic tabstops" formatting option. That way you can quickly get code in a way that will make your editing convenient and enjoyable, and then just run crystal formatter with "community recommended style" as output when publishing, PR'ing.

@waterlink - I agree a different codepoint could probably be a good thing, this would make it easier for tools to separate what the meaning of the code is - since 'fixed-unit stops' is the currently engraved meaning for 0x09.

I won't be switching to elastic tabstops until it's mandated. Me personally, I even enjoy code on paper better for planning and deep debuggings than on screen - because of the fixed positions.

The Ultimate Way (TM)

Perhaps some people are more inclined to think and relate spatially, while some focus more on the tokens them self without need to "fix" them positionally. Food for thought.

The running point as I see it: letting everyone code in the way that they enjoy, while still having a unified form for collaboration (read: "formatting tools") is the ultimate way.

So: formatting tools, formatting tools, formatting tools. And your favourite editor.

Code is poetry 
   - not prose; form matters

(and as you can tell, I'm not really a poet ;-) )

asterite commented 8 years ago

I don't think we'll go for elastic tabstops. The formatter is already pretty useful and takes care of a lot of formatting issues :-)

crystal-lang / crystal