Ruby vs Java vs c++

M

M. Edward (Ed) Borasky

David said:
I have looked through several compilers. I have to say that one of
the most appealing Scheme->C compiler ideas I have seen was to drop
the distinction between heap and compiler stack: functions were called
with an appropriate continuation data structure, and no function ever
properly returned at the C level. Data was allocated using alloca.

When the heap/stack combination overflowed, it was garbage-compacted
in its entirety. All continuations without a pending reference to
them consequently were removed from the stack.

This basically made continuations rather easy to implement.
Impressive.
I haven't dug into Scheme implementation benchmark shootouts recently,
but for now, my money is on Gambit, mostly because of the "Termite"
package implementation of Erlang-like lightweight processes.
 
D

David Kastrup

Chicken said:
I haven't dug into Scheme implementation benchmark shootouts
recently, but for now, my money is on Gambit, mostly because of the
"Termite" package implementation of Erlang-like lightweight
processes.

Well, it would be my guess that in typical applications continuations
are more important, and it looks from
<URL:http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#SEC133> as
though they are implemented in a manner that basically incurs O(n^2)
copying overhead where the n is the number of call-with-continuation
calls not yet garbage-collected.

I find Chicken's approach to continuations more appealing, but of
course performance hinges on more than just that detail.

Stalin is also said to be a good Scheme compiler.
 
D

David Vallner

--------------enigF7778CC5239D62AA79C89A18
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Paul said:
QTDesigner on Linux, plus a command-line utility called "rbuic", makes
creating GUI interfaces very easy ("rbuic" translates the GUI interface=
specification into a Ruby source file). These may also be available on
Windows.
=20

This was discussed recently, they aren't. Yet (maybe).

David Vallner


--------------enigF7778CC5239D62AA79C89A18
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFYHwYy6MhrS8astoRAoW1AJ9FQvqnY3J5JKiHftyjgKi+H7mVLwCfYXul
8JAq3lpyeSAo4EOmB0e6iU8=
=2HKG
-----END PGP SIGNATURE-----

--------------enigF7778CC5239D62AA79C89A18--
 
M

Mark Shroyer

Java is hostile to both the CPU and the programmer. Hence, the user
suffers too.

Being reasonably experienced in developing both C++ and Java applications,
I would suggest that a modern JVM is not slow by any means:

http://www.kano.net/javabench/data
You will never miss anything (except lots of entry-level jobs that
nobody should want) if you avoid Java like the plague, and stick with
languages that are technically superior. Put another way, the simple
motivation of having a boss order you to use Java is not good enough.
The motivation itself will not magically make Java more productive. It
will slow you down. Some people work by the hour, so that's okay for
them. If you want to be rewarded for productivity, go with the most
technically advanced system you can.

Ruby is great; I clearly wouldn't be on this newsgroup if I thought
otherwise. However, at this point in time Java is far more mature,
performs better, and enjoys a much greater market penetration than Ruby,
meaning that your Java skills, should you choose to develop them, could
prove the more useful.

