Re: Whats the best language to learn...



"cr88192" <cr88192@xxxxxxxxxxxxxxxxxx> writes:
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++.

On processors designed to run C and unix. That would be the contrary
on processors designed to run Lisp and Lisp OSes.

What you call "overhead" is actually the virtual machine filling out
the mismatch between an Intel processor and a LispMachine processor.


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.

That's not true. Application binaries are not standalone. (Only
kernels and microcontroler firmwares could be considered standalone).

[pjb@hubble src]$ ldd /bin/ls
linux-gate.so.1 => (0xffffe000)
librt.so.1 => /lib/librt.so.1 (0xb7ede000)
libacl.so.1 => /lib/libacl.so.1 (0xb7ed6000)
libc.so.6 => /lib/libc.so.6 (0xb7da6000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7d8f000)
/lib/ld-linux.so.2 (0xb7ee8000)
libattr.so.1 => /lib/libattr.so.1 (0xb7d8a000)

[pjb@hubble src]$ ls -l /lib/libc.so.6
lrwxrwxrwx 1 root root 13 Mar 20 03:20 /lib/libc.so.6 -> libc-2.6.1.so*
[pjb@hubble src]$ ls -l /lib/libc-2.6.1.so
-rwxr-xr-x 1 root root 1237276 Mar 20 03:19 /lib/libc-2.6.1.so*

The dependencies for applications are about the same volume for C
application or Lisp applications.


But actually the problem is that you are comparing apples with
oranges. On a LispMachine processor, it's the C applications that
need to be hosted, that need to bring around a bulkier runtime
implementing pointer semantics over a clean checked environment
implemented in hardware.


What you are saying is that for the poor processors Intel provides us,
C is a better match (that is, it is a better assembler) than a high
level programming language such as Lisp.

If at the beginning of the Workstation age LispMachines had had the
non-technical conditions to let them compete favorably against unix,
processors makers would have developed Lisp/LispMachine
microprocessors instead of C/unix microprocessors, and today, it
would be harder to run C and its class of programming language than
lisp, java, ruby, etc.


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

There was.


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.

Lisp has been invented on computers that had 32 Kword memories at
most, where if you hooked a modem with a 4K buffer you already used up
one eight of the available memory.


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.

On these older machines, it would take three 36-bit words.
On a 8-bit processor, that would take 12 bytes. (six 16-bit words).


Notice that this is exactly the same size as for the equivalent
structure in C:

struct node {
short int value;
struct node* next;
};





Anyways, these considerations about memory are not totally
irrelevant, in that nowadays, the processors have become sufficiently
powerful and memories large enough, that nobody can afford anymore to
pay for bit- and cycle- optimizing C programmers. Hence the
development of checked-environment programming languages such as java,
python, ruby, that are but a step from C++ to Lisp, as confessed for
example by the designer of Java. (for the other designers you would
have to psychoanalyze them to get the proof, but it's obvious enough
;-)).


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.

Indeed, it's done. You can implement for example graphic manipulation
algorithms running faster in sbcl than in gcc.
http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf


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



on the Linux end, C is still fairly common for apps as well.

But I notice a number of applications and tools developed in better
programming languages. (eg. MLDonkey in ocaml, darcs in Haskell, etc).


--
__Pascal Bourguignon__ http://www.informatimago.com/

"You can tell the Lisp programmers. They have pockets full of punch
cards with close parentheses on them." --> http://tinyurl.com/8ubpf
.



Relevant Pages

  • Re: Why Lisp is too hard for me to use
    ... > standard for a family of implementations to single-vendor languages. ... > library providers only have to care about one implementation, ... Common Lisp has different goals in this regard. ... There are indeed multiple Java ...
    (comp.lang.lisp)
  • Re: Symbol Grounding Problem
    ... particular programming language at all. ... powerful" than Java. ... I didn't directly address the question of comparing Lisp and Java. ... what does one mean by "powerful" in a programming language? ...
    (comp.ai.philosophy)
  • Re: CL+J 0.1 released!
    ... CL+J and jfli run on different lisp implementations, ... CL package shadowing the Java packages and tries to keep the syntax to ...
    (comp.lang.lisp)
  • Re: Crash Course To The Roguelike Development
    ... Seriously, Common Lisp guys solved all OOP problems 20 years ago, why people use ... half-assed OO implementations of C++ or Java? ...
    (rec.games.roguelike.development)
  • Re: Programming for 14 year old (was Programming for 13 year old)
    ... Delphi is good for first "real" programming language to learn. ... Command line java, c++, lisp etc, are good ...
    (comp.programming)