On Wed, Feb 25, 2009 at 03:44:26AM +0900, karlvonl wrote:
If I ever design my own programming language, I’m going to use := for
assignment and == for equality, and let a single = be a syntax error,
just to avoid the whole confusion.
I’m leaning more toward = being used for both, and some other signifier
determining how the expression should be evaluated. I think that would
be more “intuitive” for pretty much everyone involved.
On Tue, Feb 24, 2009 at 05:07:05AM +0900, M. Edward (Ed) Borasky wrote:
- That was pretty much that until computers and programming languages
came on the scene. But in the olden days, when every electron was
precious and compactness and efficiency were of the utmost import, it
turned out that reverse Polish notation was slightly more
efficient. If you look at a parser for algebraic expressions and the
resulting run-time execution engine, you’ll see that.
More than that – and still relevant today – parsers for Polish
notation
are generally more difficult to write. I know – I’ve tried designing
both Polish notation parsers and RPN parsers. In fact, Polish notation
parsers are more difficult to write for essentially the same reason that
RPN parsers are slightly more efficient from the machine’s point of
view.
- Lisp used prefix notation because McCarthy was a disciple of Church
and Church used it. Forth used reverse Polish notation because Chuck
Moore had taken apart the Burroughs compilers and stack architecture
and determined that it was the way to go for maximum compactness and
efficiency.
McCarthy was really ahead of his time. Even Common Lisp and Scheme
haven’t caught up with his vision.
On Tue, Feb 24, 2009 at 2:30 PM, Chad P. [email protected]
wrote:
McCarthy was really ahead of his time. Â Even Common Lisp and Scheme
haven’t caught up with his vision.
Nobody has ever caught up with Chuck Moore – not even he
himself. 
He’s still tweaking Forth, even though his disciples
standardized it long ago and are in a second round of standards
negotiation. For Chuck’s view, see http://www.intellasys.net/.
Warning: here there be dragons, but not of the Dragon Book.
Lisp 1 and 1.5 were (elegant) hacks for the IBM 704 and its close
descendants. As such, they’re very much as elegant as the early Scheme
interpreters. In one of his papers, McCarthy covers the transition
from his 1960 paper to the physical implementation in another paper.
I’m pretty sure it’s on the web, but I don’t recall where. It should
have been reprinted in “Beautiful Code”.
–
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky
I’ve never met a happy clam. In fact, most of them were pretty steamed.
On Tue, Feb 24, 2009 at 9:14 AM, Pascal J. Bourguignon <
[email protected]> wrote:
If you were using CL (if more people were using CL), and Ruby were not
invented, more bosses would let us use CL as a dynamic language, and
indeed we wouldn’t be forced to use Ruby (or worse, perl or python).Of course, you share the culpability with perl, PHP, Python, Java and
so on.
So your argument is Common Lisp would win by default if it were the only
game in town? That’s not exactly a confidence boosting argument.
But I’m mostly justified in thinking this, by the authors of most of
these languages themselves. Some of these authors are just poor chaps
not knowing better, but some other including Java and Ruby knew very
well Lisp, and instead of choosing to help develop and spread lisp,
they voluntarily chosed to create different and inferior languages,
picking only parts of lisp, and grafting over their abortive creation
some monstruous syntax.
Guy Steele, famous for his “drag them halfway to Lisp” quote about Java,
also spent his time making a better Lisp… in his case Scheme.
But this further demonstrates their pragmatism: since it’s clear that
Lisps
will not see widespread popularity, the next best thing is to look to
Lisp
for good ideas and use those in the creation of new languages.
That’s exactly what Matz did with Ruby.
The fact that these monstruous syntaxes view good in the eyes of the
unwashed masses
The quality of a grammar isn’t not inversely proportional to its size,
and
indeed despite the complexity of the Ruby grammar people find it not
only
easy to read, but easy to transform.
You may wish to place emphasis on the latter as Lisp’s homoiconicity
makes
it easier to conceptualize things like macros, but I prefer to place
emphasis on the former as I spend much more time reading code than
transforming it.
Your “unwashed masses” find it easier to read the code of languages with
complex grammars than they do to read Lisp. While you seem to attribute
this to some failing on their part, I’d attribute it to Lisp’s
homoiconicity
leading to an excess of tokens, making the language syntactically noisy.
Perhaps the “unwashed masses” simply prefer their languages use a more
complex grammar to eliminate some of that syntactic noise.
This is perhaps the good that will come from these evils. A lot of
programmers are now exposed on the goodness of dynamic languages, and
they may notice (or if not by themselves, I will try to make them
notice in threads like this), that their fad language of the day, is
actually some incomplete subset of Lisp, and then why not use the full
and authentic thing? Common Lisp is this way!
On the contrary, I think programmers who decide to learn a Lisp and try
out
CL as their first are far more likely to be turned off to Lisp in
general,
as opposed to those who try saner Lisps like Scheme. That was certainly
the
case with myself, and I didn’t really come to like Lisp until I tried
out
Scheme.
I think the failure of Lisp to gain widespread popularity can largely be
attributed to Common Lisp itself.
Pascal J. Bourguignon wrote:
If you were using CL
CL = COBOL Lisp
well Lisp, and instead of choosing to help develop and spread lisp,
they voluntarily chosed to create different and inferior languages,
picking only parts of lisp, and grafting over their abortive creation
some monstruous syntax.
In his city R’lyeh, dead Cthulhu lies dreaming.
“Ph’nglui mglw’nafh Cthulhu R’lyeh wgah’nagl fhtagn!”
The fact that these monstruous syntaxes view good in the eyes of the
unwashed masses, and that the lack of features (when it’s not just the
inclusion of misfeatures) is oblivious to the same masses IS NOT an
excuse.The only result is that Lisp is relegated as just an elegant weapon
from a more civilized time, still mastered only by a few remaining
Jedi.
The poor frightened wretch won’t admit that CL (COBOL Lisp) is
a flint knife and that Ruby is a samurai sword.
He fears and trembles at Ruby’s overtowering superiority.
I’ve asked him to disgorge some feculent COBOL Lisp code here
so that we, while holding our noses, can demonstrate how Ruby
can perform the same task more elegantly and concisely,
and less malodorously.
He hasn’t done so. He will never do so.
And he is so idiotic that he can’t comprehend that COBOL Lisp
isn’t the only Lisp—is, in fact, the worst of the lot.
He can’t learn Clojure because to his fossilized brain
COBOL, COBOL-LISP, APL, and FORTRAN are new and radical languages.
But there is still hope!
This is perhaps the good that will come from these evils. A lot of
programmers are now exposed on the goodness of dynamic languages, and
they may notice (or if not by themselves, I will try to make them
notice in threads like this), that their fad language of the day, is
actually some incomplete subset of Lisp, and then why not use the full
and authentic thing? Common Lisp is this way!
The Way, The Truth, and The Light. He’s a faithful disciple.
“Common Lisp” is cult jargon to conceal the True Name of their god:
Commode Lord.
Pascal J. Bourguignon wrote:
If you were using CL (if more people were using CL), and Ruby were not
invented, more bosses would let us use CL as a dynamic language,
No one can know that. For all you know, if Ruby were not invented, we
would all be using Bash.
It’s also not an argument of superiority – if C was not invented, more
bosses would let us use assembly. You could argue that higher-level
languages were an inevitability – and I would similarly argue that a
more readable syntax (like Ruby) was inevitable.
Of course, you could always go try to find a job with Paul Graham, or
found a startup of Lisp people. There’s no need to force everyone to use
the same language, when you can always work in whatever language you
want.
The fact that these monstruous syntaxes view good in the eyes of the
unwashed masses, and that the lack of features (when it’s not just the
inclusion of misfeatures) is oblivious to the same masses IS NOT an
excuse.
What you’re trying to argue is that everyone else in the world is wrong,
and you are right.
Extraordinary claims require extraordinary proof, and you haven’t
provided any.
The fact that many people prefer this syntax, even when exposed to Lisp
syntax, should tell you something about the value of each. And that’s
even before you consider that the purpose of syntax is communication.
Any syntax that is hard to understand has failed at its purpose.
PS: I’m not subscribed to “Ruby-Talk”, there’s a gateway between this
mail-list and news:comp.lang.ruby.
Then why do you read and participate in comp.lang.ruby? I’m sure you’d
find much more agreement, and maybe even some useful discussion, over at
comp.lang.lisp. (I assume that exists.)
Now, here’s the part you really don’t want to hear:
“It’s easy to talk big. It’s damn hard to implement a complex system,
and make it stable and bug-free…”
– Linus Torvalds
http://article.gmane.org/gmane.linux.kernel/232093
I was involved in a discussion overlapping the kernel mailing list, and
this is perhaps the only email I’ve received directly from Linus
Torvalds, addressed to me.
It made me sit down, and shut up, and actually try to get something done
before I opened my big mouth again.
So I am curious – what have you actually done in Common Lisp? How does
it address the challenges of communication and organization of a large
project? How fast can you whip up small, 100-line scripts to process
text, or to provide a simple service over HTTP and REST? How many cores
(or machines) do your programs scale to, and how much time do you spend
dealing with concurrency issues?
It’s easy to talk big.
But you haven’t even done that – you’ve listed no advantage of Lisp,
other than claiming other languages have “monstrous syntax” – how so?
One more link for you:
Gregory B. wrote:
I don’t think your flame-bait has helped
Calling it “flame-bait” is in itself flame-bait, proving that
you are devoid of integrity and possesed of overweening
conceit and arrogance.
On 24 Feb 2009, at 16:14, Pascal J. Bourguignon wrote:
Some of us know Lisp, we just don’t like it. That’s an aesthetic
choice, and if that bugs you I suggest you consider the relative
numbers of people worldwide employed programming in Lisp and Ruby -
it’s pretty much zilch on both counts. Why? Because many many more
people choose to program in truly monstrous languages like Java lol
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
http://www.linkedin.com/in/eleanormchugh
On 24 Feb 2009, at 13:44, Tom C. wrote:
A most fascinating thread, coming from a very distant universe, as I
do.As for this use of “^”, it is about as needless as yet another poem
about a flower. Don’t we already have one, somewhere? I fully
realize that calculation (computer) languages are not poems, but
they ARE containers for thought, and in that they are brothers/
sisters to poems.
There seems to be a fairly clean divide between the folks who like
language for being language, and those who like language for the
specific things it can do. I’ll admit that I’m one of the former and
some of my favourite programs have minimal value in the latter sense,
but the form of them makes my heart soar.
I’m with Eleanor in loving the exploration of different ways of
thinking/working with stuff (and in having an appreciation for the
elgance of RPN). A large part of the sheer burst of joy that grabbed
me and threw me into the Ruby world, on the occasion of my fifth
look at the language, was the delight I experienced upon finally
understanding that this language was “working” the notion that
everything could be an object, and have access to methods belonging
to the class of which it was a member. The sheer elegance of this
was new to me and is still a very major delight.
After years of battling with VB, C++ and Java the discovery of Ruby
was one of those doh! moments. I haven’t looked back
Ruby and beauty are not always synonymous - it very much depends on
the writer - but it’s a language that I find it hard to be ugly in and
that I think is a wonderful property.
But then again I’ve seen beautiful code in C and Assembler, even in
Pascal (see my favourite book, Programming Languages: An Interpreter-
based Approach for some wonderful examples) and perhaps one day I’ll
see beautiful code in Nexus. That alone will be justification enough
for the love and effort its developers are pouring into it.
As for Common Lisp, it reminds me of Esperanto: those who are
attracted to it seem often to be those least suited to using it
gracefully and perhaps that says more about them than the language
itself.
So, I have to wonder, when meeting up with a new language, if maybe
I’m about to hear my first Stravinsky ballet, or perhaps run into
something like Spencer Brown’s “Laws of form” (1972). Beauty is
found in strange places. If we’re all lucky, the Nexus project will
come up with some we’ve not seen yet. That would be most excellent,
howsoever difficult it may be to achieve.
We abandon the quest for beauty at our peril as it is the keenest
guide to correctness that we possess. Unfortunately an age of
aesthetic relativism has given it a bum wrap by attributing its
quality to things which patently aren’t beautiful and are far from
correct.
And once more RT has gone completely OT
Ellie
raise ArgumentError unless @reality.responds_to? :reason
David M. wrote:
One more link for you:
Too funny!
Which brings me to my point in this rather interesting exchange.
Having wandered the halls of Basic, Fortran, COBOL, C, C++, Pascal,
Forth, Java, etc, etc I have noted that each language introduced me
to new concepts and modes of thought.
I have enjoyed that tremendously but when I want to get something
done (these days) I reach for Ruby.
It suites the way I think, the way I write code and I rather enjoy
it’s almost playful antagonism to burdensome formalisms.
I like my tools light, sharp and powerful. Today, that means Ruby.
Tomorrow, it may mean something else but I haven’t seen it yet…
(And BTW, Java should have been smothered in it’s crib)
Regards
“M. Edward (Ed) Borasky” [email protected] writes:
I think Joy, at least, is influential - language designers seem to
pay attention to it, even if users don’t.Joy and Factor are essentially dialects of Forth that attempt to add
some elegance and a functional language perspective. IMHO neither one
of them is as elegant and practical as the RPL language HP put into
the HP-28, 48 and 49 calculators. If you’re going to make a reverse
Polish language, RPL is the way to do it.
Ah, what memories
I still have my HP-48SX and 2 volume programming manual, what a great
machine. As an undergrad in a numerical analysis class, the prof said
we could use any language we wanted for a particular assignment
(multiple linear regression?), so I asked if I could use the HP-48SX,
and he said sure. It was a blast to crank out on that calculator, and
I’m pretty sure it was a fraction of the size of all the submissions.
karlvonl wrote:
If I ever design my own programming language, I’m going to use := for
assignment and == for equality, and let a single = be a syntax error,
just to avoid the whole confusion.
I used <- in a language I designed once.
On Tue, Feb 24, 2009 at 6:49 PM, Clifford H. [email protected]
wrote:
karlvonl wrote:
If I ever design my own programming language, I’m going to use := for
assignment and == for equality, and let a single = be a syntax error,
just to avoid the whole confusion.I used ← in a language I designed once.
So does R and IIRC all the other dialects of S. Also IIRC R allows
a = b
a ← b
b → a
which have equivalent meaning – “a becomes (a reference to the
object) b”. But “formal” R code uses “<-”, “->” is deprecated and “=”
appears in a lot of actual code. And “==” is the equality test
operator.
At one point R also allowed
a _ b
but I think that disappeared sometime since I first learned R. I
remember that one couldn’t have names like
descent_rate
but had to use
descent.rate
because dot was a letter and underscore wasn’t. But underscore is now a
letter.
–
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky
I’ve never met a happy clam. In fact, most of them were pretty steamed.
M. Edward (Ed) Borasky wrote:
The parentheses are in Lisp because functions (and special forms) have
variable arity. If they had fixed arity the parentheses would not be
required. But since S-expressions were defined using parentheses and
Lisp wanted programs to look like S-expressions, variable arity was
thrown in as a bonus.
The parentheses are there for power: code is data, data is code. When
evaluated as a language only, putting aside external issues such as
mindshare, it is an objective statement to say that lisp is more
powerful than any language which does not have the code-data
equivalence. And the only languages which have it are lisp-like (with
the possible exception of Dylan).
Without end we could discuss popularity, “naturalness,” “well I like
…”, blah blah blah. But it remains an empirical fact some things can
be done in lisp which cannot be done in ruby, unless ruby greenspuns its
own code processor. In lisp you can manipulate code in code. The
curious can ponder the implications of that, and/or learn some lisp to
get a sense of it. The incurious will rage against it and call me a
troll.
If I understand Pascal’s point, if he has one, it is that the vast
majority of programmers do not realize that the non-lisp language they
use is preventing them from thinking certain thoughts. If after reading
the previous sentence you shouted “bullshit!”, then you might not be
fully aware of this special code-data equivalence and why it makes lisp
and lisp-like languages different. I still remember sudden realization
I had when saw what the comma does inside a lisp macro. It has no
counterpart in other languages.
I am not soliciting opinions on what is more practical, what you prefer,
what is better, or what your favorite color is. I am just giving an
overview of the core language itself, with all those issues aside.
“M. Edward (Ed) Borasky” [email protected] writes:
At one point R also allowed
a _ b
but I think that disappeared sometime since I first learned R.
In the old times, the code 95 often displayed as â†
and the code 94 displayed as ↑
It’s only on newer terminals that you would see: a _ b
it was originally: a ↠b
On Wed, Feb 25, 2009 at 8:30 AM, Chad P. [email protected]
wrote:
are generally more difficult to write. I know – I’ve tried designing
both Polish notation parsers and RPN parsers. In fact, Polish notation
parsers are more difficult to write for essentially the same reason that
RPN parsers are slightly more efficient from the machine’s point of view.
That’s seems funny because bison uses RPN as an example. The syntax
isn’t
complex and once you have tokens you just need to shift the values onto
a
stack and when an operator comes along you just apply it to the last two
values then push the result. Or you can create a tree where each value
becomes a node and the following operation the parent.
On Tue, Feb 24, 2009 at 8:40 PM, Brian A. [email protected]
wrote:
Ah, what memories
I still have my HP-48SX and 2 volume programming manual, what a great
machine. As an undergrad in a numerical analysis class, the prof said
we could use any language we wanted for a particular assignment
(multiple linear regression?), so I asked if I could use the HP-48SX,
and he said sure. It was a blast to crank out on that calculator, and
I’m pretty sure it was a fraction of the size of all the submissions.
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky
I’ve never met a happy clam. In fact, most of them were pretty steamed.
Mike G. wrote:
The parentheses are there for power: code is data, data is code. When
evaluated as a language only, putting aside external issues such as
mindshare, it is an objective statement to say that lisp is more
powerful than any language which does not have the code-data
equivalence.
How is it more powerful than any other language which allows reflection?
Including Ruby, with ParseTree?
Without end we could discuss popularity, “naturalness,” “well I like
…”, blah blah blah. But it remains an empirical fact some things can
be done in lisp which cannot be done in ruby, unless ruby greenspuns its
own code processor. In lisp you can manipulate code in code.
Right. Like ParseTree.
I have found Ruby’s reflection to be more immediately useful, but I
didn’t use Lisp long enough to really be sure. I’m talking about the
more specialized stuff, like define_method and instance_eval.
If I understand Pascal’s point, if he has one, it is that the vast
majority of programmers do not realize that the non-lisp language they
use is preventing them from thinking certain thoughts. If after reading
the previous sentence you shouted “bullshit!”, then you might not be
fully aware of this special code-data equivalence and why it makes lisp
and lisp-like languages different.
Actually, I shouted “bullshit!” because a language cannot prevent
thoughts.
For example: Ruby has blocks, where JavaScript does not. But JavaScript
does have anonymous functions.
So while Javascript doesn’t support this:
foo.each do |obj|
end
It does support this (using jQuery):
$.each(foo, function() {
// do something with ‘this’…
});
// or, on a jQuery wrapped object:
foo.each(function() {
// do something with ‘this’…
});
The question then becomes whether a language actually makes certain
things impossible, or impractical, or just annoying. And Ruby does have
ParseTree.
I am not soliciting opinions on what is more practical, what you prefer,
what is better, or what your favorite color is. I am just giving an
overview of the core language itself, with all those issues aside.
However, Pascal’s point was that Lisp was unarguably the best
language, and implied that we were all “unwashed masses” for using Ruby
(and that we probably didn’t know about Lisp). I think if we’re really
going to have a discussion about “best”, practicality has to play a part
of that.
In fact, even if we’re only talking about the most powerful language,
power is also subjective. Ruby, for example, allows me to define a DSL
as a subset of Ruby, and have the DSL be very readable – the
parentheses alone would make that harder in Lisp. All the flexibility
that I like about Ruby’s practice of duck typing would bother someone
who wanted strict compiler checks and mathematical provability – that
is, the power to ignore type would bother someone who wanted the power
to enforce it.
“Power” is subjective.
Tom [email protected] writes:
really match lisp capabilities in this respect where there is no
structural difference between the code and the data that represents
that code. That syntax most people in this thread were mocking has its
advantages and if you’re denying that, the difference to “those cl
advocates” is only a marginal one.Maybe you should rather ask if in ruby it is really necessary to
manipulate code as data the way it is necessary in lisp. With a few
exceptions, I have seldom felt a need for it whereas in lisp the use
of macros is something you do all the time.
Auto-meta-programming is only part of the picture.
Of course, when programming in Lisp, we use auto-meta-programming
obliviously all the time, but there are also a lot of lisp programs
written to implement DSL or to generate inferior languages. For these
heterogenous meta- programming applications, Ruby can be used too.
Here is for example how I generate C++ code from Ruby:
(class MapType
(def makeToStringExpression(fieldAccess , mandatory , inVector
= false , encoding = nil)
(if mandatory
(e = fieldAccess)
(ib = [[“.” , e , :begin]])
(ie = [[“.” , e , :end]])
else
(e = [[ “.” , fieldAccess , :getValuePtr]])
(ib = [[“->” , e , :begin]])
(ie = [[“->” , e , :end]])
end)
(k = (@keyType . makeToStringExpression([“->” , :i ,
:first] , true , encoding)))
(v = (@elementType . makeToStringExpression([“->” , :i ,
:second] , true , encoding)))
(s = [:block ,
[:inline , “typedef " + (self . cxxPath) + "
map_type;”] ,
(Cxx::Variable . new(:i , (Cxx::Type . new((self .
cxxPath)+“::”+“const_iterator”)) , ib)) ,
(Cxx::Variable . new(:e , (Cxx::Type . new((self .
cxxPath)+“::”+“const_iterator”)) , ie)) ,
[ “<<” , :s , " (map"] ,
[:for , [ nil , [“!=” , :i , :e],[“post++”,:i]] ,
[:block , [“<<”, :s , " (“] , k , [”<<“, :s , " .
“] , v , [”<<”, :s , “)”]]] ,
[ “<<” , :s , “)”]])
end)
end)
and how I would do it from Lisp:
(defmethod make-to-string-expression ((self map-type) field-access
mandatory &optional in-vector encoding)
(let ((f (if mandatory field-access (\. ,field-access get-value-ptr)))) (block
(typedef ,(cxx-path self) map-type)
(variable (scope ,(cxx-path self) const-iterator) i (,(if
mandatory '. '->) ,f begin))
(variable (scope ,(cxx-path self) const-iterator) e (,(if
mandatory '. '->) ,f end))
(<< s "(map “)
(for (nil (!= i e) (post++ i))
(block
(<< s " (”)
,(make-to-string-expression (key-type self) (-> i first) t encoding) (<< s " . ") ,(make-to-string-expression (key-type self) (-> i second) t
encoding)
(<< s “)”)))
(<< s “)”))))
(The generator written in Ruby cuts off the C++ syntax at the level of
types and variable expressions, hence the inline and instanciations.
In Lisp, since I could use auto-meta-programming I could easily and
in less time implement the syntax for all the parts of C++, so
there’s no need to cross the language boundaries.)
And Ruby does have ParseTree.
BTW does ParseTree work with ruby 1.9? The last time I tried it
didn’t.
Anyway, ruby isn’t really made for that kind of thing. If you look at
the example at their homepage, the :scope and :block node seem to be
superfluous when dealing with code as data, and something like
“[:call, [:lvar, :arg1], :==, [:array, [:lit, 0]]]” also seems more
complicate than it could be. I think it’s a good start but it doesn’t
really match lisp capabilities in this respect where there is no
structural difference between the code and the data that represents
that code. That syntax most people in this thread were mocking has its
advantages and if you’re denying that, the difference to “those cl
advocates” is only a marginal one.
Maybe you should rather ask if in ruby it is really necessary to
manipulate code as data the way it is necessary in lisp. With a few
exceptions, I have seldom felt a need for it whereas in lisp the use
of macros is something you do all the time.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs