5 ms·

I'm scratching my head after this article, not really sure if the author really believes in what he's complaining on fully? For me, those are kinda nice "wishes

by akavel 11y ago

I'm scratching my head after this article, not really sure if the author really believes in what he's complaining on fully? For me, those are kinda nice "wishes", in that if they happened, the porting team would have less work to do now, sure. But, actually, especially those specific things listed - they sound to me like things, which would be unnecessarily hard and really costly things to do "in the past", assuming they were initially aiming just for Windows (and maybe OSX, don't know it well). So, like, I feel like doing them that way originally was actually a very good decision. I'm even starting to think: if the author has just those things to complain about, then maybe actually the codebase should be described as written fairly portably and future-proof... To explain my argument, I'll try to elaborate a bit more on the points raised by the author: 1. Case sensitivity in paths. So, as others mentioned too: on a case insensitive filesystem like Windows, you'd have no chance to verify (i.e. test) "case-sensitive-correctness" anyway. So, you'd fail on this here and there anyway. Ok, maybe using the OSX FS with case-sensitive option would be a guard. But, OTOH, I believe OSX has it case-insensitive by default anyway, no? So, by testing in case-sensitive, you're actually testing the "least used path", which sounds not so smart, actually... especially given that switching from case-sensitive to case-insenstive (i.e. the other way) has its own surprises, then... 2. No OS #ifdefs Um;... so... like... what else to use instead?... 3. "Assumptions": 3.1. Compilers. This point seems actually to be more "no C++11". OK; yeah; sure; but remember: then you'll get maimed for being backwards, "corporate-ish", you'll get no "smart young hackers", people will get more frustrated... Not that you'd really have a good alternative to C++ (Java/Python need huge and messy runtime env; and if you need performance of C++, you need performance of C++; if you started now, you could maybe at least try using Go as a kinda compromise, but depends on your actual needs). You know, whichever way you choose, you have pros and cons. And, supposedly, some time ago when the decision was made, the pros were actually outweighing the cons; so, it wouldn't sound so smart to me to choose otherwise... 3.2. & 3.3. "Assumptions about [GUI]" Sorry to say, but: GUIs are just not portable. Every GUI environment has different "idioms", "interface guidelines", etc. Windows has different. OSX has different. Linux has different. Heck, different versions of the OSes have them different! On Linux, even in the same "OS version" (um, distro? kernel?) you have multiple "desktop environments" with different widgets, layouts, etc (KDE, Gnome, ...). Conversely, on Windows, Microsoft likes to sometimes pull you in multiple directions at the same time too, e.g. when new MS Office introduces new widgets, or new Explorer does the same, or you have Metro+classic, or whatever. Dunno about OSX; I dare suppose it's not all roses there either. I seem to believe now, that if you want to have a cross-platform app with a GUI, you should really write the GUI for each platform from scratch (only trying to reuse some parts). Or, consciously break with staying consistent with any OS interface guidelines. As to "copy & paste": on Linux it has actually totally different underlying mechanism(s) than on Windows. So, you probably have to rewrite even low level parts of it very differently. Not just menu entries. So - I don't really see what's there to complain on. The app was written for some 2 OSes; now guys port it to a third one; awesome! just, sorry, you know, there's gonna be some work needed in order to complete that. <shrug>

nacs 11y ago
> not really sure if the author really believes in what he's complaining on fully The author is a lady.
- akavel 11y ago
  Hmm, can't edit anymore to correct, sorry for the mistake.
cwyers 11y ago
> 2. No OS #ifdefs >Um;... so... like... what else to use instead?... You misread. The problem was that it was written in the form of if Windows do this, else do something that only works on OS X. The alternative is an explicit if for OS X, so that when you have a third OS to support you don't have to add that.
- akavel 11y ago
  Hm, still not quite sure how that'd help; one still has to edit all that places, no? and in case one had "#else nothing", I don't see how that's more useful in any way. And the suggested "do something sensible by default" - if one could, one wouldn't have the ifdefs at all I suppose.
  - Mathiasdm 11y ago
    One possibility would be to have #else #error #endif If you work this way, you immediately know where to change your code.
natosha_bard 11y ago
Hi! I'm glad to see that the post is promoting constructive dialog about what does or doesn't make portable code, which is what the point actually was (in addition to shedding a bit of light about the state of porting Unity to Linux). I'll clarify a few things: 1. Unity was originally written for Mac OS X, then later ported to Windows (not the other way around). Given that it's more than possible to have a case-sensitive HFS+ filesystems (since, I think OS X Panther released in 2003?), IMO it would have been more future proof for us to be sure to develop on a case-sensitive filesystem. Unity users over the years have tried to run Unity on a case-sensitive HFS+ filesystem and failed, so it would have been nice for all of those guys. :-) 2. Note that the point in the article was not to avoid using OS-specific defines (that's impossible), it was to make sure to do something sane (like #error) in the #else case that would make it immediately clear something need to be implemented there. 3.1. Yes, the higher-level point is indeed, "Be smart/cautious about what language features to use for the sake of portability". 3.2 & 3.3. Of course it's just a matter of opinion, but I wish that we'd considered a more platform-agnostic approach to GUI handling when the number of platforms that Unity was ported to went from 1 to 2. I (and others) are still a fan of the menu-system-written-entirely-in-Unity-GUI idea, but others (within Unity), for very good reasons, disagree. Fair enough. Anyway, thanks for sharing your thoughts; when I write about anything I'm always looking forward to hearing a different perspective, and one of the main goals I had in writing the post was to promote constructive dialog about what it means to write "portable" code. :-)