I agree with Philip in that you should "learn to learn languages"; that's
the advice of a seasoned software engineer. But what I would add to that
is that since Java borrows so much from C++ (and is borrowed even more
heavily from in C#), learning to "think in Java" is an especially good
starting point from which to proceed to other languages. That might be
something worth keeping in mind, especially if you think that you might do
work on .NET some day.

There certainly are flaws in Java, particularly in the language itself.
Many tasks must be approached with an unnecessary verbosity of code:
launching a new thread, for example, requires more writing than it should.
I get the feeling that Gosling et. al. originally intended this very
explicit syntax in order to make the exact behavior of the code more
apparent to the programmer (a decision which may have contributed to
Java's popularity in academic circles). However, when comparing Java to
its extremely similar - yet more concise - counterpart, C#, it is clear
which approach is more appropriate from the standpoint of a pragmatic
software developer. Java began to add some much-needed syntactic sugar in
Java 5, and I would expect to see further improvements in this area in
upcoming relases.

All things considered, the Java environment (and the vast ecosystem that
has grown up around it) is quite powerful. Coupled with the close
ideological relationship that the Java language shares with other popular
programming languages, I would think this makes Java very much worth your
consideration.

Good luck,
Mark
 
D

David Vallner

--------------enig555EDDC25A68A8DDD3E0DDA7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
however, speaking to one my programmer friends who is a top level Java=
programmer (the stuff he writes is very efficient and fancy as
well--great balance),
=20
Oh, I love it when they start lecturing you on how awesome that peesash= it=20
language is! Ay-yi-yi!
=20
[snip]

If I did that using any system besides Ruby (on Rails, and pure Test Dr= iven=20
Development), I would be absolutely screwed. Instead, I am able to fix = the=20
cost of each iteration, while keeping the quality as high as possible, =
without excessive delays.
=20

I am so glad to see the ranting preaching zealot was refuted with a
factually supported statement based on experience with comparable problem=
s.

David Vallner


--------------enig555EDDC25A68A8DDD3E0DDA7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFYH9sy6MhrS8astoRAq2MAJ0frTVGlEGQUomdgOQ0zV7xjGWh4QCeK1Tl
HmMlcYbt75b139rvgCCD++U=
=3ubj
-----END PGP SIGNATURE-----

--------------enig555EDDC25A68A8DDD3E0DDA7--
 
C

Chilkat Software

About 20 years ago, when I graduated from University of Illinois'
with a BS in Computer Science / Engineering,
the department's philosophy was for students to acquire an
understanding of computers and programming
from the ground up. That meant from the electronic circuit level, to
the logic level (NAND and NOR gates),
to assembly programming, and on up. My answer to the original
question is based on this philosophy.
I recommend starting at the C/C++ level simply to gain a fundamental
understanding of the bits & bytes,
pointers, pointer arithmetic, structure layouts, byte ordering,
structure member alignment, dynamic memory
allocation on the heap as opposed to the stack, etc. Understanding
this gives you a good idea
as to what's going on "under the hood" with higher-level
languages. Things won't be so mysterious.
It'll pay off in the long run.

-Matt
 
D

David Vallner

--------------enig6F5CF831CED128315BBFDFCA
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

n/a said:
hi, newbie so please be tolerant.... ;)
=20
i need to start to learn a programming language to be able to develop
custom aps to be applied to a variety of purposes but mainly 1) financi= al
data modeling--including graphics and data handling via database querie= s,
etc.; and 2) more general business-type aps.
=20
my feeling is that i hate BLOATED sluggish programs (like some Java
program running on older JVM's and perhaps not written in an optimal
way....u get the idea.)
=20
if i need to make a choice between fancy and efficient,
speed, etc., then it's an easy choice 4 me of efficient.
which is why i have just started w/ c++.
=20
however, speaking to one my programmer friends who is a top level Java
programmer (the stuff he writes is very efficient and fancy as
well--great balance), he is telling me that 1) c++ is being phased out
(except 4 real low level stuff like drivers, etc.) in favor of language= s
such as Java or Ruby. he recommends i switch from learning c++ to learn= ing
Java or Ruby. i wd hope to be able to choose the best path and not have= to
switch tack in the middle as my IT capablity is not a full time activit= y,
but more of a support 4 my main one--finance.
=20
of course, learning curve is to be taken into consideration as well....=
=20
'd love some comments that might help me consider my options and pick a=
path (c++, java or ruby) w/ a higher level of confidence..... i know th= at
people here will be biased towards Ruby, but that is fine: i want to he= ar
about it....
=20

So, for my two cents.

For the sake of all that's good and holy, use "you" instead of "u", same
for "wd" etc. You write to communicate ideas to others, do so that
they'll be comprehensible by anyone, not just someone able to decrypt
your specific array of preferred abbreviations.

'd b hard 2 undrstd ppl if evr1 tlks n rites like ths.

This whole post was, if unintentional flamebait, having more information
on your requirements as opposed to going on about your and someone
else's personal tastes would have helped.

Now, for the more objective (I hope) bits.

As for performance, well-written C++ outperforms well-written Java,
well-written Java outperforms well-written Ruby. The comparisons get
hairier as problem domain complexity increases.

