Standard Libraries Dont Make For Portability

Moved from IssuesAndProblemsWithLisp.

Lisp has poor support for I/O, networking, etc; this is why JavaLanguage has done so well.

Despite the size of the language, LispLanguage is missing support (in the language standard) for several key domain-independent concerns. Networking. ConcurrentProgramming. Graphics. One can get hold of external libraries and the like to do all of these things, but having these standardized is highly beneficial.

Does Java have good cross-platform support?

Many believe that the reason Java/C# are displacing C/C++ in the enterprise is due to a nicer programming model - GarbageCollection, no PointerArithmetic, etc. Probably true; but a point just as important, and often overlooked, is that it is impossible to write non-trivial applications in C/C++ without using some non-standard or non-portable feature or library. Some things, like networking and advanced I/O, are reasonably standardized in the C/C++ world despite being absent from the standard library; but many things are highly vendor-specific. This is a problem that Java solves very well - a Java app will run equally poorly on any machine. :)

The merits of WriteOnceRunAnywhere

I think the WriteOnceRunAnywhere line is a load of crap. You simply can't standardize everything since different operating systems do things differently. Apps should be written for the platform they intend to run on, Java's not lived up to write once run anywhere, and neither will any other language.

While SunMicrosystems has long oversold the WriteOnceRunAnywhere capabilities of Java (as mentioned above, Java portability isn't perfect), as well as the OneHundredPercentPureJava? stuff; Java does achieve a higher degree of portability than many other languages. And if you claim that in some cases (graphics again), portability comes at a price - you need to use a LowestCommonDenominator solution, you'd be right. (And thread semantics are a known and nasty problem)

However, there are many Java applets and applications that do run happily on multiple pieces of hardware with differing CPUs and OS's, without changing so much as a byte of the ByteCode. Many of them are butt-UgLy, but they do work. I use one such applet on a regular basis to fill in my timecard at work.

Portability, like anything else, should depend on the customer requirements. If the customer only wants something that runs on Windows, go ahead and use all the tricks in the MS-specific bag. If the customer wants it to run on every machine in his network, however, you should architect accordingly.

And just because the portability of Java (or anything else) isn't 100% perfect; doesn't mean we should abandon attempts to be portable. Where portability is important, code that is 99% portable is far better than code that is 50% or 20% or 0% portable.

See also WriteOnceRunMaybe for on the portability (real or imagined) of Java vs C++


Why haven't I seen many applications on Mac OS X (which is supposed to have good Java GUI integration), that make me want to use a portable Java application??? You get what you deserve - a crappy user interface on top of a foreign infrastructure.

People thing Gnome and KDE are standard. Well, maybe on Linux or some Unix. On my Windows NT machine at work, they are not.

Since no programming language comes with a GUI standard that you would call standard, this discussion is pretty stupid anyway. SunMicrosystems tried to define far reaching standard libraries and a computing environment for Java. You see where they ended: buggy, complicated, sometimes useless without referring to implementation dependent stuff, ugly for the user, etc. And companies put several billion dollars into these libraries. Yet would you want to write your next office suite in Java? We know the history. People tried. And failed. Would you write your next development environment with the "standard" GUI library for Java? People have tried. Looked ugly, was slow and behaved funny. The result: the most popular development environment for Java uses JavaSwt - since it uses more native windowing stuff. Ah, yes.

Graphics and similar things don't have any place for standard for the programming language (Common) Lisp.

Ha, and they have tried. You can bet. Several attempts of a standard GUI library have been made. Some died early.

If you, for example, buy LispWorks (yeah, choose a Lisp implementation), you have standards for networking, database access and gui stuff for several platforms (Linux, Unix, Mac OS X, Windows). It is just that nobody agrees on these (or competing portable libraries or APIs.

But, now you WANT to develop in Common Lisp - what would you do?

a) Just choose one implementation which provides cross platform libraries (like Allegro CL from Franz Inc. or LispWorks from LispWorks Inc.). Stay with it and be happy. Applications written with Allegro CL and LispWorks run almost unchanged on Mac OS X, Unix, Linux and Windows (with the exception of the different GUI stuff in Allegro CL).

b) Use a portable library. Several are available for various areas. When Lisp was more in fashion, companies sold commercial cross-platform libraries - also for moving software from development systems (Lisp Machine) to deployment platforms (Lucid CL for example).

c) Write/assemble your own portability layer. Several applications did that. Some applications have demonstrated that you can move large Lisp applications (like > 500klocs) from one Lisp implementation to another in a reasonable amount of time. For these applications, a 50 kloc portable layer is maybe just 10% of the whole source.

