4 ms·

>> This is different from Apple with OSX and iOS how? I'll never run "npm install" or "gem install" or what have you on iOS, Android, etc. Proprietary OSes com

by city41 11y ago

>> This is different from Apple with OSX and iOS how? I'll never run "npm install" or "gem install" or what have you on iOS, Android, etc. Proprietary OSes come in all shapes and sizes, all bringing their own pros and cons to the mix. I just happen to be focusing on a very large con of Windows at the moment. As for OSX, Redhat, Debian, etc. Sure, they're all different, of course. But generally speaking, at least when it comes to Node and npm (and as far as I know, Ruby, Clojure, Python, etc, please correct me if I'm wrong), these OSes tend to get along pretty OK. Windows, does not. >> And for crying out loud, file separator issues? That's not even a hard one. And yet how many times has that problem been hit over the decades? I mean heck, look at the commit message, "Another Windows path issue". And yeah, it's not even a hard one, it just gets worse from there. I came to that issue from here (which is my project): https://github.com/city41/reagent-breakout/issues/11 https://github.com/city41/reagent-breakout/issues/11 So for "not even a hard one", still took me 20 minutes of digging to find out what was going on. X minutes across all developers across how long Windows has been around really adds up. For just one of Windows's differences.

moron4hire 11y ago
I don't think you realize just how different even various Linux distros running even the same kernel can be, and I think you're giving waaay too much credit to OSX/Linux for being "alike". MAKE build scripts have notoriously been a mess for decades because of the differences between distros. Any reasonable language has the ability to query all of the platform-specific stuff directly from the standard library. You can't even count on two Windows users having their home directories in the same place, or two Arch users having all of their config files in the same place. It's a necessity to be able to abstract all of these away even for a single operating system, which means you get it for free when moving to other operating systems.
- city41 11y ago
  I do get that. I totally understand all OSes are very different. How often those differences surface really depends on a lot of things, mostly at what level of the OS you are working in. Node modules and apps tend to stay pretty high level. But again, I still stand by my original statement that Windows specific issues crop up more than any other OS. Just take a look at the README for node-gyp: https://github.com/nodejs/node-gyp https://github.com/nodejs/node-gyp -- yup in OSX you have to get Xcode and a few other OSX specific steps to arrive at gcc and make, but compare that to the Windows section ...
  - moron4hire 11y ago
    There is no reason building Windows software has to be this hard, other than the maintainer just not putting even a reasonable amount of effort into it. When developers are hostile torwards Windows, this is the result. This doesn't do anything to Microsoft, this just hurts other developers and users.
    - city41 11y ago
      gyp was created by Google for building Chrome. I would guess they've put a decent amount of effort into it.
  - gelasio 11y ago
    Other projects have to do a lot of work to support OS X too. So I guess I still don't see your point. Electron, for instance, had to program an entirely different object model to represent OS X's kludgy global menu bar when every other OS has menus attached to application windows. I can't believe your defending OS X though when Apple makes you buy a whole computer from them to use it...meanwhile I can run a 6 month trial of Windows (over and over again) on any virtual machine. Honestly, it's way more work to support OS X than Windows if you really bother to look at it.
    - city41 11y ago
      Apple is definitely not innocent here. They force a lot of terrible decisions too. I think ultimately though, this conversation boils down to my bias and experience versus your bias and experience.
      - gelasio 11y ago
        Sure, everybodys bias is painfully obvious here on HN. But I don't think that negates the fact that to develop anything at all for OS X I have to buy a whole computer from Apple, since it's damn near impossible to get a stable OS X experience by running it in a VM or directly on non-Apple hardware. Furthermore, remotely accessing Xcode on a Mac from a non-Mac computer is really painful since the only option is VNC - the bottom of the barrel, lowest common denominator of remote screen sharing protocols.
tracker1 11y ago
Given windows is the vast majority of desktops, and that there is more variety between different Linux distros and OSX versions than there are in the decades of Windows APIs, I think you have things a little backwards. I've done far more dev targeting linux deployments the past few years, and much of it is far nicer on *nix than windows... but your viewpoint seems to be kind of arrogant. I haven't worked for a company that has more than 100 employees that doesn't do most development on windows, even if that isn't the target for deployment. That includes two major financial institutions, some large internet services and many other smaller companies over the years.
- city41 11y ago
  I don't mean to be arrogant, and if I am honestly it comes from ignorance. I've worked in MS shops before (I did .NET, COM, etc for nearly a decade). This whole thing blew up out of frustration at Windows specific issues cropping up more often than any other OS in environments like Node. I do think that's hard to deny. If that's arrogant, then I don't know what to say :-/
  - Silhouette 11y ago
    There is a real problem here, but I think you're laying the blame a little unfairly at Microsoft's doorstep. It's probably fair to say that at least until relatively recently Microsoft has gone to far greater lengths to ensure compatibility and longevity of code build on its platforms than any other organisation in the history of software development. We used to value writing portable software as a skill, we used to value languages and libraries with robust specifications that could be used to write portable code, and portable code is also relatively future-proof code. I've worked on large projects that shipped on literally a dozen or more different platforms at any given time and were maintained for well over a decade with the significant variations in platforms that happen over that kind of time frame. Those projects built probably 95+% of the same source code for each platform, with platform-specific APIs and conventions carefully isolated. That attitude and the related skills seem to have been much less valued in recent years, not least by the Linux community. (What, you want to build this C or C++ code with a tool chain other than GCC and friends?) If people carelessly scatter platform-specific code all over their projects, then of course they won't be easily portable, but more often than not such limitations are entirely artificial and could easily be avoided at negligible cost. In my experience, this is also true of a lot of libraries with the likes of Node and Python where native code is used in managed packages, and I think it's fair to consider that the resulting portability limitations are a potential disadvantage when choosing the language for a project.

by city41 11y ago

moron4hire 11y ago

I don't think you realize just how different even various Linux distros running even the same kernel can be, and I think you're giving waaay too much credit to OSX/Linux for being "alike". MAKE build scripts have notoriously been a mess for decades because of the differences between distros. Any reasonable language has the ability to query all of the platform-specific stuff directly from the standard library. You can't even count on two Windows users having their home directories in the same place, or two Arch users having all of their config files in the same place. It's a necessity to be able to abstract all of these away even for a single operating system, which means you get it for free when moving to other operating systems.

city41 11y ago
I do get that. I totally understand all OSes are very different. How often those differences surface really depends on a lot of things, mostly at what level of the OS you are working in. Node modules and apps tend to stay pretty high level. But again, I still stand by my original statement that Windows specific issues crop up more than any other OS. Just take a look at the README for node-gyp: https://github.com/nodejs/node-gyp https://github.com/nodejs/node-gyp -- yup in OSX you have to get Xcode and a few other OSX specific steps to arrive at gcc and make, but compare that to the Windows section ...
- moron4hire 11y ago
  There is no reason building Windows software has to be this hard, other than the maintainer just not putting even a reasonable amount of effort into it. When developers are hostile torwards Windows, this is the result. This doesn't do anything to Microsoft, this just hurts other developers and users.
  - city41 11y ago
    gyp was created by Google for building Chrome. I would guess they've put a decent amount of effort into it.
- gelasio 11y ago
  Other projects have to do a lot of work to support OS X too. So I guess I still don't see your point. Electron, for instance, had to program an entirely different object model to represent OS X's kludgy global menu bar when every other OS has menus attached to application windows. I can't believe your defending OS X though when Apple makes you buy a whole computer from them to use it...meanwhile I can run a 6 month trial of Windows (over and over again) on any virtual machine. Honestly, it's way more work to support OS X than Windows if you really bother to look at it.
  - city41 11y ago
    Apple is definitely not innocent here. They force a lot of terrible decisions too. I think ultimately though, this conversation boils down to my bias and experience versus your bias and experience.
    - gelasio 11y ago
      Sure, everybodys bias is painfully obvious here on HN. But I don't think that negates the fact that to develop anything at all for OS X I have to buy a whole computer from Apple, since it's damn near impossible to get a stable OS X experience by running it in a VM or directly on non-Apple hardware. Furthermore, remotely accessing Xcode on a Mac from a non-Mac computer is really painful since the only option is VNC - the bottom of the barrel, lowest common denominator of remote screen sharing protocols.

tracker1 11y ago

Given windows is the vast majority of desktops, and that there is more variety between different Linux distros and OSX versions than there are in the decades of Windows APIs, I think you have things a little backwards. I've done far more dev targeting linux deployments the past few years, and much of it is far nicer on *nix than windows... but your viewpoint seems to be kind of arrogant. I haven't worked for a company that has more than 100 employees that doesn't do most development on windows, even if that isn't the target for deployment. That includes two major financial institutions, some large internet services and many other smaller companies over the years.

city41 11y ago
I don't mean to be arrogant, and if I am honestly it comes from ignorance. I've worked in MS shops before (I did .NET, COM, etc for nearly a decade). This whole thing blew up out of frustration at Windows specific issues cropping up more often than any other OS in environments like Node. I do think that's hard to deny. If that's arrogant, then I don't know what to say :-/
- Silhouette 11y ago
  There is a real problem here, but I think you're laying the blame a little unfairly at Microsoft's doorstep. It's probably fair to say that at least until relatively recently Microsoft has gone to far greater lengths to ensure compatibility and longevity of code build on its platforms than any other organisation in the history of software development. We used to value writing portable software as a skill, we used to value languages and libraries with robust specifications that could be used to write portable code, and portable code is also relatively future-proof code. I've worked on large projects that shipped on literally a dozen or more different platforms at any given time and were maintained for well over a decade with the significant variations in platforms that happen over that kind of time frame. Those projects built probably 95+% of the same source code for each platform, with platform-specific APIs and conventions carefully isolated. That attitude and the related skills seem to have been much less valued in recent years, not least by the Linux community. (What, you want to build this C or C++ code with a tool chain other than GCC and friends?) If people carelessly scatter platform-specific code all over their projects, then of course they won't be easily portable, but more often than not such limitations are entirely artificial and could easily be avoided at negligible cost. In my experience, this is also true of a lot of libraries with the likes of Node and Python where native code is used in managed packages, and I think it's fair to consider that the resulting portability limitations are a potential disadvantage when choosing the language for a project.