For graphics, both Java and Ruby use / let you use native libraries for
the heavy lifting, and as long as a database is involved, as the weight
in DB queries increases, the overhead of the language used to do
processing gets negligible compared to DB connection / query execution la=
g.

Most of Java's bad performance rap is due to Swing from versions 1.4 and
easier. It's a well-deserved bad rap. SWT is usually snappier, and works
reasonably well on Windows. On 1.5, IDEA - using Swing tends to be more
responsible for me than Eclipse, using SWT. This doesn't say much about
the relative qualities of the toolkits, rather that by now, they're both
mature enough for their use to be negligible overhead in applications of
sufficient complexity. The above of course presumes the GUIs are
well-written, both those toolkits are quite daunting, and often make
concessions GUI designers - layout managers that are intended to be
targetted by code generators rather than handcoding, which usually draw
much whining from mainly .NET fanboys. (I personally feel much
resentment towards anyone confused by options.)

I admit to not having used Ruby-based GUIs extensively. From what I can
recall about my brief forays into FreeRIDE, FOX seemed to be quite
responsible, and Gtk is fairly mature and native too, and tends to
perform rather well. (On Windows, both look horrible to me though.) On
the question of GUIs, I'd call things even from the performance point of
view. From the programming point of view, all toolkits mentioned make
use of callback functions, where all the languages mentioned need to
emulate functional programming capabilities with varying levels of
verbosity (with roughly Java > C++ > Ruby, greater =3D more verbose).

With your requirements, I think you're understating data source
integration. For database connectivity, every product exposes a C / C++
API. Also, more or less every product save very, very legacy databases
will provide you with a JDBC driver, which in addition to ubiquity gives
you some measure of uniform access. With Ruby, the situation is mildly
less stellar, and you'd better try and scout out if bindings to what you
need are available. For major DB vendors, they should be at usable
levels of maturity, but it's a point worth checking.

Your programmer friend has a rather narrow way of looking at things.
Both C++ and Java have their well-established niches, which means
they'll in some way matter for a long time still. I personally see no
shame in having a CV entry with good representation on the job market
even though it's not the shiny new kid on the block. That said,
depending on how much decision power you expect to wield about choice of
technology you'll use to program, this might be irrelevant to you and
your choice.

As for the fear of switching tacks in the middle, as others have pointed
out, this is unavoidable, and learning to switch is a valuable (and
easy) skill. There is no silver bullet, there is no "best" language, and
if you've got the right brain pathways, you'll notice that all the
class-based OO languages (the major family these days) are essentially
identical in enough of the fundamental concepts for programming in one
you don't know to be a matter of two hours of reading through a syntax
tutorial and having an API reference open in a browser window.

=46rom the learning curve perspective, It Depends. C++, C#, or Java are
easier if you have skill with using a high-level IDE, Ruby if you don't.
On that note, I'd be more in favour of Python than Ruby; since a lot of
learning a language *well* involves reading code, and Python forcing you
to express using more clear and basic concepts (e.g. no eval
metaprogramming, global namespace / class definition clobbering, or
other manners of witty hacks), it's more likely you'll find Python
material more didactic. That said, Ruby code not using features beyond
your current level of comprehension is on par with Python's, and the
latter language has its idiosyncracies too - notably the functional -ish
features.

Summarising the language curve bits, I don't have a problem with either
side of the fence, but scripting languages, Ruby and Python more so than
Perl / Tcl (for me at least) are more approachable in general, and their
libraries seem to be more oriented towards solving the most common tasks
very simply, instead of solving all cases consistently - which means
problems are expressed in a straightforward, more understandable way.

David Vallner


--------------enig6F5CF831CED128315BBFDFCA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFYJH4y6MhrS8astoRAqUoAJkBUF/LTcAIUkrxsLJDUFKV0OnmXQCfac14
oo8SEKsgCAcIrHvNSGjc+tg=
=FxD8
-----END PGP SIGNATURE-----

--------------enig6F5CF831CED128315BBFDFCA--
 
D

David Vallner