by akavel 11y ago

nacs 11y ago

> not really sure if the author really believes in what he's complaining on fully The author is a lady.

akavel 11y ago
Hmm, can't edit anymore to correct, sorry for the mistake.

cwyers 11y ago

> 2. No OS #ifdefs >Um;... so... like... what else to use instead?... You misread. The problem was that it was written in the form of if Windows do this, else do something that only works on OS X. The alternative is an explicit if for OS X, so that when you have a third OS to support you don't have to add that.

akavel 11y ago
Hm, still not quite sure how that'd help; one still has to edit all that places, no? and in case one had "#else nothing", I don't see how that's more useful in any way. And the suggested "do something sensible by default" - if one could, one wouldn't have the ifdefs at all I suppose.
- Mathiasdm 11y ago
  One possibility would be to have #else #error #endif If you work this way, you immediately know where to change your code.

natosha_bard 11y ago

Hi! I'm glad to see that the post is promoting constructive dialog about what does or doesn't make portable code, which is what the point actually was (in addition to shedding a bit of light about the state of porting Unity to Linux). I'll clarify a few things: 1. Unity was originally written for Mac OS X, then later ported to Windows (not the other way around). Given that it's more than possible to have a case-sensitive HFS+ filesystems (since, I think OS X Panther released in 2003?), IMO it would have been more future proof for us to be sure to develop on a case-sensitive filesystem. Unity users over the years have tried to run Unity on a case-sensitive HFS+ filesystem and failed, so it would have been nice for all of those guys. :-) 2. Note that the point in the article was not to avoid using OS-specific defines (that's impossible), it was to make sure to do something sane (like #error) in the #else case that would make it immediately clear something need to be implemented there. 3.1. Yes, the higher-level point is indeed, "Be smart/cautious about what language features to use for the sake of portability". 3.2 & 3.3. Of course it's just a matter of opinion, but I wish that we'd considered a more platform-agnostic approach to GUI handling when the number of platforms that Unity was ported to went from 1 to 2. I (and others) are still a fan of the menu-system-written-entirely-in-Unity-GUI idea, but others (within Unity), for very good reasons, disagree. Fair enough. Anyway, thanks for sharing your thoughts; when I write about anything I'm always looking forward to hearing a different perspective, and one of the main goals I had in writing the post was to promote constructive dialog about what it means to write "portable" code. :-)