Le 16.10.2013 16:42, Miles Fidelman a écrit :
berenger.morel@neutralite.org wrote:Le 16.10.2013 13:04, Jerry Stuckle a écrit :Anybody who thinks that being able to write code (be it Java, C, or .NET crap), without knowing a lot about the environment their code is going to run in, much less general analytic and design skills, is going tohave a very short-lived career.Anyone who can't write good cross-platform code which doesn't dependon specific hardware and software has already limited his career. Anyone who can write good cross-platform code has a much greatercareer ahead of him. It is much harder than writing platform-specificcode.If writing portable code is harder than platform-specific code (which is arguable nowadays), then, could it be because you have to take about type's min/max values? To take care to be able to use /home/foo/.bar, /home/foo/.config/bar, c:\users\foo\I\do\not\know\what depending on the platform and what the system provides? Those are, of course, only examples.Absolutely harder, by a long shot - in some cases you can write to the lowest-common-denominator of all platforms, and in some cases cross-platform libraries can help, but in most cases "cross-platform" means you have to include a lot of tests and special cases. Consider several examples: 1. Simple HTML/JavaScript apps to run in browsers - it's practically impossible to write stuff that will run the same in every browser -different browsers support different subsets of HTML5, and beyond thatExplorer does things one way, Firefox another, Safari another, Chrome another - and that's before you start talking desktop vs. mobile. Yes, things like PhoneGap can hide a lot of that for you, but you still end up needing to write a lot of tests and browser-specific accomondations (and then test in every browser).
I must admit that I do not know a lot about website programming, but I have heard about those problems, yes. Now, people should keep in mind that web applications often uses non-standard stuff. HTML5 is still not a released standard (I should say recommendation to use the W3C's therm). And I think that it is an error to transform HTML for that need, but well, this is not the subject here.
Please, let's talk about families of softwares. You speak about HTML/JS applications. I have a better name for the most common part of them: client-server applications. A client send a request to a server, and the server replies. Ok, if you agree that that kind of applications is the most part of webapps then consider examples of applications which uses a different language set. There are lot of them: mpd, various ftp servers (and clients, of course), etc. Was the portability a real problem because of a dirty screen rendering? I do not think so. They simply (or should) send the OS-specific stuff in a library and then base their application on that lib. It includes endianness.
Speaking about endianness, it really is hard to manage:
void myfunction( ... )
{
#ifdef BIG_ENDIAN
move_bytes_in_a_specific_order
#else
move_bytes_in_the_other_specific_order
#endif
}
And it is for C. Java and many other languages just do not care,
because a VM does the job for them. Writing small functions that just do
one thing should be the rule, and then it's quite easy to perform a task
in an order or in reverse. If not, provide me an example of code where
it really is hard, please.
The other part of those applications are... desktop applications.Again, here, I would recommend to use technologies which are made of. I do not like Java at all, but see, it is by far a better choice, if what you want is a binary that can be used on any platform without compiling anew. HTML was simply not designed to do what "we" are doing with it, and *this* is the problem, in my opinion. They do not even have a consistent stuff to build interfaces, where there are dozens in other languages which proves that they work from *years*.
Using a technology set to do something it is not designed to do and then complaining that it is hard... I think that's quite strange (not to speak about accessibility problems that I have heard to be impossible to fix). But, indeed, it is hard. On the other hand, lot of websites without flashy effects and dirty JS works fine. Did you ever noticed that a lot of websites uses some JS code to build simple links? I did, because I now disable JS by default, and it is quite funny. But almost all websites works, and more important, all website with useful and real content. Websites which only want to sell advertisements without any content on the other hand does not, same for those with malwares.
2. Anything that does graphics, particularly things that are graphics intensive (like games). Different GPUs behave differently (though OpenGL certainly hides a lot for you), and you still have to detect, if not accomodate, systems that don't have a GPU.
If you want an application which is graphics intensive, I strongly doubt that you will be able to make it working on a computer without GPU. Or with a cheap or old GPU. In fact, you can write an application portably or not: you will anyway have minimal requirements to run it, 3D or not. Some 3D games are portable. They do that by using OpenGL or libraries which encapsulate OpenGL and DirectX. The complexity is not because they had to maintain the application portable, it is because you need to optimize it. If you use only OpenGL standard stuff of the same version, is not it a driver's bug if cards react differently? (it is a true question) Anyway, those bugs would exists, but since it depends on driver's version or on graphic card, you will have that same problem with non portable stuff too. Or maybe you would name a windows 7-only game a portable game, since there are many GPUs supported by this version of Windows? That would be true, in the absolute, it can run on multiple systems, but it is not what we usually mean by portable application, right?
3. Just look at all the tests and compile time options that get run by make (or config) granted that automake generates a lot of that for you, but still.
Autotools are not really what I could name a good example. They were maybe, at a time, one of the best tools we had. Now, I would strongly recommend people to use something else on their new projects, except if a large majority of the contributors only know autotools.
In conclusion, I think that doing portable stuff is not so hard to do, excepted when you want to force the system to do something it is not made to do. Like with HTML, or with doing graphical stuff when you have no GPU. People who want to build portable stuff should remember that different systems means various interfaces ( touchscreen versus mouse/keyboard for example ), various hardware possibilities ( strong GPU on a gamer's computer versus a simple chipset for netbooks ). Sometimes you can simply not port a software to another medium: I will never try to port gnome3 ( or KDE, or whatever ) to my dishwasher. That would be too hard, of course, but also, very, very stupid. Porting it to windows on the other hand could be made, and could makes sense.
I only have the autotools example that remains, but, do not speak about 1 software, speaking about software families and/or features seems smarter to me.