--------------enigF95E16667ED3EB8A627078F7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Chilkat said:
I recommend starting at the C/C++ level simply to gain a fundamental
understanding of the bits & bytes,
pointers, pointer arithmetic, structure layouts, byte ordering,
structure member alignment, dynamic memory
allocation on the heap as opposed to the stack, etc. Understanding
this gives you a good idea
as to what's going on "under the hood" with higher-level languages.=20
Things won't be so mysterious.
It'll pay off in the long run.
=20

While my experience was notably shorter, I never, ever saw a problem
where understanding that would be in any way relevant. The whole point
of higher-level languages is that they separate the world into the
language's developers, who do care about what's under the hood, and the
users, who care bugger all about it. Your mileage may vary, but in my
opinion claiming knowing implementation details is important to using
some software isn't in any way essential (and surprisingly enough, this
notion holds in the even higher levels of software design, which is all
about information hiding and complexity reduction). Enlightening, maybe,
definitely useful if you're doing peephole hand-optimisations your C
compiler misses, but not essential for understanding.

Speaking of which, about half of the concepts you mentioned I can't see
how are relevant to implementing higher-level languages. Byte-ordering
is more or less a network / filesystem driver issue, pointer arithmethic
a hack around C not having introspection on array bounds, structure
member alignment and layouts an issue of implementing a C compiler or OS
kernel (its ABI), a cross-language low-level integration issue. Bits and
bytes are utterly irrelevant outside device drivers, they're just not a
meaningful unit of data after you leave hardware. And pointers
complicate C's type system in order to make it more compatible with
assembly and indirect memory adressing, all high-level languages (save
for maybe Perl and PHP) go out of their way to hide the fact that they
even exist and present a more orthogonal and clearer type system.

David Vallner


--------------enigF95E16667ED3EB8A627078F7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFYJWjy6MhrS8astoRAuRqAJsFFOENQd5wBJ38A6mD1KhnbXzvUQCfTFnQ
UHzgcPexlVpU8+OpQaPROJw=
=82YB
-----END PGP SIGNATURE-----

--------------enigF95E16667ED3EB8A627078F7--
 
S

stef

Chilkat Software wrote:



The OP is not trying to become a programmer qua programmer. He wants to
be able to write some very specific kinds of software in a particular a
field. In such a case I recommend that the student learn a language that
conveys the essence of programming, without necessarily conveying the
essence of the underlying hardware.

For such a person, understanding a bit-flip is far below the priority of
understanding encapsulation and top-down design.
paul i think u'r correct in the sense that u can be a great driver w/ out
understanding all the ins and outs of the engine, etc. in italy, they
still have driving students learn all about the engine, how it works,
etc.; as opposed to teaching them how to drive right away and leave the
mechanical part for the mechanically inclined. sure it's great to know
more; and i do want to know more but i also have to be productive and
efficient--which will then afford me the time to learn more, etc. if i
get bogged down in the mechanical details before ever having a chance to
be productive, that we be a problem. i say this w/ out really kowing what
i am getting into or the complete relevance of it but u get my
meaning.....
 
G

Gregory Brown

Well, Dave Thomas is, and many others... Austin Z is (only recently).

I don't think Daniel Berger is, or myself, or Matz.

Although I admit I've thought about it...

I'm really proud of myself for actually trying a Mac, finding out it
wasn't for me, and going back to GNU/Linux (ArchLinux)

Though I will say that if TextMate was cross platform, I might
consider at least trying to get over my cult-like affection towards
vim :)
 
M

M. Edward (Ed) Borasky

David said:
Yeah, I've got Chicken (and DrScheme and Guile and Gambit and a couple
others).
Well, it would be my guess that in typical applications continuations
are more important, and it looks from
<URL:http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#SEC133> as
though they are implemented in a manner that basically incurs O(n^2)
copying overhead where the n is the number of call-with-continuation
calls not yet garbage-collected.

I find Chicken's approach to continuations more appealing, but of
course performance hinges on more than just that detail.

Stalin is also said to be a good Scheme compiler.
Sheesh ... at the risk of introducing a terribly inside joke, now I need
to design a language called Shostakovich. :)

But seriously, to bring this back to Ruby, you've pointed out that the
Scheme community, which worships continuations, has proved to the Ruby
community that they *can* be implemented efficiently. So once again, I
will step on my soapbox and beg with Matz and Koichi to keep
continuations in Ruby >=1.9 if at all possible.

