Ruby vs Java vs c++
n/a
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++.
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....
Paul Lutus
> hi, newbie so please be tolerant.... ;)
You can count on it.
> 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.)
I have rather a lot of experience with Java, and it's not easy to avoid the
bloated aspect, if the program has a GUI. The problem is the GUI, not the
code. It is made worse when the GUI code is written in java, nearly always
true.
Ruby, by contrast, uses native-code GUI libraries, so it tends to be faster
as a GUI based language. It is certainly easier to modify and debug than
Java is, because of its transparent syntax.
> 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++.
C++ is only efficient when it is running. It is not efficient when you have
a deadline to finish a project and deliver working code.
The basic idea is this -- if the program is only written once and is to be
used by millions of people, then definitely use C++. If the same program is
to be written in a million variations over a period of years and only used
by a handful or people, then definitely Java or Ruby.
The middle cases require more experience to decide. In such cases, I
sometimes prototype in Ruby, because development is so fast, and then
translate the result from Ruby into C++ once I have a working program, so
the delivered program will be fast.
> 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.
This viewpoint would be very difficult to defend. C++ isn't remotely being
phased out. C++ has its niche, as does Java and Ruby, etc. etc..
> he recommends i switch from learning c++ to learning
> Java or Ruby.
You will most likely learn more about programming in a shorter time by
taking his advice, but remember that the reasoning behind his advice isn't
sound. Both Java and Ruby will show you object-oriented concepts, a "good
thing", and later on, you might want to learn C++ for those applications
that require more speed and/or closer coupling to the machine. C++ is less
object-oriented than either Java or Ruby, which means (IMHO) that the
latter two languages are a better choice for learning programming
principles.
> 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.
Oh, I thought you were going to become a well-rounded programmer. Oh, well,
in that case, either Ruby or Java will suit your goals much better than C++
would. You will be able to create and maintain 95% of the applications
typical in financial institutions using either Ruby or java, or both.
>
> of course, learning curve is to be taken into consideration as well....
Your learning curve will be much faster with Ruby or Java than with C++.
Guaranteed. I personally think Ruby and Java are much better tutorial
languages than C++ is.
> '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....
I don't think you will see much in the way of bias for or against any
particular language, at least from the regular posters here, because most
have come from a background of many other languages.
It's not like we're all Macintosh owners, or Scientologists, or Mensa
members, if you get my drift. :)
--
Paul Lutus
http://www.arachnoid.com
M. Edward (Ed) Borasky
and C++ being the hardest to learn. However, the heavy math, graphics,
database queries and other computational finance applications will be
easier for you if you use a language not in your list -- R. R has a lot
of computational finance libraries already. Are you on Linux, Windows or
something else?
As far as general business applications are concerned, I think you'll
find Ruby is a lot easier to work with than Java or C++. I find C++ code
totally unreadable, but I can usually read Java code. And having to
manage memory and pointers yourself is tedious, error prone and pretty
much rules out C++ for anything but gurus.
Speed -- for number crunching, regardless of which language you use, the
underlying math and array operations should be done in either C, C++ or
FORTRAN in libraries. Native Java number crunching is a lot faster than
native Ruby number crunching, but I don't know anyone who does number
crunching these days in native scripting languages.
>
>
--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
M. Edward (Ed) Borasky
> It's not like we're all Macintosh owners, or Scientologists, or Mensa
> members, if you get my drift. :)
>
much *every* Rubyist was a Macintosh owner. At least all the famous ones
seem to be. :)
n/a
> In such cases, I sometimes prototype in Ruby, because development is so
> fast, and then translate the result from Ruby into C++ once I have a
> working program, so the delivered program will be fast.
tx a lot 4 the feedback, Paul. i will take e/g into consideration.
let me ask u how the the translation from ruby to c++ is done....
(that wd make the case even more to go ahead and start w/ ruby and
translate to c++ in some cases where it wd be needed; & stick w/ ruby the
rest of the time....)
Paul Lutus
> On Sat, 18 Nov 2006 16:00:07 -0800, Paul Lutus wrote:
>
>> In such cases, I sometimes prototype in Ruby, because development is so
>> fast, and then translate the result from Ruby into C++ once I have a
>> working program, so the delivered program will be fast.
>
> tx a lot 4 the feedback, Paul. i will take e/g into consideration.
>
> let me ask u how the the translation from ruby to c++ is done....
By a human. e.g. me. It's not automated. It might be sometime in the future,
but remember that hand-written C++ is always faster, when done by someone
with some depth of knowledge.
>
> (that wd make the case even more to go ahead and start w/ ruby and
> translate to c++ in some cases where it wd be needed; & stick w/ ruby the
> rest of the time....)
You shouldn't expect an automated Ruby to C++, or for that matter a Java to
C++, automatic translator, in the foreseeable future.
Matt Lawrence
> Paul Lutus wrote:
>> It's not like we're all Macintosh owners, or Scientologists, or Mensa
>> members, if you get my drift. :)
>>
> There was a time not too long ago (RubyConf 2006) when I thought pretty much
> *every* Rubyist was a Macintosh owner. At least all the famous ones seem to
> be. :)
Not true, Hal Fulton doesn't own a Macintosh. But I'll bet he would
really love having one if someone was to send it to him.
-- Matt
It's not what I know that counts.
It's what I can remember in time to use.
Paul Lutus
> Paul Lutus wrote:
>> It's not like we're all Macintosh owners, or Scientologists, or Mensa
>> members, if you get my drift. :)
>>
> There was a time not too long ago (RubyConf 2006) when I thought pretty
> much *every* Rubyist was a Macintosh owner. At least all the famous ones
> seem to be. :)
Hmm. :)
Well, anyone can be a Macintosh owner, but it takes a special mental
configuration to be a Macintosh ... looking for the right word here ...
advocate? :)
Hal Fulton
>
>> It's not like we're all Macintosh owners, or Scientologists, or Mensa
>> members, if you get my drift. :)
>>
>
> There was a time not too long ago (RubyConf 2006) when I thought pretty
> much *every* Rubyist was a Macintosh owner. At least all the famous ones
> seem to be. :)
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...
Hal
n/a
> I think you'll find that Ruby is the easiest to learn, followed by Java
> and C++ being the hardest to learn. However, the heavy math, graphics,
> database queries and other computational finance applications will be
> easier for you if you use a language not in your list -- R. R has a lot
> of computational finance libraries already. Are you on Linux, Windows or
> something else?
>
> As far as general business applications are concerned, I think you'll
> find Ruby is a lot easier to work with than Java or C++. I find C++ code
> totally unreadable, but I can usually read Java code. And having to
> manage memory and pointers yourself is tedious, error prone and pretty
> much rules out C++ for anything but gurus.
>
> Speed -- for number crunching, regardless of which language you use, the
> underlying math and array operations should be done in either C, C++ or
> FORTRAN in libraries. Native Java number crunching is a lot faster than
> native Ruby number crunching, but I don't know anyone who does number
> crunching these days in native scripting languages.
>
ok, so i cd conceivably develop in ruby and integrate c++ 4 the number
crunching parts. wd that make sense...?
(and tx 4 the pointer to "R" as well)
n/a
ok, tx 4 clearing that up. it means that u must have knowledge of both
languages, obviously....and the point re. starting w/ a more intuitive
language such as ruby is of interest
El Gato
I'd rather suggest that you go the Ruby route because I think that you
would experience a much smoother learning curve and a level of
productivity that the other two can only dream of (...well, until you
get into GUI stuff which is generally quicker in Java or C++ due to the
nice IDEs available for each. I haven't really been keeping up with
Ruby IDEs, but I don't think one exists yet for GUI development).
However, it seems to me that you're looking for the expressiveness of
Ruby and the speed of C++. Welcome to the club. Strangely enough,
Java's domain really is somewhere between each. Plus, you'll never
truly appreciate a language like Ruby until you deal with a more...
verbose language such as Java.
--
Posted via http://www.ruby-forum.com/.
Paul Lutus
/ ...
> I'd rather suggest that you go the Ruby route because I think that you
> would experience a much smoother learning curve and a level of
> productivity that the other two can only dream of (...well, until you
> get into GUI stuff which is generally quicker in Java or C++ due to the
> nice IDEs available for each. I haven't really been keeping up with
> Ruby IDEs, but I don't think one exists yet for GUI development).
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.
_why
> >There was a time not too long ago (RubyConf 2006) when I thought pretty
> >much *every* Rubyist was a Macintosh owner. At least all the famous ones
> >seem to be. :)
>
> Well, Dave Thomas is, and many others... Austin Z is (only recently).
>
> I don't think Daniel Berger is, or myself, or Matz.
Oh, but look here:
http://flickr.com/photos/zh/165711300
Only one. :]
_why
stef
> However, it seems
> to me that you're looking for the expressiveness of Ruby and the speed of
> C++. Welcome to the club.
u'r right; i guess that's what i'm looking 4....
stef
u mean this http://www.arachnoid.com/ruby/RubyGUIProject/index.html (but
for windows) and
this http://www.trolltech.com/products/qt/features/designer
Roseanne Zhang
> Ruby and the speed of C++. Welcome to the club. Strangely enough,
> Java's domain really is somewhere between each. Plus, you'll never
> truly appreciate a language like Ruby until you deal with a more...
> verbose language such as Java.
Everybody here or somewhere else take that for granted: Java is slower
than C++, but actually that is not true.
I thought so too. However, my computational heavy practice proved, to
certain extent, otherwise.
Interesting enough, I was a very experienced C++ programmer, and
learning Java in 2000. I got an very heavy algorithm job. I write the
same code in Java and C++. When the algorithm was relatively simple, my
C++ code was about twice faster than Java c++/Java = 610/1085. However,
when my algorithm became extremely heavy iteration, the result was
c++/Java = 26000/12000. Java was more than twice faster than C++.
I asked several Java experts include Jason Hunter, Daniel Brookshier
about the question, why? The answers are the same, JIT!!!!
Roseanne Zhang
> Everybody here or somewhere else take that for granted: Java is slower
> than C++, but actually that is not true.
>
> I thought so too. However, my computational heavy practice proved, to
> certain extent, otherwise.
I should have said:
Everybody here or somewhere else take that for granted: Java is slower
than C++, but actually that is not ALWAYS true.
stef
thanks for the info; i see that i was not the only one with that idea
(whether pre-conceived or not).
i have to say that o/all i have seen java slower than c++ but NOT always
e.g. my programmer friend who can write in java really complex aps yet
super fast, user friendly and pleasant to the eye.... he tells me it is
because he knows how to program (and because JVM's r better than they used
to be.)
he might have a point there.....
M. Edward (Ed) Borasky
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". :)
Mike Shock
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)
Phlip
> hi, newbie so please be tolerant.... ;)
Only if you promise to read every danged post you inspired.
> 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.
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.
> 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.)
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.
> 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++.
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!
> 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),
Oh, I love it when they start lecturing you on how awesome that peesashit
language is! Ay-yi-yi!
> 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.
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.
> 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.
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!
> 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....
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.
--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Martin DeMello
> However, it seems to me that you're looking for the expressiveness of
> Ruby and the speed of C++. Welcome to the club. Strangely enough,
I'm learning OCaml for just that reason :) Some of the Scheme dialects
get some impressive performance figures too, but I haven't really
looked into them as much.
martin
David Kastrup
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.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
M. Edward (Ed) Borasky
but for now, my money is on Gambit, mostly because of the "Termite"
package implementation of Erlang-like lightweight processes.
David Kastrup
> David Kastrup wrote:
>> "Martin DeMello" <martin...@gmail.com> writes:
>>
>>
>>> On 11/19/06, El Gato <wmwil...@gmail.com> wrote:
>>>
>>>> However, it seems to me that you're looking for the expressiveness of
>>>> Ruby and the speed of C++. Welcome to the club. Strangely enough,
>>>>
>>> I'm learning OCaml for just that reason :) Some of the Scheme
>>> dialects get some impressive performance figures too, but I haven't
>>> really looked into them as much.
>>
>> 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.
Chicken <URL:http://www.call-with-current-continuation.org/index.html>
> 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.
David Vallner
> - multiple inheritance
C++ mixins anyone? Multiple inheritance with data is evil, but as long
as you only implement pure interfaces or mixins with it, it's
acceptable. It's not like a language should restrict its users with
regards to how horribly they can break the code (and brains) of other
people reusing their creations, eh?
> - operator overloading
Except for contexts where the -semantics- of the operator isn't being
overloaded, just implemented for a case the language doesn't natively
supported. Matrix multiplication -is- multiplication and a fine use
case, using, oh, shall we say, << for something that's not a bitshift,
like pushing data into an array or a stream (which some C++ texts
ironically discourage) is indeed bad.
*runs for the hills - FAST*
David Vallner
Meditating upon Pots and Kettles
David Vallner
> 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.
>
This was discussed recently, they aren't. Yet (maybe).
David Vallner
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
--
Mark Shroyer
http://markshroyer.com/
David Vallner
>> 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),
>
> Oh, I love it when they start lecturing you on how awesome that peesashit
> language is! Ay-yi-yi!
>
[snip]
> 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 so glad to see the ranting preaching zealot was refuted with a
factually supported statement based on experience with comparable problems.
David Vallner
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
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.7/538 - Release Date: 11/18/2006
David Vallner
> hi, newbie so please be tolerant.... ;)
>
> 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.
>
> program running on older JVM's and perhaps not written in an optimal
> way....u get the idea.)
>
> speed, etc., then it's an easy choice 4 me of efficient.
> which is why i have just started w/ c++.
>
> programmer (the stuff he writes is very efficient and fancy as
> (except 4 real low level stuff like drivers, etc.) in favor of languages
> 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.
>
>
> '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....
>
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 lag.
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 = 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.
From 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
David Vallner
> 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.
>
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
Paul Lutus
>
> 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.
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.
stef
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.....
Gregory Brown
> M. Edward (Ed) Borasky wrote:
> > Paul Lutus wrote:
> >
> >> It's not like we're all Macintosh owners, or Scientologists, or Mensa
> >> members, if you get my drift. :)
> >>
> >
> > There was a time not too long ago (RubyConf 2006) when I thought pretty
> > much *every* Rubyist was a Macintosh owner. At least all the famous ones
> > seem to be. :)
>
> Well, Dave Thomas is, and many others... Austin Z is (only recently).
>
> I don't think Daniel Berger is, or myself, or Matz.
>
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 :)
Paul Lutus
/ ...
>> 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.....
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.
M. Edward (Ed) Borasky
>
Yeah, I've got Chicken (and DrScheme and Guile and Gambit and a couple
others).
>
>> 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.
>
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? :)
stef
sounds good to me ;)
M. Edward (Ed) Borasky
> 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 :)
>
>
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. Edward (Ed) Borasky
>
> 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
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.
stef
stef
i AM reading e/y single post in the thread, believe me.
tx 4 the info.
stef
u make a good case. tx.
stef
well that's really helpful........
Jim Cochrane
> hi, newbie so please be tolerant.... ;)
>
> 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.
>
> program running on older JVM's and perhaps not written in an optimal
> way....u get the idea.)
>
> 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....
--
stef
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 ;)
Phlip
> Phlip wrote:
> [snip]
Apologies for misunderstand you, but which one was the zealot?
That door tends to swing both ways... ;-)
--
Phlip
Paul Lutus
/ ...
>> If this seems anal, remember that computers are unashamedly anal, fully
>> ten times worse than a human OCD sufferer.
>>
>
> well that's really helpful........
I thought you would find it useful, in your valiant efforts to gain greater
literacy and achieve clearer communications with your fellow man. :)
Paul Lutus
/ ...
> i AM reading e/y single post in the thread, believe me.
> tx 4 the info.
Translation for Earthlings:
"I *am* reading every single post in the thread, believe me. Thank you for
the information."
French is easier.
dbl...@wobblini.net
On Mon, 20 Nov 2006, Paul Lutus wrote:
> stef wrote:
>
> / ...
>
>> i AM reading e/y single post in the thread, believe me.
>> tx 4 the info.
>
> Translation for Earthlings:
>
> "I *am* reading every single post in the thread, believe me. Thank you for
> the information."
>
> French is easier.
I think the point has been made enough times that stef uses a lot of
abbreviations, and that not everyone likes it. Please let's not go
on and on about it -- thanks.
David
--
David A. Black | dbl...@rubypal.com
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org
Friedrich Dominicus
> 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.
Why not Ruby and Java and C++?
The realy unanswered question is when is one better than the other. I
even have seen someone using C for "scripting" ;-)
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Ross Bamford
> stef wrote:
>
> / ..
>
>> i AM reading e/y single post in the thread, believe me.
>> tx 4 the info.
>
> Translation for Earthlings:
>
> "I *am* reading every single post in the thread, believe me. Thank you
> for
> the information."
>
> French is easier.
>
How about introducing an [OT][WHINE] subject prefix for this stuff? So I
know to skip your persistently-off-topic whining, of course...
--
Ross Bamford - ro...@roscopeco.remove.co.uk
M. Edward (Ed) Borasky
> n/a <n...@nomail.invalid> writes:
>
>
>> 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.
>>
> Why not Ruby and Java and C++?
> The realy unanswered question is when is one better than the other. I
> even have seen someone using C for "scripting" ;-)
>
for scripting, mostly because it was more or less guaranteed to exist
everywhere, while everyone had their own "JCL/command
line/shell/whatever". So not only is it possible to write Fortran
programs in any language ...
spooq
lives and breathes Excel. VBA is by far the language most likely to be
of use to someone entering that world. It's pretty clear programming
is a tool for his/her use, rather than something that (s)he wants to
do for it's own sake. Having said that, Excel can be viewed as a type
of DSL in it's own right, so pushing the boundaries of what can be
done 'natively' is a great place to start.
David Kastrup
Isn't VBA rather similar to Ruby, anyway?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
spooq
To me it looks like an OO BASIC with support for databases and Office apps.
Reid Thompson
> Why not Ruby and Java and C++?
> The realy unanswered question is when is one better than the other. I
> even have seen someone using C for "scripting" ;-)
>
http://www.softintegration.com/
Ch is an embeddable C/C++ interpreter for cross-platform scripting,
shell programming, 2D/3D plotting, numerical computing, and embedded
scripting. Ch is the solution for:
stef
> stef wrote:
>
> / ...
>
>>> If this seems anal, remember that computers are unashamedly anal, fully
>>> ten times worse than a human OCD sufferer.
>>>
>>
>> well that's really helpful........
>
> I thought you would find it useful, in your valiant efforts to gain greater
> literacy and achieve clearer communications with your fellow man. :)
>
My literacy is just fine, thank you very much. For the sake of speed, I
use shortcuts.
I realize you are a programmer but contrary to the machines you program,
which interpret code literally, you hopefully have the power to INTERPRET,
as opposed to a chip.
Surely, you can make out that "u" = "you", etc....
Gabriele Marrone
On 20/nov/06, at 16:20, stef wrote:
> My literacy is just fine, thank you very much. For the sake of
> speed, I
> use shortcuts.
http://www.google.com/search?q=dvorak+keyboard
--
Gabriele Marrone
James Cunningham
Sure, I *can*, but I'll be less inclined to undertake the effort of
reading something if it makes my eyes bleed. Failing to use proper
English is jarring to me. Most of us grew up reading books; the English
you use is not the English we are used to reading.
How much time do you save? You realize that abbreviating tiny words
like "you" and "thanks" are dwarfed by other words, like "programmer",
"contrary", and "interpret"?
Best,
James
Peter Hickman
> My literacy is just fine, thank you very much. For the sake of speed, I
> use shortcuts.
> I realize you are a programmer but contrary to the machines you program,
> which interpret code literally, you hopefully have the power to INTERPRET,
> as opposed to a chip.
> Surely, you can make out that "u" = "you", etc....
>
>
regional and or cultural variants is unlikely to aid communication, even
native speakers can have problems. Remember that Ruby was developed by a
Japanese speaker. If Matz had shown your arrogance we would all be VB
programmers! Isn't is nice that Matz put the effort into communicating
clearly with other people. If you can't be bothered to take the time to
communicate then save yourself even more time by not hitting the send
button.
Richard Conroy
> On Sun, 19 Nov 2006 17:20:29 -0800, Paul Lutus wrote:
> My literacy is just fine, thank you very much. For the sake of speed, I
> use shortcuts.
You realise how self-defeating that is? Your speed of typing translates
into greater work for the reader. In your effort to seek help you should
be writing clearly. If that means that you sit down at a PC instead of
replying from your smartphone then do so.
> Surely, you can make out that "u" = "you", etc....
Yes we can, but it's annoying. Text speak is bad.
Also consider that this is an international group. Phonetic text abbreviations
that may be obvious to an english speaker, might be unreadable to many
worldwide Ruby-talk readers.
Hugh Sasse
> My literacy is just fine, thank you very much. For the sake of speed, I
> use shortcuts.
If you are using vi or vim you can program the editor to expand
abbreviations for you. In vim you can lookup :ab in the help
system:-
:he :ab
I'm almost certain Emacs can do abbreviation expansion as well. There
is also automatic completion available in vim for, that matter, see
:he compl-generic
for more on this. Searching for tools to help with RSI will
provide other alternatives.
You appear to be using the Pan newsreader. I'm unfamiliar with it,
and a quick look around the pan web site turns up nothing about
configuring the editor for it, so I'd suggest you look on a Pan
mailing list about how to configure it to use you favourite editor.
> I realize you are a programmer but contrary to the machines you program,
> which interpret code literally, you hopefully have the power to INTERPRET,
> as opposed to a chip.
> Surely, you can make out that "u" = "you", etc....
This moves effort from you to the N people reading the message.
Given the way much reading is done by word shape rather than reading
individual letters, this is at best inconsiderate. As you have
seen, it can be misconstrued as ignorance.
Hugh
Friedrich Dominicus
> On Mon, 2006-11-20 at 15:05 +0900, Friedrich Dominicus wrote:
>> Why not Ruby and Java and C++?
>> The realy unanswered question is when is one better than the other. I
>> even have seen someone using C for "scripting" ;-)
>>
> :)
> http://www.softintegration.com/
Yeah I know that but I was talking of compiled C. So a bit different
;-). IIRC that was for parsing some XML....
>
> Ch is an embeddable C/C++ interpreter for cross-platform scripting,
> shell programming, 2D/3D plotting, numerical computing, and embedded
> scripting. Ch is the solution for:
It's very C-ish but the libraries make the difference. However others
have written C-Interpreters also:
Eic (now abondoned)
Cint http://root.cern.ch/root/Cint.html
and another one which name I forgot...
And I remember that in anotherthread someone suggested to use the Ruby
Interpreter as a somewhat bigger library ;-)
CParticle
My two cents here as someone who swtiched from VB script to Ruby on why
not VBA, is pretty simple. If you learn VBA your are locked in to MS
products only this was my feeling as I've not heard much of VB anything
on a non-Windows environment or at least none to take note of. While
it probably is the best way to go if you are in a MS only environment
and are ok with that it seems at least to be a non-transferable
language. I did switch to Ruby however exactly because as was said
above it is very much like VBA which I had experience with. The other
reason I switch if the OP cares is that Ruby is a younger language and
this give me an opportunity to learn the language before/if the
language becomes more popular. So far (6 months) I like Ruby very much
and with the help of some people on this list I've managed to put into
production some of my scripts.
CParticle
Paul Lutus
> I would like to suggest the newbie learns VBA.
Perhaps, but IMHO after he learns programming. Otherwise VBA is a VBI. It is
certainly not a model for reliable programming style. It is only a small
bit removed from its origins in what may be the worst computer language
ever conceived.
> The financial world
> lives and breathes Excel. VBA is by far the language most likely to be
> of use to someone entering that world. It's pretty clear programming
> is a tool for his/her use, rather than something that (s)he wants to
> do for it's own sake. Having said that, Excel can be viewed as a type
> of DSL in it's own right, so pushing the boundaries of what can be
> done 'natively' is a great place to start.
OTOH, there are all sorts of interfaces to Excel objects, interfaces that
allow one to use more modern programming methods, and Ruby has one of
those. This adds to portability in a way that a complete absorption in VBA
would not -- for example one might create a generic solution to a financial
computation that interacts with, but is not dependent on, the Excel/VBA
interface. That solution could then be ported and used elsewhere. This
strategy would prolong the professional lifetime -- the viability -- of a
programmer who adopted this approach.
Paul Lutus
Not remotely. It has its roots in Visual Basic, which Microsoft abandoned a
few years ago in its zeal to sell a different, newer language to all its
loyal adherents. VBA will suffer the same fate in time, because it is owned
by a corporation whose goal is to sell new products to old customers.
VBA is not a very good model for teaching programming principles, and it is
important to remember it is a single-vendor product, one that will rise or
fall with that vendor's fortunes. Also Microsoft has no incentive to
cooperate with third parties -- those will good long-term recall will
remember the brouhaha surrounding Microsoft and Java.
Diego Virasoro
> which interpret code literally, you hopefully have the power to INTERPRET,
> as opposed to a chip.
> Surely, you can make out that "u" = "you", etc....
Although I must agree that Paul was nitpicking too much, and I am happy
to be a bit flexible (for example lots of friends forget to capitalize
the first word of a sentence), some of those abbreviation you used do
take a while to be "processed".
You may think your readers will be happy to put up with it, but most
probably if they cannot work out one of your abbreviation in some short
time, they'll just give up and move to the next question.
So it's all a matter of who has the most interest in the communication,
if you or your reader.
That said, maybe you can set a small ruby script and everyone wins, you
get speed and the rest of us get clarity. :)
Diego
M. Edward (Ed) Borasky
> M. Edward (Ed) Borasky wrote:
>>
>> everywhere, while everyone had their own "JCL/command
>
>
>> line/shell/whatever". So not only is it possible to write Fortran
>> programs in any language ...
>
> I feel old.
You feel old? Apparently you missed my post on ILLIAC I. :)
Charles D Hixson
>
> 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
From that perspective, I'd recommend starting with MIX & Knuth. But if
you want faster results pick Ruby or Python.
I'd NEVER recommend C++. C, perhaps, to establish a solid grounding in
the fundamentals...but not for anything serious. It takes too long.
One compiled language that you might try is D (Digital Mars D), with
links to C libraries to accomplish the things that aren't yet built in.
OTOH, for many uses Ruby and Python are BOTH hard to beat. I like Ruby
better as a language, but Python seems to have more bug-free libraries.
(Well, free of "show stopper" bugs.) And Python has a wider variety of
libraries. (Still, you find me here in the Ruby news group. I like
Ruby better.)
WARNING: NO LANGUAGE IS PERFECT!! Choose the language to suit the
problem. For some problems Java is the best available solution. (I'm
not aware of ANY problems for which I would choose C#, but that's
because of potential legal issues...so I won't even look at it.)
Charles D Hixson
> El Gato wrote:
>
>> Ruby and the speed of C++. Welcome to the club. Strangely enough,
>> Java's domain really is somewhere between each. Plus, you'll never
>> truly appreciate a language like Ruby until you deal with a more...
>> verbose language such as Java.
>>
>
> Everybody here or somewhere else take that for granted: Java is slower
> than C++, but actually that is not true.
>
> I thought so too. However, my computational heavy practice proved, to
> certain extent, otherwise.
>
> Interesting enough, I was a very experienced C++ programmer, and
> learning Java in 2000. I got an very heavy algorithm job. I write the
> same code in Java and C++. When the algorithm was relatively simple, my
> C++ code was about twice faster than Java c++/Java = 610/1085. However,
> when my algorithm became extremely heavy iteration, the result was
> c++/Java = 26000/12000. Java was more than twice faster than C++.
>
> I asked several Java experts include Jason Hunter, Daniel Brookshier
> about the question, why? The answers are the same, JIT!!!!
>
Your answer is processor cache relative. It also depends on how well
the C++ optimizer works.
OTOH, D (Digital Mars D) also turns in times faster than C++...probably
for similar reasons. And it's a compiled language. Theoretically, with
a good optimizer, this should be impossible...so I suspect the C optimizer.
Gregory Brown
> Gregory Brown wrote:
> > 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?
Good question. I should do that sooner or later.
> 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.
Most of the time vi is just aliased to vim on newer systems.
(possibly in the ugly compatible mode). Yeah, I liked GVim a lot when
I was still using windows a lot, I find myself using command line vim
even on windows now, just because of my fear of the mouse.
The reason I started using vim maybe 7 years ago was because I opened
up emacs first, couldn't figure out how to edit a file or close it in
five seconds, and then had to kill the process. I opened up vim and
it told me how to do that right away. I think emacs has something to
that effect now.... But that was literally the arbitrary decision I
made. Now I'm just happy enough with vim that what others have shown
me in Emacs I can usually do in vim, so there is no compelling reason
for me to switch. So it keeps me out of holy wars usually, except for
the occasional support of Vim just to be loyal :)
> ArchLinux, eh? I've forgotten -- is that a Debian derivative?
I think it was based on CRUX, actually.
They're *much* less concerned with licensing issues. I'm a bit of an
idealist when it comes to maintaining a free operating system, but
when I have hardware that free drivers barely support without pain,
I'm willing to slip a little. ;)
The real reason why I like ArchLinux though is because it offers the
flexibility and simplicity of something like Gentoo without waiting
weeks for things to compile :) (Yes, gentoo has binaries too, but it's
too tempting to use the shiny build system). Arch does have a decent
build system, when it is needed though.
I can probably fit the applications I use regularly onto my fingers,
so as simple a system as possible is what I crave. :)
M. Edward (Ed) Borasky
> Roseanne Zhang wrote:
>> Everybody here or somewhere else take that for granted: Java is
>> slower than C++, but actually that is not true.
>>
>> I thought so too. However, my computational heavy practice proved, to
>> certain extent, otherwise.
>>
>> Interesting enough, I was a very experienced C++ programmer, and
>> learning Java in 2000. I got an very heavy algorithm job. I write the
>> same code in Java and C++. When the algorithm was relatively simple,
>> my C++ code was about twice faster than Java c++/Java = 610/1085.
>> However, when my algorithm became extremely heavy iteration, the
>> result was c++/Java = 26000/12000. Java was more than twice faster
>> than C++.
>>
>> I asked several Java experts include Jason Hunter, Daniel Brookshier
>> about the question, why? The answers are the same, JIT!!!!
>>
> Your answer is processor cache relative. It also depends on how well
> the C++ optimizer works. OTOH, D (Digital Mars D) also turns in times
> faster than C++...probably for similar reasons. And it's a compiled
> language. Theoretically, with a good optimizer, this should be
> impossible...so I suspect the C optimizer.
folks have neither the patience nor the need for it. There's an
excellent (AMD-64/Intel x86-64 based) reference work on the subject at
http://www.agner.org/optimize/. But for the most common number crunching
tasks, dense matrix operations and Fast Fourier Transforms, I doubt
seriously if anybody's JIT can beat Atlas and FFTW. Tie them, perhaps,
but not beat them.
Joel VanderWerf
> Reid Thompson <Reid.T...@ateb.com> writes:
..
>> Ch is an embeddable C/C++ interpreter for cross-platform scripting,
>> shell programming, 2D/3D plotting, numerical computing, and embedded
>> scripting. Ch is the solution for:
> It's very C-ish but the libraries make the difference. However others
> have written C-Interpreters also:
> Eic (now abondoned)
> Cint http://root.cern.ch/root/Cint.html
> and another one which name I forgot...
There's tcc[1]. It's a C compiler for linux and (maybe) now windows that
is fast enough to use for scripting. This is not quite OT. It would be
great to use libtcc[2] with inline C code when compile time is more
critical than run time. And you don't have to muck with tempfiles.
[1] http://fabrice.bellard.free.fr/tcc/
[2] http://fabrice.bellard.free.fr/tcc/tcc-doc.html#SEC22
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Charles D Hixson
> Chilkat Software wrote:
>
>> - multiple inheritance
>>
>
> C++ mixins anyone? Multiple inheritance with data is evil, but as long
> as you only implement pure interfaces or mixins with it, it's
> acceptable. It's not like a language should restrict its users with
> regards to how horribly they can break the code (and brains) of other
> people reusing their creations, eh?
>
>
When multiple inheritance is done properly, it's not terrible at all. I
point you to Eiffel circa 1995. They had problems, but it WASN'T
multiple inheritance. That was one of their strong points. (Not
claiming that C++'s multiple inheritance is good. I don't know it, and
nobody seems to have anything good to say about it.) Also consider
Python's multiple inheritance. No problems there!!
>> - operator overloading
>>
>
> Except for contexts where the -semantics- of the operator isn't being
> overloaded, just implemented for a case the language doesn't natively
> supported. Matrix multiplication -is- multiplication and a fine use
> case, using, oh, shall we say, << for something that's not a bitshift,
> like pushing data into an array or a stream (which some C++ texts
> ironically discourage) is indeed bad.
>
> *runs for the hills - FAST*
>
>
> David Vallner
> Meditating upon Pots and Kettles
Operator redefinition can be seriously abused. It's also something
that's very powerful when done correctly. I can see an argument for
requiring that the *standard* operators not be redefined. This doesn't
mean that there shouldn't be user defined operators that CAN be treated
just as any other (virtual) function. Perhaps a requirement like "A
user operator must begin with a '|' character and contain no whitespace
in it's name. It may contain any other non-control character, and must
be delimited by whitespace." would suffice.
stef
I didn't realize I was being so cryptic. I guess I'll have to remember
to post to this newsgroup in PLAIN and proper English.
Maybe I should make a script as you suggested.... ;)
--
Charles D Hixson
> ...
> 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/
> .)
>
..
Eiffel USED to be a good language. Unfortunately they started making a
lot of the wrong changes a few years ago. Now... well, it was a small
language to begin with, but it's split into at least three mutually
incomprehensible dialects. Also they've suppressed a lot of the good
features while trying to add compatibility with MS.NET and also while
adding tuples. During this process they broke many of the extant
libraries. If something survives from this, it might again be a decent
language to look at in a decade (perhaps slightly less). Unfortunately,
while they are feuding, other languages are progressing. I note that
Ada 2000 didn't add garbage collection, so it's still out of the loop,
but there are new contenders. My favorite among the compiled languages
is D (Digital Mars D), though I'm also giving a bit of consideration to
Gambit Scheme with Termite. (To be honest, the Scheme thing is probably
on indefinite hold...but Termite sounds quite interesting for a few
years from now when more than two processors/CPU becomes common.
[Currently I have an SMP system with two processors, so this wouldn't
buy me much, but how many CPU slices with my next computer have?])
stef
> On Mon, 20 Nov 2006 01:22:37 -0000, Paul Lutus <nos...@nosite.zzz>
> wrote:
>
> > stef wrote:
> >
> > / ..
> >
> > > i AM reading e/y single post in the thread, believe me.
> > > tx 4 the info.
> >
> > Translation for Earthlings:
> >
> > "I am reading every single post in the thread, believe me. Thank
> > you for the information."
> >
> > French is easier.
> >
>
> How about introducing an [OT][WHINE] subject prefix for this stuff?
> So I know to skip your persistently-off-topic whining, of course...
You do have a point there. Some people are just plain A-N-A-L.....
--
Charles D Hixson
> spooq <spo...@gmail.com> writes:
>
>
>> I would like to suggest the newbie learns VBA. The financial world
>> lives and breathes Excel. VBA is by far the language most likely to be
>> of use to someone entering that world. It's pretty clear programming
>> is a tool for his/her use, rather than something that (s)he wants to
>> do for it's own sake. Having said that, Excel can be viewed as a type
>> of DSL in it's own right, so pushing the boundaries of what can be
>> done 'natively' is a great place to start.
>>
>
> Isn't VBA rather similar to Ruby, anyway?
>
>
rounding errors, outright mistakes. Now granted this was over 5 years
ago now, and they MAY have improved things...but I wouldn't trust it any
more. I actually rewrote things to use Excel macros to avoid doing
arithmetic in VBA. I never did figure out under what circumstances it
would do this, but ever since then I've had an extreme distrust of
everything programmed in MSOffice. I figure that Excel macros are
probably safe...because there would be so many eyes looking at them.
But I'm not sure. I never heard anyone else saying that they had caught
VBA (actually basic for MSAccess2000) in an arithmetic error, but I
definitely did. The numbers were small enough that a third grader would
have seen the error, and there wasn't ANYTHING subtle about the program.
IS it similar to Ruby? I sure hope not.
M. Edward (Ed) Borasky
> Operator redefinition can be seriously abused. It's also something
> that's very powerful when done correctly. I can see an argument for
> requiring that the *standard* operators not be redefined. This
> doesn't mean that there shouldn't be user defined operators that CAN
> be treated just as any other (virtual) function. Perhaps a
> requirement like "A user operator must begin with a '|' character and
> contain no whitespace in it's name. It may contain any other
> non-control character, and must be delimited by whitespace." would
> suffice.
1. Every programmer is entitled to define his or her very own personal
programming language using whatever syntax and semantics makes the job
easy. As long as it's simply a dialogue between one programmer and one
machine, who else cares?
2. *However*, the minute a second programmer, a manager, a user, or
another machine enters the picture, that programmer needs to communicate
with more entities, thus requiring a standardized language *and* a
meta-language for communicating about the language.
3. Programming languages evolved from symbolic logic, algebra and
English, at least here in the USA and in the United Kingdom, where the
initial development was begun during WW II and the early years of the
Cold War. (No, I haven't forgotten about Konrad Zuse or the early
Russian computers -- they just didn't have much influence on programming
languages).
C++ has *way* too many features, both syntactic and semantic, to be of
much use to me. Sure, any programmer can work in a readable subset of
C++, but most don't. Most have their own team dialect of C++. As far as
I'm concerned, there's only one usable dialect of C++ -- ANSI C. :)
M. Edward (Ed) Borasky
> I'm also giving a bit of consideration to Gambit Scheme with Termite.
> (To be honest, the Scheme thing is probably on indefinite hold...but
> Termite sounds quite interesting for a few years from now when more
> than two processors/CPU becomes common. [Currently I have an SMP
> system with two processors, so this wouldn't buy me much, but how many
> CPU slices with my next computer have?])
For small/agile production, it's probably adequate. But if you want an
industrial strength large-product software development environment with
the same underlying concurrency semantics (more or less), you should
probably be looking at Erlang/OTP. It's open source (but standardized by
Ericksson) and has lots of infrastructure (compilers, interpreters,
correctness analysis tools, databases, etc.)
M. Edward (Ed) Borasky
> I stopped using VBA after I caught it making arithmetic mistakes. Not
> rounding errors, outright mistakes. Now granted this was over 5 years
> ago now, and they MAY have improved things...but I wouldn't trust it
> any more. I actually rewrote things to use Excel macros to avoid
> doing arithmetic in VBA. I never did figure out under what
> circumstances it would do this, but ever since then I've had an
> extreme distrust of everything programmed in MSOffice. I figure that
> Excel macros are probably safe...because there would be so many eyes
> looking at them. But I'm not sure. I never heard anyone else saying
> that they had caught VBA (actually basic for MSAccess2000) in an
> arithmetic error, but I definitely did. The numbers were small enough
> that a third grader would have seen the error, and there wasn't
> ANYTHING subtle about the program.
incorrectness. To be fair, some of it came from the need to be upward
compatible from Lotus 1-2-3, which in turn needed to be upward
compatible from VisiCalc. A simple example is the belief in Excel that
1900 was a leap year. I'm not sure what Google query you can use to hunt
down this stuff, but I would not make business decisions based on
anything done with Excel. I use it as an X-Y plotter when I'm in a
hurry, but when I actually care about the numbers, I do things in R.
Hal Fulton
>
> I actually wrote some programs in RATFOR (Rational Fortran) .. man
> I feel old.
Oh, so you own _Software Tools_, eh?
There was an option to order the software, you may
recall... not on CD, not on floppy... on tape.
Big honking reel-to-reel magnetic tape.
There was actually a _Software Tools in Pascal_, too,
which I still have somewhere.
Cheers,
Hal
gregarican
Couldn't you say that about --- hmm, lessee --- C being started at Bell
Labs, Smalltalk being started at Xerox PARC, Java being started at Sun,
etc.? Plenty of languages were started by companies and weren't
collaborative FOSS. That doesn't mean they are inherently flawed or
unworthy of consideration because of that. Now Microsoft being behind
languages such as C# and whatnot could restrict platform implementation
to Windows only. But then again look at Mono. Plus with Microsoft's
WPF/E the intent is to deploy .NET to a variety of devices, not just
Windows PC's. There will be a WPF/E plug-in for web browsers such as
Safari, Mozilla, Opera, etc.
Henry Maddocks
On 19/11/2006, at 12:40 PM, n/a wrote:
> '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....
I have been thinking, and talking, about this quite a bit lately.
Here is my take...
Learn Ruby and C. With Ruby you can write programs fast, with C you
can write fast programs, ie write your system in Ruby and then
rewrite the slow bits in C (rubyinline?).
C++'s days are numbered unless you are doing seriously performance
critical stuff (visualisation, some games, etc). Java is an
improvement but then Ruby is at another level.
M. Edward (Ed) Borasky
>
> C++'s days are numbered unless you are doing seriously performance
> critical stuff (visualisation, some games, etc). Java is an
> improvement but then Ruby is at another level.
C can't? Are the optimizers/code generators better for C++ than they are
for C? I would think a pure C code would have *better* performance,
simply because the language is simpler and easier to optimize.
Jon Egil Strand
> My literacy is just fine, thank you very much. For the sake of speed, I
> use shortcuts.
>
Please do understand that it is not _your_ literacy that's important, it's
_my_ litereacy you should care about. If I am to help you, which I am more
than happy to do if I can, I need to understand.
I understand your question faster and better when communication is clear,
potentially leading to faster and better answers.
So, in advance, thank you for your help.
All the best
JE
--
Jon Egil Strand
David Vallner
>>
>> C++'s days are numbered unless you are doing seriously performance
>> critical stuff (visualisation, some games, etc). Java is an
>> improvement but then Ruby is at another level.
> How does C++ deliver "seriously performance critical" applications where
> C can't? Are the optimizers/code generators better for C++ than they are
> for C? I would think a pure C code would have *better* performance,
> simply because the language is simpler and easier to optimize.
>
And conversely, what's the problem with using C++ instead of C for
performance-critical Ruby extensions or any "fast code"? It's not THAT
much overhead compared to pure C, and I'd bet money on that it'll be
less than the cost of interpreter callouts (in doing data structure
marshalling or manipulating Ruby objects as opposed to not having to for
a straight C++ app) is. The heaps and piles (I know, I can get cream for
that) of inconsistency inside C would make that overhead worth it for
me, as well as the fact that doing robust code is horrible busywork.
Also, for gaming, .NET seems to be gaining hold recently, if the
(sometimes amusingly tangled) dependencies new stuff has on it are a
reliable hint, although I can't tell which of the C# syntax flavours it
is that's being used, obviously.
David Vallner
M. Edward (Ed) Borasky
> M. Edward (Ed) Borasky wrote:
>
>> How does C++ deliver "seriously performance critical" applications where
>> C can't? Are the optimizers/code generators better for C++ than they are
>> for C? I would think a pure C code would have *better* performance,
>> simply because the language is simpler and easier to optimize.
>>
>>
>
> And conversely, what's the problem with using C++ instead of C for
> performance-critical Ruby extensions or any "fast code"?
well-structured) scientific libraries that are written in C++, and I've
even seen a couple of decent OS microkernels done in C++. I simply find
C++ unreadable, which is why I'm such a big fan of SWIG. :)
Paul Lutus
> The corporate-owned, single-vendor product angle is a debatable point.
Not when the vendor can kill it. Microsoft killed Visual Basic. Q.E.D.
> Couldn't you say that about --- hmm, lessee --- C being started at Bell
> Labs, Smalltalk being started at Xerox PARC, Java being started at Sun,
> etc.?
Now that Sun is about to give up control over Java, your list doesn't have
any casualties on it. They're all out in the open, and the originators
can't kill them any more.
It is not about origin, it is about control. Microsoft likes having control,
and (switching topics suddenly) they are about to start in on Linux.
David Kastrup
> Henry Maddocks wrote:
>>
>>
>> I have been thinking, and talking, about this quite a bit
>> lately. Here is my take...
>>
>> Learn Ruby and C. With Ruby you can write programs fast, with C you
>> can write fast programs,
So Muhammad used C? He wrote down the rules for Ramadan, and that may
be called a fast program.
> I like this summary, I'll already used it today :-)
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
gregarican
Paul Lutus wrote:
> Not when the vendor can kill it. Microsoft killed Visual Basic. Q.E.D.
>
Not to belabor the topic, but how is Microsoft killing off VB? I
understand that VBA is being retired, but VB seems to be alive and
kicking through .NET in the 2005 version
(http://msdn2.microsoft.com/en-us/vbasic/default.aspx). Did I miss
something? I know that VB 6.0 is formally losing support as of 2008 but
the .NET implementation is still alive, correct? Even if Microsoft
formally retired VB there are other one-off alternatives that could
take its place. RealBasic for example
(http://en.wikipedia.org/wiki/REALbasic).
Paul Lutus
>
> Paul Lutus wrote:
>> Not when the vendor can kill it. Microsoft killed Visual Basic. Q.E.D.
>>
>
> Not to belabor the topic, but how is Microsoft killing off VB?
It's dead, and Microsoft killed it. First they killed it, then they stopped
offering support for it, all to get people to move on to new Microsoft
products.
http://www.developer.com/net/vb/article.php/3422891
http://www.sqlmag.com/Article/ArticleID/43158/sql_server_43158.html
http://www.bitwisemag.com/copy/features/vb6/strangedeathofvb.html
Apart from these VB post-mortems, the point I am making is that, no matter
which variety of Microsoft language one adopts, it is only a matter of time
before Microsoft tries to migrate you to the latest fad, if necessary by
halting support for the prior product.
> I
> understand that VBA is being retired, but VB seems to be alive and
> kicking through .NET
Unfortunately, and as these articles show, VB/.NET is not the same language.
For those who only know one language, e.g. those firmly in the Microsoft
camp, the transition is very difficult.