Re: Whats the best language to learn...


"santosh" <santosh.k83@xxxxxxxxx> wrote in message
news:g8e4h4$v27$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
cr88192 wrote:


"gremnebulin" <peterdjones@xxxxxxxxx> wrote in message

news:68b2df7d-ab3c-4463-b021-37c29757b958@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 18 Aug, 20:55, p...@xxxxxxxxxxxxxxxxx (Pascal J. Bourguignon)
wrote:

For CS professionnaly, I'd advise scheme as a teaching language and
Common Lisp as a industry strong programming language.

What for everything? Database access? GUis? Device drivers?

personally, though CL is interesting, I would not consider it that
general purpose of a language.

Some languages simply don't "take off" in the wide world even though
they are technically as good as (if not often better) than their more
popular counterparts.


but, beyond just the merits of the languages themselves, one also needs to
consider the merits of the typical implementations.

CL implementations are typically hosted, and have traditionally carried a
much higher overhead than, for example, C and C++.

for C and C++, most of the content (code+data) is the app itself (the
runtime traditionally being a fairly small part, helped in part by the
linker), as well as most of the memory being for the app, and not for the
runtime. typically, CL implementations have had comparably bulkier runtimes,
which would hurt a bit more on much older and much slower systems (this has
changed in modern times due to the relatively low price of both memory and
disk storage).

another major difference is in terms of style, where CL has typically been
hosted (one needs a CL VM at the destination, itself not necissarily small
in times since past), whereas C and C++ have typically focused on standalone
binaries. the result being that, while one system is getting apps to
customers, another is not.

I am also remembering that back in DOS days, it was a common technique for
people to make use of tweaky little hacks to self-compress their apps,
decompressing them either at load time, or decompressing bits and pieces as
needed at runtime (like, a whole bunch of code is present but only some of
it may be needed, the app partly playing a shuffle game decompressing some
pieces, discarding others only to be decompressed again later, all to make
the greatest effect of the maybe 400 or 500 kB of memory still left over).


considering the problem hypothetically, I don't know if there were any
real/practical 16-bit DOS CL implementations.

now, if a good solid 150 or 200 kB (or more) is needed by the
implementation, and considering the naturally bulkier nature of the data
itself (likely, 6 or 8 byte cons-cells, ...) things are not looking good.

for example '(1 2 3) may take 24 bytes, but in those same bytes you could
fit 12 near pointers, 12 16-bit integers, or 6 far pointers.