Sunday is the day they do the soapbox thing at Hyde Park in London,
right? :)
 
S

stef

Ayup ... ask the jRuby folks about that :). Of course, there is YARV
coming down the pike, and Rubinius, and the various Ruby on CLR
implementations.

Then again, for pure number crunching, there's no reason in the world
Ruby's NArray can't run at full floating point speed on at least a
modern x86-32 platform. This stuff is what we call "embarrassingly
parallel". :)

sounds good to me ;)
 
M

M. Edward (Ed) Borasky

Gregory said:
I'm really proud of myself for actually trying a Mac, finding out it
wasn't for me, and going back to GNU/Linux (ArchLinux)

Though I will say that if TextMate was cross platform, I might
consider at least trying to get over my cult-like affection towards
vim :)
Quick quiz -- how many vim users actually donate money to the orphanage
in Uganda?

Actually, what made Vim my editor of choice was the GVim implementation
on Windows, not the Unix/Linux versions. After all, they already had vi,
and for those with enough memory, emacs. But the ability to do both "vi"
keystroke editing and Notepad-like cut and paste in GVim was what made
it indispensable to me.

ArchLinux, eh? I've forgotten -- is that a Debian derivative?
 
M

M. Edward (Ed) Borasky

Chilkat said:
About 20 years ago, when I graduated from University of Illinois' with
a BS in Computer Science / Engineering,
the department's philosophy was for students to acquire an
understanding of computers and programming
from the ground up. That meant from the electronic circuit level, to
the logic level (NAND and NOR gates),
to assembly programming, and on up. My answer to the original
question is based on this philosophy.
I recommend starting at the C/C++ level simply to gain a fundamental
understanding of the bits & bytes,
pointers, pointer arithmetic, structure layouts, byte ordering,
structure member alignment, dynamic memory
allocation on the heap as opposed to the stack, etc. Understanding
this gives you a good idea
as to what's going on "under the hood" with higher-level languages.
Things won't be so mysterious.
It'll pay off in the long run.

-Matt
Well, speaking of bachelors' degrees from the University of Illinois,
about 44 years ago I got an AB in math there. Computers were just then
starting to become available to undergraduates, and I certainly learned
the logic design as well as programming on machines of that era. Would
you believe the IBM 650 and ILLIAC I? Hell, these gizmos didn't even
have hardware floating point -- you had to be a grad student to get your
paws on one of those!

I'm glad to see they were still teaching that 20 years ago. But you know
what? I would hope that the people coming out of the U of I in CS/EE
with a BS *today* would have had all of that in high school or even
junior high! I would hope by the time they got their BS, they'd know
stuff that didn't *exist* 20 or 44 years ago!

To give you an example, I graduated right around the time such advances
as the Fast Fourier Transform, Lisp, the notions of computational
complexity and NP-completeness, disk operating systems, etc. were just
starting to make it into commercial application. The stuff that makes
Google and Microsoft and PlayStations and BlueGenes and iPODs tick
*today* is what undergrads should be learning about. And that means, as
far as I'm concerned, Ruby or Smalltalk or Erlang over Forth or
C/C++/Java or Lisp/Scheme.
 
S

stef

tx a lot 4 the feedback. sounds good

Hi!
As a developer who wrote programs in C++ & Java & Ruby and as a man who
trained young programmers,
I surely recommend Ruby for a newbie :)

If you're a beginner it's certainly better to have the fastest startup
with some OO language - and Ruby here is the best choice:
it's easy to learn and it suggests the 'proper' way of OO thinking.
It's more important first to get more experience in OO design and
programming, leaving for the future your thoughts of possible app's low
speed...
After a while you may want to learn Java or / and C++ ('cause a
programmer have to know more than 1 language)
and with happy Ruby experience it'll be much easier.

The questions of speed and efficiency of financial / economical
applications should be treated from the point of view
of the architecture & framework, not merely the programming language -
considering all the DBMS, client-server and Web-interface stuff.
Ruby on Rails offers a fine solution for database-centric applications.

Mike Shock
(Mikhail Shokhirev)
 
S

stef

Only if you promise to read every danged post you inspired.


All non-trivial applications, these days, are multi-lingual. For example,
many applications use a markup language (HTML, RC, etc...) to paint their
GUIs. Then they use an OO language for their high-level command-and-control
code (such as Ruby). Then they use a declarative language, such as SQL, to
interface with their systems, such as OSs and database engines written in a
C language.


That's because Java was invented to take market share from C++, allegedly
without introducing new risks. The actual result was a language that's
harder to compile, and harder to program. Java strongly resists high-level
abstractions, forcing you to write line after line and page after page of
cruft just to get anything done. (No wonder the book /Refactoring/ uses
Java!!;)

Java is hostile to both the CPU and the programmer. Hence, the user suffers
too.


No prob. Just remember that C++ is "portable OO assembler", and it is
CPU-friendly and programmer-hostile.

Ruby, by contrast, is the ultimate in programmer-friendliness. At
considerable expense to the CPU!


Oh, I love it when they start lecturing you on how awesome that peesashit
language is! Ay-yi-yi!


Incorrect. C++ is a systems language (per Bjarne Stroustrup, its author).
Systems are large and long-lived. Nobody is phasing them out.

C++ is strongly represented in the database, videogames, operating systems,
scientific, and research spaces. Also, all those spaces typically "alternate
hard and soft layers", by augmenting their C++ with a soft OO language.
Videogames use LUA, OSs often use Perl, databases use at least SQL if not
more, and so on. Ruby makes an _exquisite_ soft-layer, to provide the
high-level features for a C++ application.


Learn to learn languages. I could write a program in Java if you forced me
to (and with steady access to Google). Then learn all of them. You don't
have to worry about running out of room in your brain!


You will never miss anything (except lots of entry-level jobs that nobody
should want) if you avoid Java like the plague, and stick with languages
that are technically superior. Put another way, the simple motivation of
having a boss order you to use Java is not good enough. The motivation
itself will not magically make Java more productive. It will slow you down.
Some people work by the hour, so that's okay for them. If you want to be
rewarded for productivity, go with the most technically advanced system you
can.

I work to the story-point. That means I estimate for my client each feature
in "ideal hours", and then I charge to those point, _not_ the actual hours
spent researching and coding. I don't actually give a darn what that time is
(and it usually includes lots of bizarre interruptions from my females!).

If I did that using any system besides Ruby (on Rails, and pure Test Driven
Development), I would be absolutely screwed. Instead, I am able to fix the
cost of each iteration, while keeping the quality as high as possible,
without excessive delays.

i AM reading e/y single post in the thread, believe me.
tx 4 the info.
 
S

stef

Being reasonably experienced in developing both C++ and Java applications,
I would suggest that a modern JVM is not slow by any means:

http://www.kano.net/javabench/data


Ruby is great; I clearly wouldn't be on this newsgroup if I thought
otherwise. However, at this point in time Java is far more mature,
performs better, and enjoys a much greater market penetration than Ruby,
meaning that your Java skills, should you choose to develop them, could
prove the more useful.

I agree with Philip in that you should "learn to learn languages"; that's
the advice of a seasoned software engineer. But what I would add to that
is that since Java borrows so much from C++ (and is borrowed even more
heavily from in C#), learning to "think in Java" is an especially good
starting point from which to proceed to other languages. That might be
something worth keeping in mind, especially if you think that you might do
work on .NET some day.

There certainly are flaws in Java, particularly in the language itself.
Many tasks must be approached with an unnecessary verbosity of code:
launching a new thread, for example, requires more writing than it should.
I get the feeling that Gosling et. al. originally intended this very
explicit syntax in order to make the exact behavior of the code more
apparent to the programmer (a decision which may have contributed to
Java's popularity in academic circles). However, when comparing Java to
its extremely similar - yet more concise - counterpart, C#, it is clear
which approach is more appropriate from the standpoint of a pragmatic
software developer. Java began to add some much-needed syntactic sugar in
Java 5, and I would expect to see further improvements in this area in
upcoming relases.

All things considered, the Java environment (and the vast ecosystem that
has grown up around it) is quite powerful. Coupled with the close
ideological relationship that the Java language shares with other popular
programming languages, I would think this makes Java very much worth your
consideration.

Good luck,
Mark

u make a good case. tx.
 
S

stef

stef wrote:

/ ...


Sure, I get your meaning, after a little help from my Perlish IRC cruft
filter:

s/ paul / Paul /g

s/ u'r / you are /g

s/ italy / Italy /g

s/ i / I /g

s/ u / you /g

s! w/ out ! without !g

No pure regexp for the rule "Sentences begin with a capital letter", but
since this is a Ruby newsgroup:

message.gsub!(%r{(^|\.\s+)(\w)}) { |c| c.upcase }

If this seems anal, remember that computers are unashamedly anal, fully ten
times worse than a human OCD sufferer.

well that's really helpful........
 
J

Jim Cochrane

hi, newbie so please be tolerant.... ;)

i need to start to learn a programming language to be able to develop
custom aps to be applied to a variety of purposes but mainly 1) financial
data modeling--including graphics and data handling via database queries,
etc.; and 2) more general business-type aps.

my feeling is that i hate BLOATED sluggish programs (like some Java
program running on older JVM's and perhaps not written in an optimal
way....u get the idea.)

if i need to make a choice between fancy and efficient,
speed, etc., then it's an easy choice 4 me of efficient.
which is why i have just started w/ c++.

If you're not too attached to the mainstream, Eiffel could be another
choice - efficient (statically compiled, like C++), but higher-level
than C++; has GC but is better designed than Java, as far as the language
itself. Designed to facilitate writing correct programs. If this
interests you, do a bit of googling/research to learn about its
advantages and disadvantages and see if it's worth pursuing further.
(There are two GNU-licensed Eiffel compilers available:
http://eiffelzone.com/esd/studio/index.html
http://smarteiffel.loria.fr/
..)

Regarding Ruby, it's much closer to being justifiably called a pure OO
language than Java is; part of the result of that is that its design is
simpler and better. In many cases, you don't want to make a choice
between high-level and efficient - you want both; and you do that by
using two or more languages. Ruby is a contender for being your best
choice for your "dynamic scripting" language. (Perl has an advantage if
you need its larger available collection of libraries and components,
but this will shrink as Ruby is used more.)
however, speaking to one my programmer friends who is a top level Java
programmer (the stuff he writes is very efficient and fancy as
well--great balance), he is telling me that 1) c++ is being phased out
(except 4 real low level stuff like drivers, etc.) in favor of languages
such as Java or Ruby. he recommends i switch from learning c++ to learning
Java or Ruby. i wd hope to be able to choose the best path and not have to
switch tack in the middle as my IT capablity is not a full time activity,
but more of a support 4 my main one--finance.

of course, learning curve is to be taken into consideration as well....

'd love some comments that might help me consider my options and pick a
path (c++, java or ruby) w/ a higher level of confidence..... i know that
people here will be biased towards Ruby, but that is fine: i want to hear
about it....


--
 
S

stef

If you're not too attached to the mainstream, Eiffel could be another
choice - efficient (statically compiled, like C++), but higher-level
than C++; has GC but is better designed than Java, as far as the language
itself. Designed to facilitate writing correct programs. If this
interests you, do a bit of googling/research to learn about its
advantages and disadvantages and see if it's worth pursuing further.
(There are two GNU-licensed Eiffel compilers available:
http://eiffelzone.com/esd/studio/index.html
http://smarteiffel.loria.fr/
.)

Regarding Ruby, it's much closer to being justifiably called a pure OO
language than Java is; part of the result of that is that its design is
simpler and better. In many cases, you don't want to make a choice
between high-level and efficient - you want both; and you do that by
using two or more languages. Ruby is a contender for being your best
choice for your "dynamic scripting" language. (Perl has an advantage if
you need its larger available collection of libraries and components,
but this will shrink as Ruby is used more.)

tx. i'll definitely check out eiffel; and you're right: i'd like to
trade-off as little as possible efficiency and higher level/programmer
friendliness; which prompted my post in the 1st place ;)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,982
Messages
2,570,186
Members
46,744
Latest member
CortneyMcK

Latest Threads

Top