Re: Whats your favorite language and why? (LINUX)

Giancarlo Niccolai wrote:
Jon Harrop ha scritto:
That is wild speculation. In reality, we have no idea about the
correctness of these programs (in a formal sense). What we do know is
that Java and C# are now significantly more common than C and C++:

http://www.itjobswatch.co.uk/jobs/uk/c.do
http://www.itjobswatch.co.uk/jobs/uk/c++.do
http://www.itjobswatch.co.uk/jobs/uk/java.do
http://www.itjobswatch.co.uk/jobs/uk/csharp.do

Ehem... job requests says even less than any other browseable references
about current distribution of running mission-critical programs
(multithreaded).

Why did you just add "mission-critical"?

GUI needs MT so much that the vast majority of GUI apps are single
threaded.

That is simply not true.

Even Vista has a single thread for dispatching GUI messages,
and if you want to do GUI, your MT GUI app must serialize all the info
coming form the other threads in the only thread that is authorized to
do OS Level GUI.

Yes.

This is even more true for X, where failing to do that causes immediate
and forced crash of the application.

What is "X"?

Finally, even if GUI was really MT, (and it is not) it may handle no
more than a few hundreds very small messages per second,

Your quantification is at least testable. Test it and you'll see that you
are wrong by two orders of magnitude.

Also, the size of the message is irrelevant when you have a concurrent GC
(as the JVM and CLR both do) because a message pass is always O(1) wrt the
size of the data because nothing has to be copied (unlike Erlang).

Finally, I agree that message passing is not fast but it is also not
relevant to this discussion: it simply means that performant communication
with the GUI thread does not use message passing.

and in a couple of threads at a time or so.

Most GUI apps use dozens or even hundreds of threads.

Either you don't know this basic reality, or you are trying to disguise
it. In both cases, any further talk is a loss of time.

I'm afraid your "basic reality" is pure fantasy.

Two very interesting applications written in C that you should be aware
of are the CLR and the JVM. Still they're written in C, with some asm
at spots, as low level C is meant to have. And they appear to work well
with threading... They are just a C program executing instructions of a
more elaborate language.

No, that is completely wrong. You are failing to distinguish between
running a C compiler and writing a compiler in C. The former imposes the
limitations of the C language upon the generated code whereas the latter
gives you complete freedom. Both the JVM and the CLR are examples of the
latter: they use run-time generated machine code and can do anything they
want.

For example, both the JVM and CLR rely heavily upon fine-grained
concurrency between mutators and their GCs. That cannot even be expressed
in C or C++.

You are the one that is confusing running code and running pseudocode,
and this confusion is so evident and radical that I am nearly sure
you're pushing it deliberately.

You can express any high-level concept in any poetry you want, but what
you have on a CPU is opcodes running. That code running, like it or not,
has been designed and realized in C...

You are now using ill-defined phrases like "designed and realized" to dance
around the fact that your previous statements were completely wrong.

I am telling you a big news here: mutlithreading application don't need
to synchronize all the time. The more they can run on their CPU
undisturbed, the more they are working well. In other words, a well
designed multithreading application doesn't even need to know there are
threads running around, if not for a fraction of time, which is needed
to coordinate with the other threads. (Some algorithms don't even EVER
need any form of synchronization, not even visibility guarantees, and
even if rare, they are significant).

If the fraction of the time needed to coordinate by the logic of your
threads is more than epsilon (a minimal, really minimal time quantity),
you're in the wrong business. Prepare your resume, because you'll need it.

In that epsilon, and only in that epsilon, you're willing to perform
coordination, and with that, any needed synchronization. And is there
that you want some guarantees that C, as a language, will not give you,
because it knows you can and have to take it from the hardware you're
running.

Luckily, this hardware is standardized enough that, even if different,
and using different Low level APIs or machine opcodes, they're commonly
abstracted under the same behavioral model. In simpler words, you can
just rewrite the needed function (or macros, that is, raw opcode
sequences) to talk with your hardware synchronization facilities.

For the others readers, contrarily to you, I am not sustaining that C is
the Right Path To Threading Perfection. At times, you'll want Java. But
really... if it's for GUI, you can get away with it with a single thread
in multiplexing. Or if you want a bit of threading, anything that can
launch a thread and signal a semaphore will do. Really, that will do,
and C is good more than enough for that. FOR THAT, there is no need for
the guarantees you're given in Java and CLR. They're cute to have, and
even if they will bog down your program, well, you're doing a GUI...
You may want Java or .NET for GUIs, but it's not because of the
threading you may need in GUIs.

None of the above is even relevant. The point is, Java and C# programs are
executed as machine code that was never C code, so they do not share C's
limitations. The fact that parts of their standard libraries and run-times
are written in C is irrelevant: the bits that require membars cannot have
been written in C in any meaningful sense.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
.

Relevant Pages

  • comp.lang.java.gui FAQ
    ... Q1.3 There are so many Java FAQs. ... Q1.4 Does Sun support or endorse this FAQ? ... Q3.2 How do I update the GUI from another thread? ... Q4.2 What is the Swing single-threading issue? ...
    (comp.lang.java.gui)
  • comp.lang.java.gui FAQ
    ... Q1.3 There are so many Java FAQs. ... Q1.4 Does Sun support or endorse this FAQ? ... Q3.2 How do I update the GUI from another thread? ... Q4.2 What is the Swing single-threading issue? ...
    (comp.lang.java.programmer)
  • Re: A question to the APL vendors on Windows GUIs ...
    ... Is there a possibility of using "Java GUI Modules" instead? ... we can't provide natural APL interfaces to every possible ... low-level programming. ...
    (comp.lang.apl)
  • comp.lang.java.gui FAQ
    ... Q1.2 There are so many Java FAQs. ... Q1.5 What is Swing? ... Q2.1 My GUI freezes or doesn't update. ... Q2.5 How can I make a transparent or non-rectangular window? ...
    (comp.lang.java.gui)
  • Re: MONO (.net for UNIX)
    ... language compilers all generating code for a common back-end - the CLR ... As with Java, you develop once and then deploy the byte-code compiler ... platform on which the CLR functions. ...
    (comp.os.vms)