d) Write your software with exquisite factoring (hint: use TDD!), relegate platform-specific code to platform-specific libraries, and move on with life. This technique is used extensively in the Forth community to great effect (porting ANSI Forth programs to non-ANSI systems, and vice versa, are usually very simple tasks). And, you wanna know something? It works in C too. And Pascal. And ... --SamuelFalvo? :-)

For example, people have been able to write web servers in Lisp (like CL-HTTP and (Portable) Allegroserve) that can run on multiple operating systems and Lisp systems. So, it is possible to write portable applications in Lisp. You just have to do it, which would mean less talk and more code - possibly even hard work. Most people like to talk and speculate, and many of them talk of stuff they have heard or would suspect that it could be in theory. With less FUD, more would be get done.

But if you look at CL-HTTP source code, you can see lots of conditionally compiled code (similar to #ifdef) which just have to deal with different kind of lisp. What I think is having those support (GUI, networking, Thread) library standardized will encourage opensource community to join the language. (Why would I write opensource HTTP server if it will run only on commercial LispWorks? Or it could run on other Lisp implementation but then I would be having the burden of keeping implementation differences instead of at least get standardized Thread and Socket library like java does?)

A language with a very small standard library is not open source friendly at all...


1. JavaSwing doesn't have to be SUN's swing does it? If say Sun's implementation's ugly... One can come up with same API interface but nicer implementation. Don't know why JavaSwt isn't doing this way. If I want SWT performance and look. Why can't it be put in like endorsed standard or something?

Because Swing makes some assumptions about the underlying system that involve overhead. Specifically, SWT requires each widget to have a parent, and AFAIK doesn't use much in-JVM storage of attributes (i.e., everything is stored in the native widget).

2. For things like Collections, I/O, Networking... I still think it is nice to have Standard Library packaged with. Because once you know it, you know what other usually know. When people moved in to join the project. They can reduce the time to go in and explore standard library.

3. You say if you want standard library, just choose to buy one from vendor. Then isn't it better that this library (Collection, networking) comes for free? If you say no because some library is not good enough, then you can buy only that library from third party. Reduce the cost of the company.

And just because libraries are available from a vendor doesn't make them standard. It's about more than cost of software, to use a makretroid term it's about TotalCostOfOwnership - if you hire new people they will (should?) already know the standard libraries, they are much less likely to know the API of some library that you purchased from a 3rd-party vendor.

4. You said standard library is not purely portable, But is buying from Third-party vendor more portable? Compare the user base of standard library to one single Library.


To me, the benefit of a standard library is that it's there, and every one knows it. And that draws people together more easily.

Take Java as an example; Swing is not that good (as you all said) but I like it. When I was a 12 grade student with no money, Swing is great!!! It's the first GUI I ever create.

Then I tried to learn lisp and then... No Free GUI on Windows. Many lispers will suggest I use CLIM on Linux or buy that 1000$ LispWorks. No, I am not that rich!!! (I have a job now, but not every single programmer in the world can afford to buy those, based on his salary).

Java has got lots of people to join the open source community, why?? One reason is because it's easier to write portable code in Java than in Lisp. (In lisp, even just to connect to the socket, you got all those #+clisp and #-clisp all over place).

Then you haven't factored your code correctly. Refactor, so that your core code is clean, and your platform-specific code is tucked away neatly in platform-specific files. --SamuelFalvo?


"This is a myth. The team I work with has developed a large application in Java using WebLogic 7 and JDO/Kodo. Don't even think that it will run on the next J2EE application server without serious trouble. -- Anon"

That doesn't make a myth. The team I work with (and the two before that) developed applications in Java using the J2EE spec. They run on WebLogic, WebSphere, Oracle 9i and other J2EE compliant app servers. I've written big, non-trivial, portable Java apps and it's much easier than it was with C or C++. Just because you can write an app that only runs on WebLogic 7 doesn't mean you can't also write a portable app. -- EricHodges


Pet Peeve: RubyLanguage (my favorite) has a perfectly good Pathname class, which bottles up the endless join and abspath and mkdir nonsense into an object that behaves like a string. Hours of fun, and clean code results.

PythonLanguage, however, is the language that pays my bills. And it is unaware of the rule "StandardLibrariesDontMakeForPortability". So it has no matching Pathname class. Instead, it has the usual fan-out of methods, such as os.path.join, os.path.abspath, os.mkdir, etc. The Official Reason is because "such a class would not be perfectly portable," which is specious, because such a class would be just as portable as the os.path module itself is. >elaborate sigh< --PhlIp

EditText of this page (last edited March 13, 2013) or FindPage with title or text search