I'm creating several FREE software project, expanding greatly on the types of code present on my web site (http://www.coyotegulch.com). The projects will focus on algorithms and applications for cellular automata, evolutionary computation, and astronomy.
My one remaining question: What programming language should I use?
I hope you who read this will have some insights for me. I've been out of academia for a while, and I'm not very familiar with the types of computers used overseas, or the current preferences in programming languages outside commercial software development. Were I only interested in performance and "market", I'd write a C++ Windows application and be done with it. However, I want this code to be accessible to any programmer, amateur or professional, from PDAs to Beowulf clusters. And I want non-programmers to be able to use the programs with a minimum of fuss.
So my foremost concern is cross-platform portability, which leads me to consider Java. I have various GNU-Linux and Wintel systems for development, but I'd like to see these projects run almost anywhere. Java is also appealing due to its support for a portable graphical user interface.
Java is not without its difficulties, however. To begin with, Java requires a significant piece of hardware to run sophisticated applications; Java can also be slow, especially on platforms where the Java Virtual Machine (JVM) is poorly-implemented. Not every computer comes with a JVM, and installing a Java run-time can be frustrating for non-programmers.
By profession, I'm a nuts-and-bolts, algorithms-and-API programmer who works primarily in C++ and C. Beyond C++ and Java, I've developed code in everything from COBOL and FORTRAN to Prolog and Modula-2. For most work, however, I choose C++ because it is (when written carefully) portable, efficient, and extremely flexible.
While C++ would be my first choice for these projects, some of the software requires a graphical user interface. I don't really want to spend the time to learn GTK or Qt or some other compiled portable GUI -- and I want to distribute complete source code for my projects.
So where does that leave me?
With Java, I think. The goal of my project is to demonstrate algorithms to the widest possible audience -- and only Java gives me that capability.
How wide-spread is Java in the astronomy community, for example? If I produce a cellular automata application in Java, will it be useful? Do people have "big-enough" machines to run Java? I just don't know the answers to those questions, and I haven't found the answers on the net.
I'll appreciate considered opinions; no religious diatribes, please.
I agree that C++ and Java are your only best choices. Just over one year ago I stopped all of my C++ MFC development and switched to 100% Java. Though I loved C++, I like Java just as well, but for slightly different reasons. Swing, the standard libraries, not having cross-platform problems, not needing tools like GTK or MFC. Swing UIs are incredibly slow compared to Windows MFC UIs, but the cross-platform, ease of modifying behavior, object oriented nature of Swing is wonderful. Non UI code performance is quite good.
Recommend: IDE - Net Beans and Forte (Sun's version of Net Beans) - 100% Java, open source Web Server - Jetty 3.0.3 - 100% Java, open source Database - HypersonicSQL - 100% Java, open source XML parser - Crimson (Sun, Apache) All the stuff from Apache.org
Scott Robert Ladd wrote: > While C++ would be my first choice for these projects, some of the > software > requires a graphical user interface. I don't really want to spend the > time > to learn GTK or Qt or some other compiled portable GUI -- and I want > to > distribute complete source code for my projects.
> So where does that leave me?
Well, with Java you're going to have to learn a GUI API as well.
-- Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/ __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE / \ History is a bucket of ashes. \__/ Carl Sandburg REALpolitik / http://www.realpolitik.com/ Get your own customized newsfeed online in realtime ... for free!
> Well, with Java you're going to have to learn a GUI API as well.
Ah, but I already *know* the Java GUI API and the Windows API, whereas I would need to *learn* a Unix GUI to port C++ applications. I suppose I could write code directly for X-Windows, but that isn't terribly effective in my experience. And picking between Motif, KDE, Gnome, and all the other Unix GUIs is an annoying prospect...
What *do* scientific types use as a standard Unix GUI, if any?
Your original post never showed on my news server, so if this is something mentioned already please forgive me.
Have you considered using JNI, the Java Native Interface? This should let you program UI in Java while at the same time being able to code (or maintain legacy code) in C/C++.
George
On Mon, 05 Mar 2001 00:44:15 GMT, "Scott Robert Ladd"
<sc...@coyotegulch.com> wrote: >"Erik Max Francis" <m...@alcyone.com> wrote... >> Well, with Java you're going to have to learn a GUI API as well.
>Ah, but I already *know* the Java GUI API and the Windows API, whereas I >would need to *learn* a Unix GUI to port C++ applications. I suppose I could >write code directly for X-Windows, but that isn't terribly effective in my >experience. And picking between Motif, KDE, Gnome, and all the other Unix >GUIs is an annoying prospect...
>What *do* scientific types use as a standard Unix GUI, if any?
> "Erik Max Francis" <m...@alcyone.com> wrote... > > Well, with Java you're going to have to learn a GUI API as well.
> Ah, but I already *know* the Java GUI API and the Windows API, whereas I > would need to *learn* a Unix GUI to port C++ applications. I suppose I could > write code directly for X-Windows, but that isn't terribly effective in my > experience. And picking between Motif, KDE, Gnome, and all the other Unix > GUIs is an annoying prospect...
> What *do* scientific types use as a standard Unix GUI, if any?
I never use a GUI for any of my GP, GA or NN simulations. They are always written in C, run in an xterm and print their progress to stdout and or a text file.
For my current project I hacked together a GUI visualisation server in Python/Tk. Multiple separate instances of the simulation connect to the GUI server using TCP/IP sockets. The separate instances can be run on a number of machines with their combined outputs showing up in one window.
Python/Tk has the big advantage of being reasonably portable across platforms and Python is definitely a leader in the field of scripting languages.
On my current project, the simulation code required some 50+ hours of coding while the GUI took about 10 hours over a couple of days. I consider that a pretty good distribution of programming resources.
Just my $0.02 worth, Erik -- ----------------------------------------------------------------- Erik de Castro Lopo nos...@mega-nerd.com (Yes its valid) ----------------------------------------------------------------- Beware the Lollipop of Mediocrity. Lick it once, and you suck forever.
David Holliday <dholli...@altaworks.com> wrote: > I agree that C++ and Java are your only best choices. Just over one > year ago I stopped all of my C++ MFC development and switched to 100% > Java. Though I loved C++, I like Java just as well, but for slightly > different reasons. Swing, the standard libraries, not having cross- > platform problems,
Of course you have no "cross-platform problems" since you only have one single platform to consider: the JVM. Yes, the JVM platform can be emulated on various other platforms, but so can Windows: there are emulators for Windows running on several different Unices, which will make your C++ MFC Windows programs "cross-platform" in a way similar to Java programs.
> not needing tools like GTK or MFC. Swing UIs are incredibly slow compared > to Windows MFC UIs,
On emulated Windows the speeds may be somewhat similar though.
-- ---------------------------------------------------------------- Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF) Grev Turegatan 40, S-114 38 Stockholm, SWEDEN e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se WWW: http://hotel04.ausys.se/pauschhttp://welcome.to/pausch
>> Well, with Java you're going to have to learn a GUI API as well.
> Ah, but I already *know* the Java GUI API and the Windows API, > whereas I would need to *learn* a Unix GUI to port C++ applications.
Didn't you once have to learn the Java GUI API and the Windows API too?
> I suppose I could write code directly for X-Windows, but that isn't > terribly effective in my experience.
If you want to do native code development, Java is out of the question anyway. But if it's OK to interpret code at runtime, Java isn't your only choice. You could also run a Windows emulator on your Unix platform, and then run your Windows API programs on that emulator. This will make your Windows API programs as much "cross platform" as your Java programs, and in the same way: by interpreting that one-and-only platform on other platforms.
> And picking between Motif, KDE, Gnome, and all the other Unix > GUIs is an annoying prospect...
Unless you have good reasons for some other choice, choose Motif since that's most often used. And if you do have good reasons for some other choice, that choice ought to be easy too...
> What *do* scientific types use as a standard Unix GUI, if any?
Scientific type do scientific programming, not GUI programming... :-) But seriously, if you stay with CLI's, then you'll probably end up with more time on your science.....
Also, even if scientific types dabble with GUI's, they're probably more concerned with solving their scientific problems than by making their personal hacks portable. So they'll probably just grab whatever GUI happens to be available on their system.
Finally, many scientific types don't program at all, or very little, instead they use software tools avaialbe for their field.
-- ---------------------------------------------------------------- Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF) Grev Turegatan 40, S-114 38 Stockholm, SWEDEN e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se WWW: http://hotel04.ausys.se/pauschhttp://welcome.to/pausch
> I never use a GUI for any of my GP, GA or NN simulations. They are > always written in C, run in an xterm and print their progress to > stdout and or a text file.
An evolving cellular automata doesn't really have much meaning without a visual representation... ;)
Otherwise, I usually follow the same pattern as you do: My GA/EC apps are simple console programs that report via stdout.
I hadn't really considered a Tk or Python solution; quite frankly, I've never used either under Windows, but I'm willing to bet that both are hosted in some fashion.
"Paul Schlyter" <pau...@saaf.se> wrote... > Didn't you once have to learn the Java GUI API and the Windows API > too?
And I'm tired of learning new GUIs... ;}
In theory, a Java GUI runs on any JVM; thus I learn one GUI, and the app runs on WIndows, X, and Mac without my having to understand a unique API for each platform.
In practice, Java is nowhere near as portable as its adherents wish us to think. My own applets have annoying GUI differences, just under various JVMs (MS, IBM, Sun) for Windows.
I suspect I'm looking for a Holy Grail here. I just don't want to maintain six code bases for different platforms, especially, when I'm distributing free code over the web...
> If you want to do native code development, Java is out of the > question anyway. But if it's OK to interpret code at runtime, Java > isn't your only choice. You could also run a Windows emulator on > your Unix platform, and then run your Windows API programs on that > emulator
In my experience, the Windows emulators are annoyingly incomplete, and they are much less likely to be installed than would a Java machine.
> Unless you have good reasons for some other choice, choose Motif > since that's most often used. And if you do have good reasons for > some other choice, that choice ought to be easy too...
I'm considering Motif. I've never *done* any Motif work, but hey -- if this job were easy, everybody would be doing it... ;)
> Scientific type do scientific programming, not GUI programming... :-)
Yes, yes, I know -- *BUT* some applications are best shown using a graphic display. We could write papers without charts and graphs, too, but text simply doesn't convey certain information clearly. I can't imagine how I'd describe a cellular automata, for example, in text.
On the other hand, my first "Life" program was written in FORTRAN and ran on a Univac 1110 with a DecWriter terminal, printing each generation as a block of dashes and stars. Now does that date me or what?
> But seriously, if you stay with CLI's, then you'll probably end up > with more time on your science.....
For some of the applications I probably will stay CLI with console output.
> Finally, many scientific types don't program at all, or very little, > instead they use software tools avaialbe for their field.
Quite true; what I'm hoping to distribute is a set of useful tools. The target audience has three components: scientific programmers who want to learn about evolutionary computation, scientists who need a set of drop-in tools, and the curious layman. I'll have some more details in a week or so.
Thanks for the comments; they been most interesting.
Scott Robert Ladd wrote: > I hadn't really considered a Tk or Python solution; quite frankly, > I've > never used either under Windows, but I'm willing to bet that both are > hosted > in some fashion.
Tk is quite portable, and has bindings for most languages. Python is useful because it's also quite portable, and is extremely easy to learn and use, but on the other hand is also quite powerful.
-- Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/ __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE / \ Love is the triumph of imagination over intelligence. \__/ H.L. Mencken Polly Wanna Cracka? / http://www.pollywannacracka.com/ The Internet resource for interracial relationships.
Paul Schlyter wrote: > Scientific type do scientific programming, not GUI programming... :-)
You forget that many of us scientific types have to perform "demos" in order to remain funded scientific types. :) There will be plenty of GUI work there.
> I hadn't really considered a Tk or Python solution; quite frankly, I've > never used either under Windows, but I'm willing to bet that both are hosted > in some fashion.
Well Python cose is compiled to byte code which is executed by a virtual machine. But the Python interpreter and the Tk windowing stuff all runs native.
Erik -- ----------------------------------------------------------------- Erik de Castro Lopo nos...@mega-nerd.com (Yes its valid) ----------------------------------------------------------------- The National Multiple Sclerosis Society of America recently started an advertising campaign with the slogan "MS: It's not a software company".
Seasoned IT professionals will have no trouble telling the two MS's apart. One is a debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. The other is a disease.
In article <zjBo6.241129$8V6.40316...@typhoon.tampabay.rr.com>, "Scott Robert Ladd" <sc...@coyotegulch.com> writes:
> "Erik Max Francis" <m...@alcyone.com> wrote... >> Well, with Java you're going to have to learn a GUI API as well.
> Ah, but I already *know* the Java GUI API and the Windows API, whereas I > would need to *learn* a Unix GUI to port C++ applications. I suppose I could > write code directly for X-Windows, but that isn't terribly effective in my > experience. And picking between Motif, KDE, Gnome, and all the other Unix > GUIs is an annoying prospect...
Well, Gtk is at least available on both X11 and windows. If you dare to be unconventional I'd recommend the (IMHO) excellent programming language Ada. And there is also a very good binding to Gtk for Ada, GtkAda.
Best Regards
Anders -- -------------------------------------------- "A well-written program is its own heaven; a poorly-written program is its own hell." - The Tao of Programming
When JPython came out it was reputed to be faster than the "native" alternative (presumably due to running on a more developed VM). I don't know if this is still true.
I understand Python has virtues over Java in a number of areas - but somehow, I doubt writing CAs is one of those areas. -- __________ |im |yler t...@cryogen.com Home page: http://alife.co.uk/tim/
> In article <ta53ts25ii...@corp.supernews.com>, > David Holliday <dholli...@altaworks.com> wrote:
> > I agree that C++ and Java are your only best choices. Just over one > > year ago I stopped all of my C++ MFC development and switched to 100% > > Java. Though I loved C++, I like Java just as well, but for slightly > > different reasons. Swing, the standard libraries, not having cross- > > platform problems,
> Of course you have no "cross-platform problems" since you only have > one single platform to consider: the JVM. Yes, the JVM platform can > be emulated on various other platforms, but so can Windows: there are > emulators for Windows running on several different Unices, which will > make your C++ MFC Windows programs "cross-platform" in a way similar > to Java programs.
We are reaching here, aren't we? It isn't like Microsoft is shipping a "Windows VM" for various platforms, and providing certification tests for third party "Windows VM" implementations....
Yes, one can emulate a platform across other platforms, but from a pragmatic point of view, such observations are useless if the vendor of the propritary platform doesn't care to support such cross platform efforts. Of course, even Sun has not been all that impressive in its cross platform efforts.
> > not needing tools like GTK or MFC. Swing UIs are incredibly slow compared > > to Windows MFC UIs,
> On emulated Windows the speeds may be somewhat similar though.
Nah, a good Windows imlementation should have much better performance. The JVM suffers from a hoplessly muddled execution model. Stack frames for procedure calls, and zero operand instructions. There just isn't a good way to compile it or make a processor to execute it. At least Intel assembly has a consistant execution model that quite a number of processors have successfully emulated, often with better performance than Intel's native implementation.
> -- > ---------------------------------------------------------------- > Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF) > Grev Turegatan 40, S-114 38 Stockholm, SWEDEN > e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se > WWW: http://hotel04.ausys.se/pauschhttp://welcome.to/pausch
> When JPython came out it was reputed to be faster than the "native" > alternative (presumably due to running on a more developed VM). > I don't know if this is still true.
> I understand Python has virtues over Java in a number of areas - but > somehow, I doubt writing CAs is one of those areas. > --
I don't know much about python about python but writing anything about CAs in Tk is _definitely_ NOT a good idea. I mean this kind of scripting language are handy and quick but unappropriate (to say the least) to handle structures like CA grid efficiently.
mathieu capcarrere wrote: > I don't know much about python about python but writing > anything about CAs in Tk is _definitely_ NOT a good idea. > I mean this kind of scripting language are handy and quick > but unappropriate (to say the least) to handle structures > like CA grid efficiently.
You meant Tcl, not Tk. Tcl is the scripting language; Tk is the GUI binding.
-- Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/ __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE / \ It is not enough to succeed; others must fail. \__/ Gore Vidal The laws list / http://www.alcyone.com/max/physics/laws/ Laws, rules, principles, effects, paradoxes, etc. in physics.
And tcl the language is perfectly appropriate for writing good CA software when used in the spirit in which it was created. tcl wasn't intended to be a stand-alone language appropriate for heavy algorithm development. Instead it provides support for loading DLLs generated from C/C++ code. Packaging CA extensions to tcl in a DLL created from C/C++ code is definitely a correct way to go if you like tcl.
George
On Tue, 06 Mar 2001 08:50:06 -0800, Erik Max Francis <m...@alcyone.com> wrote:
>> I don't know much about python about python but writing >> anything about CAs in Tk is _definitely_ NOT a good idea. >> I mean this kind of scripting language are handy and quick >> but unappropriate (to say the least) to handle structures >> like CA grid efficiently.
>You meant Tcl, not Tk. Tcl is the scripting language; Tk is the GUI >binding.
Personally I think Perl is also a good candidate in some situations. I have nice experience with Perl when writing an evolutionary neural network program which learns to classify texts. It even support Object Oriented programming.
"George Maydwell" <geo...@collidoscope.com> wrote in message
> And tcl the language is perfectly appropriate for writing good CA > software when used in the spirit in which it was created. tcl wasn't > intended to be a stand-alone language appropriate for heavy algorithm > development. Instead it provides support for loading DLLs generated > from C/C++ code. Packaging CA extensions to tcl in a DLL created from > C/C++ code is definitely a correct way to go if you like tcl.
> George
> On Tue, 06 Mar 2001 08:50:06 -0800, Erik Max Francis <m...@alcyone.com> > wrote:
> >mathieu capcarrere wrote:
> >> I don't know much about python about python but writing > >> anything about CAs in Tk is _definitely_ NOT a good idea. > >> I mean this kind of scripting language are handy and quick > >> but unappropriate (to say the least) to handle structures > >> like CA grid efficiently.
> >You meant Tcl, not Tk. Tcl is the scripting language; Tk is the GUI > >binding.
Lin Gu wrote: > Personally I think Perl is also a good candidate in some situations. I > have > nice experience with Perl when writing an evolutionary neural network > program which learns to classify texts. It even support Object > Oriented > programming.
> > Personally I think Perl is also a good candidate in some situations. I > > have > > nice experience with Perl when writing an evolutionary neural network > > program which learns to classify texts. It even support Object > > Oriented > > programming.
> Barely, if you don't mind squinting.
No, OO Perl is not all that different from OO C++. Perl doesn't have to be cryptic. I wrote a database-driven website for my family entirely in OO Perl: http://www.mwilden.com/familydex/.
Mark Wilden wrote: > No, OO Perl is not all that different from OO C++. Perl doesn't have > to be > cryptic.
Anyone familiar with object orientation can clearly see a mile away that Perl's object oriented facilities were tacked on on the end as an afterthought. Perl's object orientation is an embarassment.
-- Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/ __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE / \ They have rights who dare defend them. \__/ Roger Baldwin Official Omega page / http://www.alcyone.com/max/projects/omega/ The official distribution page for the popular Roguelike, Omega.
|
