I think that there are two broad problems that make the problem so bad, and both of them can be improved significantly without placing the burden on day to day developers.
-
Show this thread
-
First, too many popular tools don't work on Windows (or only pass tests on Windows, and don't work when introducing common real world elements). The way to fix this issue is leverage: build abstractions that work on Windows,
1 reply 0 retweets 3 likesShow this thread -
then get popular tools to use them, then get less popular tools to lean on the popular tools, rinse repeat. The good news is the highest leverage points (languages) more and more support windows very competently.
1 reply 0 retweets 3 likesShow this thread -
The second problem is that people often assume (and disseminate) false information about when you really need to use portable abstractions, which causes tools to gratuitously fail to work on Windows.
1 reply 2 retweets 6 likesShow this thread -
My favorite example of this is that developers broadly believe that path.join() is unnecessary because windows "supports /". However, windows doesn't support / in "verbatim" file names beginning with "\\?\", which are used a lot to work around path size limitations.
1 reply 1 retweet 12 likesShow this thread -
So code that does `${parent}/${child}` will appear to work fine, and then fall apart when used with other production abstractions trying to be resilient on Windows.
1 reply 0 retweets 2 likesShow this thread -
You might be thinking that this kind of wacky behavior is just further evidence that Windows is a lost cause, but the truth is that the problem was caused by people believing (and disseminating) a false belief that you don't need path abstractions.
1 reply 0 retweets 7 likesShow this thread -
That's just one example. Other examples (largely historical) that I have noticed in my career include: * Windows has no support for symlinks * Windows has no support for anything like inotify
2 replies 0 retweets 4 likesShow this thread -
My favorite example of something we did in Ember CLI to better support Windows is creating the symlink-or-copy utility (kudos to
@stefanpenner for that one). It uses symlinks where available (often true on Windows!) and falls back to copying when needed.3 replies 0 retweets 10 likesShow this thread -
* We didn't have to give up good performance just to support windows * We didn't fall into the common trap of supporting symlinks on *nix and not on Windows (the "make it work but don't optimize it" trap) * The abstraction largely eliminates the cognitive load from portability
2 replies 0 retweets 8 likesShow this thread
I do not believe that "shaming" everyday developers into supporting Windows is a good idea. People have enough on their plate already, and asking them to think about new requirements all the time doesn't work.
-
-
But I do think there's a lot more we can do at the tooling level and culturally to help people fall into the "pit of success" when it comes to portability and windows support.
0 replies 0 retweets 14 likesShow this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.