K
Kaz Kylheku
Paul said:
Right. What these have in common with Lisp is that they use manifest
typing, whereas Lisp uses latent typing. But after that, they mostly
diverge.
Right. What these have in common with Lisp is that they use manifest
typing, whereas Lisp uses latent typing. But after that, they mostly
diverge.
P
Paddy
Yes. I changed my opinion on advocating Python having macros in one
of our long threads on the subject. Maintainance counts.
This is new to me. In fact, for the compiled languages available to me.
Using them *first* would be the difficult choice.
Yep, I think I read that one. To (over), summarise what I read: the
author
states that waiting for perfect will often give the advantage to a
competitor who ships with 'good enough'. The author gives examples.
The skill to me resides in knowing what is good enough ;-)
I can't vouch for your Russian friend, but yes I do think that the
gumph on
exponential time algorithms versus linear time algorithms makes sense.
I started using my first scripting language AWK whilst using C and went
through only using it for small tasks to using it for more and more
because it was fast enough. In my case I'd be finishing some task in
a much shoter time giving my customers solutions that might take 10
minutes to run instead of ten seconds, but they were using it in a flow
that took maybe overnight to run.
Unlike Lisp, Python does not have a ubiquitous compiler. It is
therefore
made to interface nicely with compiled languages. Other compiled
language users see the need for dynamic interpreted languages like
Python and maintain links Python such as the Boost Python C++
wrapper. IronPython for .NET, Jython for Java.
Lisp is its own interpreter and compiler, which should be a great
advantage, but only if you don't make the mistake of ignoring the
wealth of code out there that is written in other languages.
Python is newbie-friendly. Part of that is being accessible.
Doctest is about a novel way of using a feature shared by Lisp, that is
docstrings. Testing is important, usually not done enough, and doctests
are a way to get people to write more tests by making it easier. Does
Lisp have similar?
Does Lisp have a doctest-like module as part of its standard
distribution?
Or are you saying that If you ever needed it, then it would be trivial
to
implement in Lisp, and you would 'roll your own'? There are advantages
to
doctest being one of Pythons standard modules.
- Paddy.
K
Kay Schluehr
Yes, this structure of argument is the same in *any* discussion about
language design and feature integration. The solution could be laissez
faire but then you have to counteract creating standards for a minimal
contract social. In either way you cut down language feature diversity
and feature implementation redundancy, something macros strongly
encourage. So Lisp is always the right language to start with but what
is the right language to end with? The answer is BASIC and although the
reference to the historical BASIC language is not accidental, I
actually mean all kind of general purpose languages that aim to
facilitate programming in the first place. That's why Python = BASIC or
more accurately Python = ABC. Of course you can start with BASIC too,
instead of Lisp, or Ruby and quote Yukihiro Matsumoto who just wants
happy users - from the very beginning and not just after one month,
when one starts looking through the jungle of parens ( Ken Tilton ) or
perform any other cognitive transformation to ease the pain.
While Pythonistas might defend their language with all kind of typical
nerdish idiocy, Lispers try to convince Pythonistas to be unhappy,
because they lack X, Y and Z and recommend Lisp as the cure. But just
like a beautifull woman, Pythonistas stay unimpressed and do respond:
no, I don't lack anything, I am complete; stay away from me with your
weirdness!
K
Kaz Kylheku
Paddy said:
I pity the hoplelessly anti-intellectual douche-bag who inflicted this
undergraduate misfeature upon the programming language.
This must be some unofficial patch that still has a hope of being shot
down in flames, right?
R
Ravi Teja
Kaz said:
Sour grapes. Eh
Or were you going to follow up with some intellectual argument to
support your adjectives?
1. pity
2. hopelessly
3. anti-intellectual
4. douche-bag
5. inflicted
6. undergraduate
7. misfeature
8. unofficial patch
9. shot down in flames
That's a lot of hate in 2 sentences for judging a novel feature you
barely came across.
J
Juan R.
(e-mail address removed) ha escrito:
I cannot understand why. It is like if you claim that packaging things
in boxes is difficult to learn.
HTML and XML have more brackets than LISP (usually double) for
structuring data and everyone has learned HTML.
I cannot understand why. It is like if you claim that packaging things
in boxes is difficult to learn.
HTML and XML have more brackets than LISP (usually double) for
structuring data and everyone has learned HTML.
K
Kaz Kylheku
Paddy said:
No, and it never will.
The wording you are using betrays cluelessness. Lisp is an ANSI
standard language. Its distribution is a stack of paper.
There isn't a ``standard distribution'' of Lisp any more than there is
such a thing of C++.
There are also advantages in being able to tell idiots who have
terrible language extension ideas that they can simply roll their own
crap---and kindly keep it from spreading.
This is generally what happens in intelligent, mature programming
language communities. For instance, whenever someone comes along who
thinks he has a great idea for the C programming language, the standar
answer is: Wonderful! Implement the feature into a major compiler like
GCC, to show that it's feasible. Gain some experience with it in some
community of users, work out any wrinkles, and then come back.
In the Lisp community, we can do one better than that by saying: Your
feature can be easily implemented in Lisp and loaded by whoever wants
to use it. So, i.e. don't bother.
Lisp disarms the nutjobs who want to inflict harm on the world by
fancying themselves as programming language designers. They are reduced
to the same humble level as other software developers, because the best
they can do is write something which is just optionally loaded like any
other module, and easily altered beyond their original design or
rejected entirely. Those who are not happy with the lack of worship run
off an invent shitty little languages for hordes of newbies, being
careful that in the designs of those languages, they don't introduce
anything from Lisp which would land them in the same predicament from
which they escaped.
T
Tim Peters
[Paddy]
[Kaz Kylheku]
As a blind misshapen dwarf, I get far too much pity as it is, but I
appreciate your willingness to share yours. If you like, feel free to
give this precious gift to another. I get the impression that pity is
something you don't feel often, and it would be a shame to waste it.
Alas, no. It was secretly snuck into Python's standard library in the
2.1 release (2001), and although we've done our best to hide it, it's
widely used now. Strangely enough, it's especially popular among
intellectuals ;-)
[Kaz Kylheku]
As a blind misshapen dwarf, I get far too much pity as it is, but I
appreciate your willingness to share yours. If you like, feel free to
give this precious gift to another. I get the impression that pity is
something you don't feel often, and it would be a shame to waste it.
Alas, no. It was secretly snuck into Python's standard library in the
2.1 release (2001), and although we've done our best to hide it, it's
widely used now. Strangely enough, it's especially popular among
intellectuals ;-)
T
Timofei Shatrov
But, you have to admit that it looks horrible (at least at the first glance). If
there's some programming style that I absolutely can't stand, it would be the
one where programmer writes a huge block of commentary describing what a
function does, followed by one-liner of code, which contains the same amount of
information in itself. With doctest it is even worse, because examples also
contain superfluous information. Everyone can just copy-paste the code in REPL
and see what happens when you execute it. Besides that, there are many reasons
why tests should be stored in a separate file, or at least not in the same
function that they are testing.
Also Wikipedia article contains some "Cons of doctest" that look pretty nasty:
* Large numbers of tests in a docstring can become unwieldy. docstrings
should be pruned and excised tests put in external file(s).
* Tests producing large amounts of output make for large docstrings.
* Debugging integration is far from perfect
* 'print' (or 'trace') debugging is not possible (because it intervenes with
the test result)
* Test setup has to be either copied or hidden away from the test, making
the overall environment harder to understand.
* Many of the complex assertions of existing unit tests frameworks do not
exist, (e.g. assertRaises, assertEquals, assertAlmostEqual, ...), although some
are not necessary.
* Failing assertions are very hard to debug (Especially in Web applications
if the expected result is a web page with a lot of HTML)
It's not surprising that no one uses this stuff for serious work.
M
Michele Simionato
Timofei said:
Well, I replaced all my unittests with doctests long ago, and I am not
the only one following this way
(see the Zope 3 project for instance).
Michele Simionato
G
greg
There's no way you could compile Python to efficient
machine code just by macro expansion. You'd also need
some very heavy-duty type inferencing.
Python is extremely dynamic, even more so than Lisp.
That's why compiling Python is hard, not because it
doesn't have macros.
G
greg
Ken said:
That's not how I would describe the experience
I have when I'm editing Python code.
When moving a set of statements in Python, you
are usually selecting a set of complete lines,
cutting them out and then pasting them in
between two other lines somewhere else.
Having done that, the lines you've just pasted
in are selected. Now it's just a matter of
using using your editor's block-shifting commands
to move them left or right until they're in
the correct horizontal position.
I find this to be quite a smooth and natural
process -- no "thrashing" involved at all.
Having edited both Lisp and Python code fairly
extensively, I can't say that I find editing
Python code to be any more difficult or error
prone.
On the plus side, Python makes less demands on the
capabilities of the editor. All you really need
is block-shifting commands. Bracket matching is
handy for expressions but not vital, and you
certainly don't need bracket-based auto-indenting.
R
Ravi Teja
Timofei said:
You Sir, are no fan of Literate Programming
.And doctest automates such REPL tests. Like macros, don't knock it till
you try it.
You need not have doctest as a part of source code. You can also create
a separate documentation file that contains prose as well as tests
intervening.
http://www.python.org/doc/lib/doctest-simple-testfile.html
Combine it with ReStructured Text and you have a wonderful
documentation and testing solution in one place. Personally, I like
this a lot better than Javadoc style documentation where usage examples
are often absent.
Of course, doctest is hardly the ultimate testing solution. But it does
an admirable job for many cases where you don't need to setup elaborate
tests.
I have seen enough libraries that use doctest. Zope, Twisted and Paste
are some of the popular Python projects in that use it. Epydoc supports
it as well.
P
Paddy
Oh wow! So much invective. So little reason.
Doctest is very easy to try.
1/ Get python installed on your machine:
http://wiki.python.org/moin/BeginnersGuide/Download
2/ Use a tutorial to get up to speed in Python:
http://wiki.python.org/moin/BeginnersGuide/Programmers
3/ Try Doctest.
http://www.python.org/pycon/dc2004/papers/4/
http://en.wikipedia.org/wiki/Doctest
http://www.python.org/doc/lib/module-doctest.html
Try doctest and you will see why it is not.
- Paddy.
A
Alex Mizrahi
(message (Hello 'Paul)
(you :wroten '(10 Dec 2006 21:06:56 -0800))
(
??>> read the book.
PR> Which book?
Paul Graham's "On Lisp".
or just refreshing your knowledge about CPS transformaction might be
sufficient.
i've found very good explanation of CPS transformaction in the book
"Programming Languages:Application and Interpretation"
Shriram Krishnamurthi
Brown University
it's not Common Lisp but Scheme though, but it's very interesting since it
shows how continuations can be used for better web programming.
both books are available online.
??>> but once you convert it to CPS, you just operate with closures. stack
??>> is just a lexical variables caught into closure. do you know what does
??>> CPS mean at all??
PR> I once understood the basic notion but confess to have never been
PR> clear on the fine points. However, I don't see how you can do it with
PR> CL closures since CL semantics do not guarantee tail recursion
PR> optimization. If you code a loop with closures and CPS, you will blow
PR> the stack.
most CL implementation do tail call optimization, unless you're running
debug mode -- in that case you'd prefer full stack.
however, it's possible to implement tail call optimizations in non-tail-call
optimizing language. i think it's called trampolined style.
example can be found in PAIP book: interpreter of Scheme is implemented in
Common Lisp.
CPS transformation found in ARNESI implements that -- you might notice on
the macroexpansion i've showed in prev example function drive-cps. it's
defined following way:
(defun drive-cps (cps-lambda)
(catch 'done
(loop for f = cps-lambda then (funcall f))))
additional (lambda () ...) is inserted in the code to delay evaluation. code
becomes like this:
(drive-cps
(block1)
(lambda () (block2))
thus for each CPS tear-point it's able to throw stale stack frames away.
here's an example of CPS-transformed eternal loop
(macroexpand '(with-call/cc (loop for i upfrom 1 do (print i) do (call/cc
(lambda (cont) cont)))))
(DRIVE-CPS
(LET ((#:CPS-LET-I-1712 1))
(DECLARE (TYPE NUMBER #:CPS-LET-I-1712))
(LABELS ((#:TAGBODY-TAG-NEXT-LOOP-1713 ()
(PROGN
(PRINT #:CPS-LET-I-1712)
(LAMBDA ()
(FUNCALL #'TOPLEVEL-K
(FUNCALL #'(LAMBDA (CONT) CONT)
(MAKE-CALL/CC-K
(LAMBDA (#:V-1717)
(DECLARE (IGNORE #:V-1717))
(PROGN
(PROGN
(SETQ #:CPS-LET-I-1712
(1+ #:CPS-LET-I-1712)))
(#:TAGBODY-TAG-NEXT-LOOP-1713))))))))))
(#:TAGBODY-TAG-NEXT-LOOP-1713))))
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
(you :wrote
n '(10 Dec 2006 21:06:56 -0800))(
??>> read the book.
PR> Which book?
Paul Graham's "On Lisp".
or just refreshing your knowledge about CPS transformaction might be
sufficient.
i've found very good explanation of CPS transformaction in the book
"Programming Languages:Application and Interpretation"
Shriram Krishnamurthi
Brown University
it's not Common Lisp but Scheme though, but it's very interesting since it
shows how continuations can be used for better web programming.
both books are available online.
??>> but once you convert it to CPS, you just operate with closures. stack
??>> is just a lexical variables caught into closure. do you know what does
??>> CPS mean at all??
PR> I once understood the basic notion but confess to have never been
PR> clear on the fine points. However, I don't see how you can do it with
PR> CL closures since CL semantics do not guarantee tail recursion
PR> optimization. If you code a loop with closures and CPS, you will blow
PR> the stack.
most CL implementation do tail call optimization, unless you're running
debug mode -- in that case you'd prefer full stack.
however, it's possible to implement tail call optimizations in non-tail-call
optimizing language. i think it's called trampolined style.
example can be found in PAIP book: interpreter of Scheme is implemented in
Common Lisp.
CPS transformation found in ARNESI implements that -- you might notice on
the macroexpansion i've showed in prev example function drive-cps. it's
defined following way:
(defun drive-cps (cps-lambda)
(catch 'done
(loop for f = cps-lambda then (funcall f))))
additional (lambda () ...) is inserted in the code to delay evaluation. code
becomes like this:
(drive-cps
(block1)
(lambda () (block2))
thus for each CPS tear-point it's able to throw stale stack frames away.
here's an example of CPS-transformed eternal loop
(macroexpand '(with-call/cc (loop for i upfrom 1 do (print i) do (call/cc
(lambda (cont) cont)))))
(DRIVE-CPS
(LET ((#:CPS-LET-I-1712 1))
(DECLARE (TYPE NUMBER #:CPS-LET-I-1712))
(LABELS ((#:TAGBODY-TAG-NEXT-LOOP-1713 ()
(PROGN
(PRINT #:CPS-LET-I-1712)
(LAMBDA ()
(FUNCALL #'TOPLEVEL-K
(FUNCALL #'(LAMBDA (CONT) CONT)
(MAKE-CALL/CC-K
(LAMBDA (#:V-1717)
(DECLARE (IGNORE #:V-1717))
(PROGN
(PROGN
(SETQ #:CPS-LET-I-1712
(1+ #:CPS-LET-I-1712)))
(#:TAGBODY-TAG-NEXT-LOOP-1713))))))))))
(#:TAGBODY-TAG-NEXT-LOOP-1713))))
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
P
Paul Rubin
Alex Mizrahi said:
Oh ok, someone mentioned that was online, and I just bookmarked it.
I'll look at it when I'm more awake.
Scheme probably makes more sense for this type of book--it's simpler than CL.
I'd rather stick to what the CL standard says, rather than what some
implementation might happen to do. CL does not guarantee TCO so these
code transformation schemes mustn't rely on it.
This book doesn't seem to be online. But anyway I think you mean,
compile the Scheme code into one giant CL function, which is no longer
really a clean mapping of Scheme to CL, it's just writing an
interpreter. And I think that interpreter has to do its own
management of environments rather than letting the CL runtime do it.
So basically it says CL is turing-complete and can do everything,
which we already knew ;-).
Part of the problem I'm having with these examples is I don't know all
the different macros being used. But I think I understand one part of
what was confusing me before: your call/cc macros depend on a
nonstandard feature of some CL implementations. You can't write a
call/cc macro in standard CL--you instead have to write something that
transforms the entire program.
I think even with TCO though, you still can't do coroutines with CL
macros (but you can do them with real call/cc). The point is that you
have to do something like TCO on calls that are not tail calls and
actually have to return. You again have to transform the whole
program, not just expand a call/cc macro locally inside functions that
use it.
R
rdiaz02
Maybe this was already mentioned in this thread and I didn't see it.
Anyway, I find that Scheme (so I am talking about Scheme as a member of
the "lisp family") has pedagogical advantages over Python.
1. There are a range of excellent books that will introduce not just
Scheme but programming and computer science to audiences with varied
background and previous programming experience.
1.1. I do not know of any Python equivalents to "The Little Schemer"
and "The Seasoned Schemer". These teach you recursion and "the art of
scheme programming". I think "Core Python Programming" (and, to a
lesser extent, "Learning Python") might teach some of "the art of
python programming", but the focus, style, and effectivenes are quite
different (and, I'd say, not as successful; you can read the little
schemer in a couple of long train commutes; there is no way you can do
that with Core Python Programming.). Sure, the style of "The little
Schemer" is not for everyone.
1.2. "How to design programs" is obviously a much broader,
comprehensive, detailed, and far-reaching textbook than (the nice) "How
to think like a computer scientist; learning with Python".
1.3. SICP has no counterpart in the Python world. I've read some people
have taught SICP like using Python (and that there is a new course at
MIT, taught by Abelson and/or Sussman, that will use Python, not
Scheme; but this is not a course that really substitutes the original
for which SICP was written). But SICP remains SICP. It'd be nice to see
something similar in Python.
1.4. More advanced material is available as "Programming Languages:
Application and Interpretation" (Krishnamurthi). I know of no Python
counterpart in the range and depth of topics covered.
1.5. Last, but not least, lots of this material is available on-line.
So you can check it out before buying the dead-tree version.
2. PLT scheme and Dr. Scheme are a wonderful learning environment for
Scheme, with no equivalent in Python. Its not just the great debugging
and tracing facilities, but also who you can restrict the language you
use to concentrate on some key features, so as to build incrementally
(to avoid the forest from preventing you to see some specific trees).
Interestingly, I think there has been at least one attempt to build
something similar for Python on top of Dr. Scheme (in PyCon 2004 or
2005?).
3. Schemers (some Schemers at least) are making a strong effort to
teach CS to audiences of varied backgrounds and experiences. They even
have a sequence that starts from basically 0, teaches you Scheme, and
ends up including Java (I guess this is catering to the "but I really
need Java to get a job when I get out of here!"). That Scheme is way
ahead of Python in this area I think has been recognized by relevant
members of the Python community (comp.lnag.python not long ago).
4. Python, instead, has the wealth of "nutshells", "pocket guides",
etc. Which are fine (I always have my Ptyhon in a Nuthsell and Python
Pocket Reference nearby when writing Python). But I doubt these books
really teach you basic computer science as the above do. They are of
the applied kind (and here probably the only Lisp coutnerpart might be
"Practical Common Lisp").
Why does all this matters (or at least matters to me, who am
considering moving most of my programming from Python to Scheme and
CL)?
a) If the issue of teaching programming to a kid/adolescent arises, I'd
definitely have a lot more resources, which also teach much more than
just a language, if I choose Scheme. (And, no, I do not think a
parenthesis is inherently more scary than a tab for someone who is new
to both).
b) I have no formal CS training; I am a biologist and statistician by
training and have used Basic, C/C++, Pascal, Fortran, R (oh, and RPL,
that minor language of the HP48 calc., which I used extensively for 18
months for writing lots of animal behavior recording programs). But
once and for all, I'd like to learn some basic CS, while learning how
to use a language. I have a strong feeling that, with the Scheme route,
this will be fulfilled. Not with Python. (Sure, this is also fulfilled
with Mozart/Oz and "Concepts and Techniques and Models of Comp.
Progr.", but Mozart/Oz does not seem as ready for the types of projects
I work on and there are speed issues). The first three chapters of SICP
and the first four chapters of CTM so far have really been
mind-expanding. None of the Python books I've read have felt anyway
similar (Python has felt cozy, nice, easy to use; not eye opening).
c) Now, if Scheme/CL were just "toy languages" we could dismiss all the
above by saying "we are not talking about why kids learn XYZ, nor why
CS ignorants like you prefer to be spoon fed basic CS concepts by
learning language UVW". But of course, I think that neither Scheme nor
CL are just toy languages.
Just my 2 cents.
Ramon
Anyway, I find that Scheme (so I am talking about Scheme as a member of
the "lisp family") has pedagogical advantages over Python.
1. There are a range of excellent books that will introduce not just
Scheme but programming and computer science to audiences with varied
background and previous programming experience.
1.1. I do not know of any Python equivalents to "The Little Schemer"
and "The Seasoned Schemer". These teach you recursion and "the art of
scheme programming". I think "Core Python Programming" (and, to a
lesser extent, "Learning Python") might teach some of "the art of
python programming", but the focus, style, and effectivenes are quite
different (and, I'd say, not as successful; you can read the little
schemer in a couple of long train commutes; there is no way you can do
that with Core Python Programming.). Sure, the style of "The little
Schemer" is not for everyone.
1.2. "How to design programs" is obviously a much broader,
comprehensive, detailed, and far-reaching textbook than (the nice) "How
to think like a computer scientist; learning with Python".
1.3. SICP has no counterpart in the Python world. I've read some people
have taught SICP like using Python (and that there is a new course at
MIT, taught by Abelson and/or Sussman, that will use Python, not
Scheme; but this is not a course that really substitutes the original
for which SICP was written). But SICP remains SICP. It'd be nice to see
something similar in Python.
1.4. More advanced material is available as "Programming Languages:
Application and Interpretation" (Krishnamurthi). I know of no Python
counterpart in the range and depth of topics covered.
1.5. Last, but not least, lots of this material is available on-line.
So you can check it out before buying the dead-tree version.
2. PLT scheme and Dr. Scheme are a wonderful learning environment for
Scheme, with no equivalent in Python. Its not just the great debugging
and tracing facilities, but also who you can restrict the language you
use to concentrate on some key features, so as to build incrementally
(to avoid the forest from preventing you to see some specific trees).
Interestingly, I think there has been at least one attempt to build
something similar for Python on top of Dr. Scheme (in PyCon 2004 or
2005?).
3. Schemers (some Schemers at least) are making a strong effort to
teach CS to audiences of varied backgrounds and experiences. They even
have a sequence that starts from basically 0, teaches you Scheme, and
ends up including Java (I guess this is catering to the "but I really
need Java to get a job when I get out of here!"). That Scheme is way
ahead of Python in this area I think has been recognized by relevant
members of the Python community (comp.lnag.python not long ago).
4. Python, instead, has the wealth of "nutshells", "pocket guides",
etc. Which are fine (I always have my Ptyhon in a Nuthsell and Python
Pocket Reference nearby when writing Python). But I doubt these books
really teach you basic computer science as the above do. They are of
the applied kind (and here probably the only Lisp coutnerpart might be
"Practical Common Lisp").
Why does all this matters (or at least matters to me, who am
considering moving most of my programming from Python to Scheme and
CL)?
a) If the issue of teaching programming to a kid/adolescent arises, I'd
definitely have a lot more resources, which also teach much more than
just a language, if I choose Scheme. (And, no, I do not think a
parenthesis is inherently more scary than a tab for someone who is new
to both).
b) I have no formal CS training; I am a biologist and statistician by
training and have used Basic, C/C++, Pascal, Fortran, R (oh, and RPL,
that minor language of the HP48 calc., which I used extensively for 18
months for writing lots of animal behavior recording programs). But
once and for all, I'd like to learn some basic CS, while learning how
to use a language. I have a strong feeling that, with the Scheme route,
this will be fulfilled. Not with Python. (Sure, this is also fulfilled
with Mozart/Oz and "Concepts and Techniques and Models of Comp.
Progr.", but Mozart/Oz does not seem as ready for the types of projects
I work on and there are speed issues). The first three chapters of SICP
and the first four chapters of CTM so far have really been
mind-expanding. None of the Python books I've read have felt anyway
similar (Python has felt cozy, nice, easy to use; not eye opening).
c) Now, if Scheme/CL were just "toy languages" we could dismiss all the
above by saying "we are not talking about why kids learn XYZ, nor why
CS ignorants like you prefer to be spoon fed basic CS concepts by
learning language UVW". But of course, I think that neither Scheme nor
CL are just toy languages.
Just my 2 cents.
Ramon
M
Michele Simionato
P
Paul Rubin
Michele Simionato said:
Thanks!
D
Dmitry V. Gorbatovsky
Put aside,that I don't understand meaning of term
"psychological claim" in that context.
It is obvious that different
medium of information exchange provides
different levels of readability for humans.
And accordingly easier/harder to learn/use.
Regards, Dmitry