Re: Whats the best language to learn...


"Pascal J. Bourguignon" <pjb@xxxxxxxxxxxxxxxxx> wrote in message
news:873al0h9ca.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx
"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.


yes, this is very possible...
so, yes, an ideal processor for a lisp machine would probably be almost
anything other than an 8088 or 286. on a 386, it is much better, but a C
like language still has a strong advantage (given that x86 uses
byte-addressed memory, has native support for variable-sized value types,
and so on).



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).


yes, however, they are standalone from the POV of the OS and the user, that
they depend on the OS is ignorable.

for example, if a LISP-based OS were common, it "could" work.

but what about on MS-DOS?... it is much less likely...


for now, I am assuming a history where x86 and MS-DOS were "inevitable",
wheras languages were given free choice.

now, most probably, had anything other than C gained dominance, it would
have been Pascal-based.
the result being that, now, we would not have something like Java as a
popular OO language, rather a language about like that of Delphi would have
taken its place.

this said, C and Pascal are not strictly balanced either WRT the processor
(Pascal being typically a little less efficient, and having less capable
pointer facilities access...).

adjusting these, the language would have possibly ended up more like a
hybrid of Pascal and C (like, maybe Pascal-like syntax with C-like
semantics...).


[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.


yes, this can be argued.
none the less, C had a strong advantage, for working so nicely on the kinds
of HW that came to dominate...

even then, you are looking at something modern (Linux), and not something
historical (such as MS-DOS).



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.


yes, however, I doubt that historical market forces could have produced all
that much different of an outcome...

had, for example, a Motorola-based chipset came into dominance instead (or
the Z80, or much of anything else), the outcome would have likely been about
the same.

I doubt that it could have been the case that the right HW could have
existed at the right time and the right place, to have made CL become the
dominant language (even ignoring other probable shortcommings...).


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.


potentially, considering things much further in the past.

however, this would still be assuming that LISP processors were more cost
effective to produce (I suspect that, initially, the x86 architecture, as
well as that of many of its competitors, were designed with the primary
concerns being that of cost...).

so, the question is then one of whether it could have been cheaper (or at
least within a margin of plausibility) for it to have gone otherwise.



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

There was.


yes, ok.
my attempts at looking up info had not yeilded much (what info I found had
suggested 32-bit DOS/DPMI implementations, ie, 386 and newer, but not 8088
or 80286).



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.


however, the word size is important.
if WORD=16 bits, this is 64KiB.
if WORD=32 bits, this is 128KiB.

however, to make LISP work here (assuming the VM were to actually exist on
the machine), then it would have to exist in ROM (insufficient memory for an
in-ram VM).


now, assuming a ROM-based VM, it possible a LISP (though probably not CL)
could have worked effectively. the next cost then to consider, is whether or
not early PC-makers would have included such a VM (the ROM often being
fairly cramped), and whether developers would have made use of it.

I have some doubts here.


another historical consideration (maybe relevant) would have been one of
whether Apple could have been cost-competitive with IBM, clones, and
friends...

(this matters, since vs PCs, Apple had a good deal more in their ROMs).



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;
};



if we assume 16-bit words, which I did initially, but came to the view that
they would not have worked effectively (at least 24 bits would have been
needed, but people would have likely used 32).

basically, we need both sufficient bits to hold the tag, as well as to index
addressable memory.

now, had 16 bits been used, best case, we would have a heap limited to
128KiB.

for example:
0: pointer (cons/obj)
10: fixnum
1100: literal
....

I am assuming here non-segmented memory (getting segmented memory to work
effectively in a system like this would be painful, likely requiring some
sort of proxy/jump mechanism, ...).

6 bytes per cell could have also worked, but is unlikely since in is not a
power-of-2.
so, 8 bytes is the likely size...





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
;-)).


yes, I was considering this as well.

however, had Java come around in the early 80s and targetted PCs, it likely
would have died where it stood...

Java thus survived because it was on the thin edge of plausibility near the
time it was released, and then was helped along by them dumping huge amounts
of money into marketing and similar...

of course, much later and it would have faced much more competition, and
thus would not have gained so much popularity.



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


as noted, I was still being historical, rather than modern.

could it have worked effectively on an 8088 or 286?...



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


doubtful.

CL is not likely to enjoy such popularity, since the window of opportunity
back in the 80s was not available on low-end HW (the 80s were critical, and
they have passed), and in modern time it is unlikely to compete effectively
even vs Python, much less ECMAScript.

the primary reason for this is syntax and functionality. most of what LISP
could do, can already be done in Py and JS, and both of them have syntax
much closer to the established players (C and friends) than does CL.

on these grounds, JS and friends have the clear syntactic advantage, and
have become well entrenched in the current likely critical places, that JS
is likely to become the language of coice.

C and C++ are unlikely to move off the map apart from the possibility of a
critical redesign of the funamentals of computing, and so I suspect they are
likely to hold on fairly safe in a specific niche (it is much the same as
why ASM never dies...).

very few people actually like ASM, almost no one considers it the future of
computing, but it stays around none the less.


C and C++ are likely to remain around, occupying a similar part of the
landscape as ASM.
they will probably slip somewhat from public awareness, but they will not
likely go away anytime soon.

C# and Java, however, lack this particular advantage, and so within 10 years
will probably fall into steady decline.




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).


potentially, but these are infrequent.

may as well point out that GIMP uses Scheme for scripting, and EMACS has EL.
doesn't change much though...



.

Relevant Pages

  • Re: Is anybodys favorite computer programming language not included here?
    ... to talk about getting me some paying work writing Java classes. ... and could be copied to a script (as in Java BeanShell or Lisp PROG). ... >> please post a followup saying what language it is, ... Server: "Mother, ...
    (comp.programming)
  • Re: Be afraid of XML
    ... | that Java is an engineering masterpiece: ... | Interestingly the same is historically true for Lisp: ... BLISS (Basic Language for the Implementation of Systems Software) ...
    (comp.lang.lisp)
  • Re: Oft-shared (perhaps?) Impressions of a Lisp Newbie
    ... Lisp community that lexical closures were the right thing. ... Did they agonize over the decision to start a new language ... prefer Java to C++. ...
    (comp.lang.lisp)
  • Re: Joel hammers the final nail into Lisps coffin
    ... Indeed, if you are an inexperienced Lisp programmer, you will probably ... Well yes if you a are super brilliant Java programmer you'll be ... Of course you can use some language compiling to Java which offers ...
    (comp.lang.lisp)
  • Re: Python syntax in Lisp and Scheme
    ... Lisp also has this to a certain degree: ... what language "paradigm" you are currently using. ... > conjecture is that additional syntax can make some things easier. ... I don't know a lot about the specifics of shared memory, ...
    (comp.lang.python)
Loading