Re: How to develop for Linux


"Paul Nichols [TeamB]" <paul@xxxxxxxx> wrote:
If you are running some of Desktop applets, you are running
Java written apps. If you are running Gnome, I am almost >willing to bet you are running apps written in Java, though
you are probably totally unaware of it, since they were >written using the Java language but compiled with gcj, and are
therefore natively compiled.

I'm using KDE. OpenOffice can use Java, but is written in C++, and doesn't start a JVM for normal tasks. It is an extremely slow application and shows C++ isn't everything either. As soon as Koffice becomes a realistic option, I'll dump OpenOffice.

Daniël Mantione wrote:
"Paul Nichols [TeamB]" <paul@xxxxxxxx> wrote:
No Delphi nor C++ app is going to
run as fast as the same app written with the same attention to detail,
than an app which is written in C and assembly.

There is some serious problem with your attitude against Pascal. There is, obviously, no reason why Pascal is slower than C (in theory Pascal could be faster, because the compiler has more information). Our goal is none other than to beat C in Shootout.

The language has nothing to do with it. I do not care if it is Perl,
Python, C, Java, Pascal, Wirth, Algol, Smalltalk, Simula, etc. The
compiler algorithms and of course the proximity to the hardware core
instructions are what ultimately produces the tightest and therefore the
most optimized code for the instruction set/processor/hardware that the
instructions are running against. Whatever the language, it is
ultimately compiled and ceases to be what it was in source form.

The facts, as they exist today, is that C and Assembly produce the
fastest and tightest code, due to the fact that the languages support
better compiler options due to their structures. That is pretty much
indisputable, if you take into account independent benchmarks from
independent sources across a variety of platforms and hardware
configurations. That is why the vast majority of Operating systems are
written with these languages.

Using well known and established facts does not disparage other
languages. Most of my work today is done in Java. I do not attempt to
compare the speed of Java to C and Assembly as far as optimized
instructions go. If I want to compare what I can produce in Java in
comparison to what I can produce in C and Assembly in time of
development, however, Java will be multiples quicker in time of
development, though the finished product will be somewhat slower in
terms of human experience. Clock cycle wise, it will be much slower, but
are clock cycles really that important? In some applications, the answer
may be "Yes", while in others, the answer is "no". That was and is my point.

If speed is all that matters (which seems to be the point some were
attempting to make), then the only applications we should be creating,
would all be written in C and Assembly, since all reputable sources
report that these compilers produce the fastest code. That was and is
the only point I was making. The rhetorical question was, since Assembly
and C are the fastest, then why are not all applications written in
these two and only these two languages? Since it is obvious that all
applications are not written in these two languages(not by a long shot),
then there must be other considerations at work. And of course, there are.

The dominance of C/C++ on Linux is overwhelming. So yes, all applications in use are written in one of these languages, be it close to 100% C/C++ and 0% assembler, the latter one disliked in the Open Source world because of its portability problems.

Now, the reason is not that their raw performance is better. In fact, it doesn't count much for desktop applications. For desktop applications startup time, memory usage, and UI responsiveness is what counts. As of yet, no one has seriously contested these advantages of C, which explains its dominance. This is why the position of C is IMHO best attacked with a more powerfull language which shares all of these properties with C.

What are the other considerations? Well time of delivery is one.
Difficulty of mastery of these languages is another. Task assessment is
another, Skill of development teams, yet another. Scope of assignment,
another. And the list goes on.,

Some languages and platforms are better suited for certain tasks and
applications, than others. Not all apps have to be super fast. Not all
applications have to be be careful to use memory in the most cost
effective manner. The means must justify the desired result. And that
was all I was attempting to say.

This is very right. The software world is a Darwinian process, so the question is wether the tool allows you to write applications that survive in this Darwinian process. If you can write a better application with a certain tool, that gives your application a higher chance of surviving. If a tool slows down your application, your chances decrease.

This is exactly what happens with many Java applications, the authors decided to use Java because of its higher level programming than C, but users don't want it because it is slow.

Pascal is a very good language. I found Pascal to be the most natural
language I ever used. I like Pascal, and I have nothing against Pascal.
Delphi was always one of my favorite Windows only tools. But Pascal
on Unix is a very narrow and dimly lit street. You can do it, just like
you can do Perl or Shell Scripting on Windows. Just don't expect a lot
of support and do not expect there to be a wide world of support out
there. Doable? Of course. The best route? That (at least to my
understanding) was the question.

There are several good reasons to use Pascal for new code:

* FPC programs have no or few library dependencies, and it is therefore very easy to target multiple Linux distributions.
* FPC programs start faster than C programs, and use less memory.
* Lazarus is by far the most advanced RAD-tool available under Linux.
* Lazarus is the only tool that allows you to target GTK, QT, Win32, MacOS with a single codebase, and it doesn't use a can of paint to do so, the controls are the real native ones.

Therefore, yes, for many people, Pascal is the best route.

Daniël Mantione
.

Relevant Pages

  • Re: Whats the best language to learn...
    ... Common Lisp as a industry strong programming language. ... Some languages simply don't "take off" in the wide world even though ... people to make use of tweaky little hacks to self-compress their apps, ... Java and C++). ...
    (comp.programming)
  • Re: Proposal: a language showdown - not necessarily here.
    ... > They occupy niches in the vast domain of applications. ... > Java, for example, is seldom used for general purpose computing ... I'm aware of quite a number of Java applications which are not web based. ... > in programming languages as part of their curriculum. ...
    (comp.lang.cpp)
  • Re: best way to remotely display a java GUI
    ... efficiently over an ssh connection, whereas the defaul behaviour for ssh ... a literal binary copy to the client with respect to java. ... java apps, that is, RMI? ... Typically, in a distributed app, java applications need to be ...
    (comp.lang.java)
  • Re: Threading in VB
    ... Which is another reason that runtime languages are so popular and portable. ... Disputing programming philosophy, what have I become? ... those apps would run unchanged on Windows. ... I've never downloaded a single java ...
    (microsoft.public.vb.general.discussion)
  • Re: Hows dot.net doing nowadays?
    ... Windows applications not web based apps. ... nothing else just to feel that if I make the switch to other languages some ... I work with specialized hardware. ... In regards to Java, I hear alot of people are excited about Ruby on rails. ...
    (microsoft.public.vb.general.discussion)