so, if there were implementations, I doubt they were all that practical
(more like trying to do ones' shopping in a tank...).


oh yes, and I still remember EMS. actually, when I was still young (back in
elementary school), I had something like a 2MB or 4MB EMS card or such (my
main computer having been an older 8088...).


now, things are a little better if one considers a Protected Mode
implementation (and 8 or 16 MB of RAM), but until recent years, it is still
likely to have been FAR behind on the memory density and overhead fronts,
where C or C++ is getting a good deal of real work done in this memory, and
CL is battling with making it all fit well and having enough left over to
actually do much of anything practical with it.


even now, this issue is lingering, where the inherent costs in terms of
memory density are far from trivial (although similar costs are present if
one were to try to develop "industrial-strength" apps in Python).


now, this is ignoring the possibility of statically compiling CL into a much
denser language (could have been done for all I know), possibly in the
process giving up a good deal of what makes LISP be LISPy (very likely, many
structures would have to be made either immutable, or severely restricted),
and I still have major doubts as to whether or not it could have been
competitive with C or C++ on these grounds.



now, however, things are a little different, but there are still plenty of
other things it *didn't* have going for it.

now, I suppose C and C++ "could" have lost, but most likely it would have
been to something fairly similar (for example, had C lost to Pascal, ...).

actually, I suspect one of the major things C and C++ had going for them
were their "down to the metal" operatation, and their very capable pointer
facilities (I personally don't know of anything other languages, apart from
ASM, so finely capable of elaborate pointer manipulation...).


in modern times, things have shifted a bit, and run-time compilation is now
a far more practical option (though I don't think this will be of much help
to CL, which has most likely already lost its window).

I suspect that within the near future, languages like Python or ECMAScript
may start to somewhat encroach on much of the domain currently held by Java
and C++ (actually, it is my intuitive guess that ECMAScript is likely to
make far more inroads here, in Python's case its syntax likely serving as a
detractor, wheras ECMAScript has similar capabilities but without this
issue, and so is far more likely to compete with the syntactically similar
Java and C++).

very likely, this could be a downside for C#, which would at this point be
competing with both languages (but it could potentially overpower Java).

so, a guesstimation:
2013 language rankings: C++, ECMAScript, Java, C, C#
2018 language rankings: ECMAScript, C#, C++, C, Java

note that ECMAScript here includes both JavaScript and ActionScript (Flash)
as variants, but will likely have moved well into the world of primary
development languages as well (for example, people running apps on their
desktop, which were written in Flash...).

I don't predict will decline that much, basically holding a fairly long
niche as a systems and "backend" language (in the later timeframe, C++ will
likely have been largely displaced in terms of app development, to some
degree operating within a similar niche to C).

however, I don't expect Java will be able fit into this niche, and once the
current-breed languages (Java and C# in particular) go into decline, it is
possible not much will stop them.


at this point, there may be some new rising languages based on technologies
I am not currently aware of...


so, I think for most industry uses, C or C++ is probably best
(industry I think is more leaning towards C++, wheras the Open-Source
/ Linux side of things is much more biased towards C in general).

Only on the system side. With end-user applications, C++ and Java are
becoming more common, as far as I can see.


on the Linux end, C is still fairly common for apps as well.
on the Windows end, C++ is much more common in general.


Java is also fairly popular, but as noted, it is more for pure user apps,
and much less so for more "intensive" apps (games in particular). it is
generally acceptably though for many tasks, given anymore it is usually not
"that" much slower (within around 2-4x slower AFAIK).

Java has a few selling points though, which I suspect help keep it around.


for some cases or industries (portable app development, ...), Java may
be a good option.

Java is not a bad option for desktops, servers and mobiles.


yes, agreed here.
this is partly what I meant by "portable app development".


<snip>

for low-level development (kernels, drivers, ...), or lower-end
embedded systems, often C is about the only real practical option
(well, that and assembler...).

And this really is the strength of C. The possibility of fast, yet
portable, system code. Uptil the mid-80s it was taken for granted
that "serious" system code will *not* be portable and using HLLs while
interesting, was academic. Then C came along and changed all this. Now
it's rare that system software needs to be written whose bulk cannot be
done in C.


yes.


[ ... ]

languages like Python and friends I doubt are good options for
"industrial strength" programming.

Note that Google uses Python extensively with their servers and if
that's not an example of "industrial strength", then what is?

They are great for constructing "glue" code and lots of little utilities
that would take too long to do absolutely robustly in something like C.



my definition of industrial strength may be different then.

python will perform very admirally for these kinds of things (where the
bottleneck is not likely to be within the apps' program logic or raw
processing abilities).

for example C vs Python for tasks like huge amounts of string processing or
messing with DOM trees, is not likely to be dramatic (since the big
expensive parts are still written in C in both cases, the overhead is payed
for in other ways).


if, however, the app is "too the metal" with respect to system performance
(such as in a 3D game, physics engine, ...), the bottleneck is likely to be
located within the program logic itself, making it a much less practical
option.

something like Python is much less likely to be considered if one has a good
deal of personal experience running into the raw performance limitations of
modern computers wrt processor-intensive apps...


<snip>



.

Relevant Pages

  • Re: How to develop for Linux
    ... Java written apps. ... written with these languages. ... attempting to make), then the only applications we should be creating, ...
    (borland.public.delphi.non-technical)
  • Re: Python has truly triumphed
    ... The main languages chosen by industry: C++, Java and C#. ... there is more COBOL than all three of those combined. ...
    (comp.programming)
  • Re: Python has truly triumphed
    ... The main languages chosen by industry: C++, Java and C#. ... there is more COBOL than all three of those combined. ...
    (comp.programming)
  • Re: Importance of Computer Science degree?
    ... > still a terrible idea to take a language designed for portability and ... They produce portable languages, therefore they are scared of portable ... As for 'shoehorning' stuff onto Java, ... They got to choose between portable apps that looked like typical Java ...
    (comp.programming)
  • Re: To C or not to C?
    ... I can give you some pros and cons for several Microsoft languages (and no ... but it won't work with future Windows ... folders, copy or delete files, modify the device registry, launch apps, ... all I need to know is where to get good OBJECTIVE advice on choosing a programming language for the application I'm going to develop for WM devices. ...
    (microsoft.public.pocketpc.developer)