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.

• Oh - C [ObjectiveCee?], AdaLanguage, CeePlusPlus, JavaLanguage, etc., have standardized graphics - zero, one, or more? Why does EclipseIde use the JavaSwt when it is not standard? Most of these so-called standards are a joke when it comes to cross-platform application development - sorry.

• C/C++; no. Ada isn't important for the problem domains where standardized graphics are important. Java comes the closest, and while Swing certainly isn't the greatest, it's a start.

• I don't use Eclipse, but as for "why SWT", I found the explanation on these two pages satisfactory: http://www.eclipse.org/documentation/html/plugins/org.eclipse.platform.doc.isv/doc/guide/swt.htm http://www.eclipse.org/eclipse/presentation/eclipse-slides.ppt (some ways into the slide show). I know, it was a rhetorical question, but I'd just finished reading these pages. :-)

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. :)

• 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. Even if you try to avoid the lock-in into some specific application server (WebLogic) or persistence library (JDO), you will not create an application that runs automatically on other Java systems. Far from it. Welcome to the real world.

• What? I have major problems with C and C++, but I have also used them extensively and shipped a lot of product with each, and typically we didn't use middleware or other 3rd party stuff nor depend on non-standard compiler features. I think your claim is just flat out false. "Impossible"? No way. Try "it is common to use non-standard blah blah". And even then it'd be good to be a bit more specific about what you mean. Boost? Roguewave? GNU compiler extensions??? What?
  • What I meant was - it's difficult to write an application (especially one using graphics) which is portable (where "portable" here means "runs on Windows, Unix/Linux, perhaps Mac as well") without using non-standard libraries of some sort (where "non-standard" means any library that is neither the standard library itself, nor implementable exclusively in terms of the standard library). Vendor- or OS-specific libraries are "non-standard" in this context, though many of them (much of POSIX, the Berkeley sockets API, etc.) are sufficiently ubiquitous that they can be considered "standard". Virtually anything having to with graphics in C/C++ is non-standard, under this definition. Now there are many toolkits to abstract away platform differences. Too many of them, in fact (the Gnome stuff, the KDE stuff, parts of RogueWave, the ACE library, take your pick); the number of such competing implementations can be a pain; in particular when you are staffing a team and/or when you have to integrate components using different such libraries. Compare this state of affairs with Java, where the standard library abstracts far more areas of concern - worries about "is this for Win32 or X or whatever" go away. This I am claiming as an advantage (one often overlooked in discussions such as these) for Java (in many of its most common uses) - the same program will execute without modification on whatever machine you like - within reason. I'm not discussing compiler/ language extensions here (though those get used quite a bit as well; "long long" is a popular extension though still not ANSI-compliant C++). Of course, there isn't anything necessarily wrong with using non-standard libraries in C/C++ - I do so all the time as well. However, writing portable C/C++ code is frequently hard work. Given the number of enterprises with heterogeneous computing environments (Windows on the desktop, Solaris in the data center, Linux in other server applications, and maybe a few Macs as well), coupled with the ease that Java code can be deployed throughout the enterprise, it's no surprise that Java has gained a strong foothold there. (Java's portability isn't perfect, of course - and comes at a price).

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 project with many standard parts draws people in easier. That also tells about why Java is so popular compared to lisp. Imagine someone wants to use an open source library in their project. Which one is a better statement?
  • Java Project: It's not tested on your platform yet? Then try using it? Looks at source code. You will be able to understand most of them since the standard library works the same way on all implementations (mostly).
  • Lisp Project: What? you wanna use lisp? Which implementation do you use? CLISP? Hmm... we haven't ported to CLISP yet. You can choose to buy 3000$ LispWorks and use our FREE library or try looking at our code and port it. But then again, have fun mapping LispWorks API to CLISP.

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

• When Python and Perl hit the scene, they didn't have a large standard library. Yet, somehow, they accreted code to form them. Lisp has a massively huge standard library in contrast. By your logic, Lisp should have hordes of coders for it, and yet, it appears as though the reverse has happened. I think what it boils down to is, you need to let the "free market" of the noosphere take its course; standards come about because everyone uses them, not because they're imposed by some high-up, ivory-tower standards agency. --SamuelFalvo?

---

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