Le 16.10.2013 16:42, Miles Fidelman a écrit :
berenger.mo...@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
to
have a very short-lived career.
Anyone who can't write good cross-platform code which doesn't
depend
on specific hardware and software has already limited his career.
Anyone who can write good cross-platform code has a much greater
career ahead of him. It is much harder than writing
platform-specific
code.
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
that
Explorer 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.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/dd197d3d74ff0ccd4c8c7d95b4370...@neutralite.org
