Slashdot Mirror
Write Portable Code
Simon P. Chappell writes "Much as a certain large software company located in the North-West of the United States of America might wish otherwise, there are many different operating systems and platforms in use in the world today. Software these days needs to able to operate in a disparate environment, either by communicating with these other platforms or by running on them or, increasingly, doing both. The Information Systems industry is making good progress with the communication half of the problem (even if a lot of it seems to involve large amounts of XML), but it is still struggling with the issues inherent with writing portable code. Brian Hook's contribution to all of this is Write Portable Code , which according to it's subtitle is an introduction to developing software for multiple platforms." Read on for the rest of Simon's review.
Write Portable Code
author
Brian Hook
pages
248 (14 page index)
publisher
No Starch Press
rating
8/10
reviewer
Simon P. Chappell
ISBN
1593270569
summary
I recommend this book to anyone working with portable code.
This is a book for computer programmers who write software designed to run on multiple platforms. It's also for programmers who suspect that their software may need to run on different platforms. This brings the book onto the radar for free and open source software authors, as they seek to create software that does not trap their end users into using specific operating systems. The Structure
There is a good progression shown in the eighteen chapters of the book. The first couple of chapters introduce the reader to portability concepts and then to some of the specific portability features of ANSI C and C++ that are used throughout the rest of the book.
The middle chapters of the book, cover individual portability topics. Some of these topics are the obvious ones, like Floating Point numbers, Networking, Operating System, File System and Dynamic Libraries. Other topics are less intuitively associated with portability, but when you read the chapter, it's inclusion is both obvious and necessary. These subjects include Source Code Management, Compilers, Scalability and Data. There is more to portability than many of us might suspect.
The last two chapters look at some alternative ways of getting portability. Scripting languages are discussed and the pros and cons of each ones portability is weighed. Lastly the use of cross-platform libraries and toolkits is addressed. Quite apropos given that the book's author is also the author of a cross platform library.
As an example of the thoughtful approach taken in this book, lets' take a look at the chapter on scripting languages. It's about the shortest chapter in the book, but representative of the approach that Mr. Hook brings to his work. This chapter takes a very honest look at the portability and cross-platform aspects of using scripting languages. There are advantages and disadvantages to the use of scripting languages. The advantages include everything that is a disadvantage of low-level languages like C/C++. Scripting languages do not require you to worry about about memory allocation, bindings, System API calls or any of the other bugbears of a low-level language programmer's life. The disadvantages of scripting languages naturally include performance, given their interpreted natures, a general lack of tools, such as development environments or IDEs and their tendency to sit high above the operating system with a corresponding detachment from low-level facilities and services of that same operating system. Mr. Hook's choice of scripting languages to consider was interesting. I expected Ruby and Python; both popular and capable in their own right. The inclusion of JavaScript/ECMAScript was also not too unexpected, now that standalone versions are bubbling up and becoming available. The real surprise, albeit a pleasant one, was the inclusion of Lua; a scripting language designed for platform portability and which seems to have managed to fully mature without making a blip on most geeks radar screens.
I like that Mr. Hook has experience writing portable software. This matched with his authorship of the Portable Open Source Harness (POSH) portability library and his contributions to the Simple Audio Library (SAL) gives a great deal of credence to his writing.
This is a solid "doing" book. Mr. Hook is under no illusion that he's writing an introduction to programming. This book has a consistent purpose to take experienced programmers and fully equip them to deal with portability and it does not deviate from this in the slightest.
The layout of the book is first rate, with clear typography, comfortable spacing, clear diagrams and tables and nicely highlighted callouts. I did not notice any obvious typos or glitches in the book. While the look of a book is not the author's fault if it is below par, a well presented book can enhance the reading and learning experience.
The examples are as realistic as possible. While some of the examples to teach principles might be simpler, they are typically backed up with examples from either the POSH or SAL projects, showing real world portability coding. The level of C/C++ required to understand the examples is higher than many books that I've read. That's not to say that the code seems obfuscated, but it's code that is taking into account aspects of the real world and is, by necessity, not simple. A further positive quality of the code examples is that they're very well explained; well enough that an inexperienced programmer with determination could follow them and come to an understanding.
Appendix B contains a summary of all of the portability rules presented through the book. There are twenty rules and each is reprised with a small explanation/reminder of it's application. An example: Rule 4 - "Never read or write structures monolithically from or to memory. Always read and write structures one element at a time, so that endian, alignment, and size differences are factored out."
If you're looking for more of a fluffy "about" book, then this is not it. This is not a complaint, rather I offer it as something to consider, before you buy what you might otherwise think is a beginner's book.
I must reiterate the non-trivial C/C++ example code the book contains. This book is for serious programmers and is not afraid to role up it's sleeves and cut real code.
This is a very well written and very readable book. There are many aspects to the subject matter of portability and Mr. Hook addresses more of them than many of us had previously suspected existed and addresses them with firm authority. I recommend this book to anyone working with portable code."
You can purchase Write Portable Code from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This is a book for computer programmers who write software designed to run on multiple platforms. It's also for programmers who suspect that their software may need to run on different platforms. This brings the book onto the radar for free and open source software authors, as they seek to create software that does not trap their end users into using specific operating systems. The Structure
There is a good progression shown in the eighteen chapters of the book. The first couple of chapters introduce the reader to portability concepts and then to some of the specific portability features of ANSI C and C++ that are used throughout the rest of the book.
The middle chapters of the book, cover individual portability topics. Some of these topics are the obvious ones, like Floating Point numbers, Networking, Operating System, File System and Dynamic Libraries. Other topics are less intuitively associated with portability, but when you read the chapter, it's inclusion is both obvious and necessary. These subjects include Source Code Management, Compilers, Scalability and Data. There is more to portability than many of us might suspect.
The last two chapters look at some alternative ways of getting portability. Scripting languages are discussed and the pros and cons of each ones portability is weighed. Lastly the use of cross-platform libraries and toolkits is addressed. Quite apropos given that the book's author is also the author of a cross platform library.
As an example of the thoughtful approach taken in this book, lets' take a look at the chapter on scripting languages. It's about the shortest chapter in the book, but representative of the approach that Mr. Hook brings to his work. This chapter takes a very honest look at the portability and cross-platform aspects of using scripting languages. There are advantages and disadvantages to the use of scripting languages. The advantages include everything that is a disadvantage of low-level languages like C/C++. Scripting languages do not require you to worry about about memory allocation, bindings, System API calls or any of the other bugbears of a low-level language programmer's life. The disadvantages of scripting languages naturally include performance, given their interpreted natures, a general lack of tools, such as development environments or IDEs and their tendency to sit high above the operating system with a corresponding detachment from low-level facilities and services of that same operating system. Mr. Hook's choice of scripting languages to consider was interesting. I expected Ruby and Python; both popular and capable in their own right. The inclusion of JavaScript/ECMAScript was also not too unexpected, now that standalone versions are bubbling up and becoming available. The real surprise, albeit a pleasant one, was the inclusion of Lua; a scripting language designed for platform portability and which seems to have managed to fully mature without making a blip on most geeks radar screens.
I like that Mr. Hook has experience writing portable software. This matched with his authorship of the Portable Open Source Harness (POSH) portability library and his contributions to the Simple Audio Library (SAL) gives a great deal of credence to his writing.
This is a solid "doing" book. Mr. Hook is under no illusion that he's writing an introduction to programming. This book has a consistent purpose to take experienced programmers and fully equip them to deal with portability and it does not deviate from this in the slightest.
The layout of the book is first rate, with clear typography, comfortable spacing, clear diagrams and tables and nicely highlighted callouts. I did not notice any obvious typos or glitches in the book. While the look of a book is not the author's fault if it is below par, a well presented book can enhance the reading and learning experience.
The examples are as realistic as possible. While some of the examples to teach principles might be simpler, they are typically backed up with examples from either the POSH or SAL projects, showing real world portability coding. The level of C/C++ required to understand the examples is higher than many books that I've read. That's not to say that the code seems obfuscated, but it's code that is taking into account aspects of the real world and is, by necessity, not simple. A further positive quality of the code examples is that they're very well explained; well enough that an inexperienced programmer with determination could follow them and come to an understanding.
Appendix B contains a summary of all of the portability rules presented through the book. There are twenty rules and each is reprised with a small explanation/reminder of it's application. An example: Rule 4 - "Never read or write structures monolithically from or to memory. Always read and write structures one element at a time, so that endian, alignment, and size differences are factored out."
If you're looking for more of a fluffy "about" book, then this is not it. This is not a complaint, rather I offer it as something to consider, before you buy what you might otherwise think is a beginner's book.
I must reiterate the non-trivial C/C++ example code the book contains. This book is for serious programmers and is not afraid to role up it's sleeves and cut real code.
This is a very well written and very readable book. There are many aspects to the subject matter of portability and Mr. Hook addresses more of them than many of us had previously suspected existed and addresses them with firm authority. I recommend this book to anyone working with portable code."
You can purchase Write Portable Code from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Truly portable code is like flipping someone the bird.
No matter what country (OS) you're working in, everyone understands it!
How can I write portable versions of Mac OS X apps when the Cocoa API doesn't exist outside of Mac OS X (don't tell me about YellowBox or what-have-you) and the language Objective C isn't supported outside of Mac OS X (Apple is killing off Cocoa's Java support)? Oh, and the Carbon API doesn't exist outside of Mac OS X either (but at least it uses a widely supported language). You mentioned a software company in the Northwest US, but what about the one in Cupertino? Apps written to their platform are no more portable than Windows apps.
Besides that, apps that aren't able to take advantave of the underlying platform's unique features aren't sellable. Mac users in particular want apps that take advantage of the unique features of Mac OS X (and no, they don't consider some unix app to be a real "Mac" app, and rightly so). That means Cocoa or Carbon, and neither api is supported outside of Mac OS X.
-- "I never gave these stories much credence." - HAL 9000
"as a certain large software company located in the North-West of the United States of America might wish otherwise, there are many different operating systems and platforms in use in the world today. "
If his first sentence isn't trolling I don't know what is. Why is it ok to do it against MS, but nobody else?
You do it against MS, you make the front page, against apple you get flamed.
"If you haven't ported your code, it isn't portable."
Sticking to the libraries and (subsets of) languages that are really portable helps, too, like this book appears to cover, but if you just start off on a small mix of platforms, it becomes usually quite trivial to port to others. My Ostiary program runs on (at least) Linux, *BSD, OSX, Solaris, HP-UX, AIX, Tru64, IRIX, and Cygwin. I've written commercial code that runs on all of those plus Windows, NetWare, and OpenVMS, though that requires a few more #ifdefs.
PHEM - party like it's 1997-2003!
are done w/ J2SE using SWT as the front end. Looks like a native app, runs super fast since it relies on native widgets, and portability issues are largely mitigated for me.
Then device drivers and operating systems were going to let us abstract away the details of the underlying implementation of the hardware, letting us write portable code. But not all O/S versions are compatible; there are glibc issues under Linux, and so on.
Then JAVA was going to be completely portable to all operating systems. But not all Java virtual machines are identical, and different version of Java came out, and things diverged.
All of these things made life more portable, to some degree. All of them still require boostrapping a system that understands the underlying hardware and deals with it efficiently; then abstracts all that hardware specific efficiency away again.
Portability is *hard*: in some sense, it's the enemy of efficiency. You need to abstract away all those nice hardware specifics that make the hardware work, and replace them with a theoretical construct that caters to the lowest common denominator that you're willing to support.
What's worse, as soon as someone makes a different design decision, or an improvement, or something that isn't universally adopted all at once, you have multiple versions -- divergent standards which aren't completely compatible. It happened with UNIX; it's happening with Linux (to a lesser extent, because code can merge again after a fork), and it happened with C and Java.
What can the developer do? Just our best; true universal portability is a Holy Grail that we'll never attain, because the day we do, someone will invent a radical new system that doesn't quite fit our abstraction model...
I've written production code in C, C++, Objective-C, Lisp, Pascal, many different scripting languages, and Java. Bar none, if you want to write something portable, Java is the language to use. It has the incredibly complete and mature libraries, performance is excellent, tool support with IDE's and app servers and source repositories is fabulous, and it is designed to be cross platform! Games, huge transactional systems, office apps, and utilities are all appropriate types of applications to build on Java. I've started to do scripting on FreeBSD with Java. I'll admit, it's hard to write a useful bit of Java that is less than about 10 lines of code, particularly for text processing. But that is probably the only place it is lacking. The one other place one might consider using something else is in Dynamic Client-Side Web Apps (AJAX stuff). Other than that, I always groan when people talk about using other languages for cross-platform development.
Helping with organizational effectiveness is our job.
If the task is well defined, a small, tightly defined app tied very closely to the target API has a better chance of performing well with fewer bugs as you can spend the portability-effort in testing.
I abstract math and models to generic C++. I tie the rest as tightly as possible to the target API and focus on being fast and bug free. In my career so far, the only code I have ever ported for business reasons ($$) has been mathmatical algorithm related.
YMMV.
..don't panic
That's right, you heard me. Don't write portable code.
Use portable libraries and languages; re-factor your working code to be portable; make high-level choices that support portability (e.g. don't lock yourself in to proprietary solutions), but don't write portable code.
Why? Because premature portability, like premature optimization is a red herring that steals your attention from the only two things that will ever matter: correctness and maintainability. Write correct code. Write verifiably correct code. Write maintainable code. Do these things and you are done. Then, port it to another platform or ten and optimize the hell out of it. Don't do these things up-front, as they buy you nothing on the first pass, and doing them later will give you the chance to re-consider the structure of your system which you should do at least twice before your first release anyway.
That said, do not snub portability unduely. If you have the choice of trivially supporting or not supporting portability-enhacing features (e.g. in your choice of a configure/build system), there's no reason not to be portable. Just don't let it set priorities for your project from day one.
2) Only if it is programmed that way... a developer can force a specific Look and Feel.
3) If by forever you mean 4) Again, only if it is programmed that way.
5) From a purist perspective, I'll grant you this one. But from a practical perspective, it's just not a big deal. Lots of JVM's out there, source code is available (although it's not Free).
Helping with organizational effectiveness is our job.
> Good Java programmers... use Python instead.
Votez ecolo : Chiez dans l'urne !