Lambda the Ultimate

It's unclear from the executable size table what, if any, other DLLs and such are required by an installation. That is, if your app is 100K but depends on a 10M DLL you must bring along...

Also, I see that it connects to COM, but what about calls to Win32 native APIs, invoking C/C++ code in DLLs via exports, etc. Features such as these are critical for me as we rarely, if ever, start apps from total scratch.

The worry with using languages like this is that they're heavily Wintel-centric. Even old tools like Delphi won't generate code for the various processors Windows CE runs on.

the Smalltalk category for executable size
console hello world = 53.5 KB

what if any, other DLLs and such are required
STMT5 runtime = 52.2 KB

If you want to use OLE or DirectX or GDI+ or... then you'll need to distribute some more dlls.

what about calls to Win32 native APIs
STMT has direct access to Win32 APIs.
FileStream>>close is implemented as

   WINAPI CloseHandle: m_hFile.
m_hFile := 0

When you don't need Win32 apis, you've gotta love those crazy functional languages ;-)
[Clean console hello world = 31,744 bytes, no runtime; VC = 32,768 bytes]

I have no direct experience but I'm interested to know more about GCJ and SWT on Windows and other platforms. Supposedly works.

Since SWT is open and AWT/Swing is proprietary, this would seem to be the trend to bet on for the best GCJ support.

Register me as one that thinks VB should be abandoned. VB3 thru VB6 are dead languages that won't be supported for much longer. Why start a project designed to upgrade your tool set that is outdated even before the first line of code is written? VB.net is a supported language but it's effectively a new language. If you're gonna expend the energy learning a new language and a whole new set of API's, use C#. Programming for .Net is much easier and more natural in C# than in VB.

Since the author says that speed is not an important component, I'd forget anything and everything about C or C++ (and yes they are two totally different languages). These languages have their uses, but rapid application development is not one of them.

Delphi is a great choice, though I never seem to be able to get the time or resource commitment to pursue that particular path.

When I do have a choice these days, I generally choose Python. It's a nice powerful scripting language that plays with others about as well as can be done (e.g. COM & JVM). But then, the author needs to be a little more specific about what they mean when stating "shrinkwrap". What is it about the project that makes VB, Delphi, & VC++ seem to be the only valid languages? RAD? GUI? COM? Compiled? Packaging & Distribution? </language>

Packaging & Distribution are certainly very important considerations, especially for shrink-wrapped software, especially if it is also distributed over the web. Download size still matters, even in this age of broadband.

Also, installing VMs is usually more demanding than installing a standard app. And the installation processes for the VM is out of your hands.

So, what would be the download size for a Python app if I can assume nothing about the target machine? What would be the installation requirements? Will it work if the user has Windows 95 or 98?

My current feelings are that anything beyond dropping an exe file and a couple of DLLs into a directory, and maybe also registering a COM component or two, is too complex. Oh, and ideally the user shouldn't have to reboot.

The tools situation is pretty sad! TC++/Win in 1991 provided better GUI C++ programming support than gcc + gtkmm does today. With a Tower of Babel like stack of separately maintained libraries and tools, a paucity of documentation and constant gtk vs. gtk2 confusion - I'm now on 8 different mailing lists and learning to debug autoconf/automake tools just to get past a Gtkmm hello, world app.

What's worse, back in the early 90's there seemed to be reasonable support for Modula-3 and Sather and like languages - system programming languages with gc runtime support. Well, after a few weeks of surfing, I found few gc languages with actively maintained Gtk/Gnome support. It's kind of depressing. I was hoping to use a Lisp or Scheme language, but even Guile/Gtk is something of a mess (I'm on that mailing list too :-) The CMUCL folks seem to have different priorities than "mainstream" Linux desktop application programming.

I've settled on gcc and gtkmm and Python + WxWindows for now. Python is a nice language for many tasks and the documentation is pretty darn good. wxWindows binds to Gtk on Linux and has a very nice API. gcc + gtkmm/gnomemm is pretty much a "by default" choice - if you can call it that.

I'm amazed that there doesn't seem to be a "market" for a type safe, gc supporting but natively compiling systems language/implementation. I really am amazed.

Another option is S# (nee SmallScript http://www.smallscript.net). The executables this system generates are very, very small (3K for hello world) and are blazingly fast. The S# for .NET preview is currently in testing with a small group and will likely be available in the near future.

For cross platform stuff your choices are a bit more limited. I don't have any recommendations in that area based on experience. Maybe one of the cross platform Smalltalks is suitable.

Ditto, especially one with module support, and not the Fortran-like separate compilation still used by C++. I've also been amazed that GUI building tools have been so bad, with the exception of Visual Basic and Delphi. As much as I hate to admit it, both of these voids are being addressed with C# and .net. To a great extent, the C#/.net is how desktop programming in the 1990s should have been, if it hadn't been derailed in various ways.

(I'm answering two different threads at once here, I guess - one person is objecting to Java and one to no GUI support on clients).

Sun also just released a new version of the virtual machine which is only a 2M download, which is ideal for users with very slow connections (i.e. 56K or slower). You also have the option of using a native compiler like JET, which compiles Java applications down to a native executable. The consensus seems to be that native compilers don't increase execution speeds, but that they do reduce application startup times and disk size.

If you need special integration with Windows, there are several free and commercial COM bridges, and you can always use JNI (Now I can plug Jace - http://jace.reyelts.com/jace). There is also at least one commercial Java-.NET bridge. Not surprising, considering how similar they are.

About the only drawback I can think of, is that Sun may be withdrawing support for Win95 in their latest virtual machines. What can you expect when even Microsoft doesn't support it?

<http://www.drscheme.org>;?

Scott: I'm amazed that there doesn't seem to be a "market" for a type safe, gc supporting but natively compiling systems language/implementation. I really am amazed.

<http://www.ocaml.org>;?

http://www.mlton.org/ x86 SML compiler

http://smarteiffel.loria.fr/ Eiffel to C compiler

http://www.object-tools.com/products/ve/ x86 Eiffel compiler, closed source but free on Linux

Eiffel to C compiler

I would probably never consider a PL that is implemented in this way because it generally means that there is no debugger support. I know some PLs need to be debugged a lot less than others, and that debugging in itself can be evil, but I like to have a debugger handy just in case.

Other factors include a good IDE, a large collection of existing libraries and frameworks and the ability to integrate with existing C/C++ code (that is, handle C calling convention). Multi-platform support is also a GOOD THING.

Obviously no PL is best at everything, and I've seen lots of interesting suggestions in this thread that I will check out. I also hope that it came across that creating a great dev-env, especially for the client-side, requires a lot more than good PL design (and why so may people are still using C++ or VB (or both) for this type of work).

The library support isn't quite as good as, say, Java or Delphi, but it does have XML and HTTP for network apps, Tk and Gtk for UIs, and a full FFI interface for calling C libraries, along with the usual FP datastructure implementations. Plus, the bundled parser and DSL tools are top-notch, which is great for end-user customization and scripting.

I haven't used any of these, but maybe http://www.cliki.net/Java helps. You might also want to check out Jabberwocky which is a CL IDE written in Java.