Nexus Programming Language

David M. wrote:

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?

Because in lisp, the metalanguage is the same as the language. Tweaking
ParseTree data is different than writing ruby code. In lisp, the two
activities are the same.

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.

You are supporting my point here. ParseTree only runs on 1.8 CRuby,
being tied to the C implementation’s AST. If ruby as a language
supported a retrievable AST structure, then it could be put alongside
dylan as one of the non-lisp languages which supports code as data. But
Matz has explicitly decided against this.

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.

Reflection is different from code-data equivalence.

Actually, I shouted “bullshit!” because a language cannot prevent
thoughts.

Most people are surprised when they learn lisp macros. I know I was,
and I know many students who were. Why did it surprise us? Because we
hadn’t thought of that before. It is not that a language prevents the
thoughts willfully like a evil demon, it’s that the thoughts never arise
in the first place.

The question then becomes whether a language actually makes certain
things impossible, or impractical, or just annoying. And Ruby does have
ParseTree.

Not in 1.9 or JRuby. Nor is it planned. Let me know if it happens.

“Power” is subjective.

No, not in the way I used the term. Because of code-data equivalence,
lisp can do things which ruby cannot. In this formal, objective sense,
lisp is more powerful. Even if ruby greenspuns its own tools like
ParseTree, the language will still be different than the metalanguage.
Don’t take it personally. This fact is well understood. There is no
sense wiggling around it just to somehow respond with a
counter-argument.

Matz has called lisp “extreme abstraction”, which is one way to put it.
Lisp allows for more abstractions than ruby. It was his choice to
relinquish some of those abstractions, some of that power, in the design
of ruby. After all, despite all the catch phrases, ruby is not lisp, by
design.

[email protected] (Pascal J. Bourguignon) writes:

           (e = [[ "." , fieldAccess , :getValuePtr]]) 
                [:for , [ nil , ["!=" , :i , :e],["post++",:i]] ,
                  [:block , ["<<", :s , " ("] , k , ["<<", :s , " . "] , v , ["<<", :s , ")"]]] , 
               [ "<<" , :s , ")"]])
      end)
   end)

Pascal, I’m curious about your use of parentheses above. Do you use
them because it makes some things easier in your editor, or to compare
more directly with the Lisp example I elided, or simply to try and
make your Ruby code look as much like Lisp as posisble, or … ?

On Tue, Feb 24, 2009 at 11:04 PM, Mike G.
[email protected]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.

Homoiconicity doesn’t afford power so much as simplicity. Using parse
transformations in Ruby requires learning what the Ruby parser’s “sexps”
look like, whereas in Lisp you write your code directly in those sexps
so
there is no disconnect.

Once you have the Ruby parser’s sexps, the same class of transformations
are
still available, as they are in any language which allows you to
programatically retrieve parser output and invoke the compiler from
within
the language itself.

However, for day-to-day programming tasks I find code in sexp form
harder to
read (and write) than code in a more complex grammar which is able to
express the same idea with fewer tokens and less syntactic noise.

Lisp is certainly better optimized for macros, but in my opinion Ruby is
better optimized for day-to-day use and readability.

Chad P. wrote:

I’m leaning more toward = being used for both, and some other signifier
determining how the expression should be evaluated.

What should that other signifier be? I guess you could say that
assignment has
no value (instead of returning the assigned value as it usually does)
and
then interpret = as checking for equality when it’s used in a place
where a
(boolean) value is expected and as assignment when it’s not. But I
imagine
that could become confusing as well. Also it’d make it impossible to do
things like “while item = get_item” (which may or may not be a good
thing
depending on your point of view, of course).

On Wed, Feb 25, 2009 at 12:44 PM, Brian A. [email protected]
wrote:

           (ie = [["." , e , :end]])
              (Cxx::Variable . new(:e , (Cxx::Type . new((self . cxxPath)+"::"+"const_iterator")) , ie)) ,

make your Ruby code look as much like Lisp as posisble, or … ?


Brian A.
http://lojic.com/

I think he was making a point to compare Ruby code with LISP code and
showing how similar it is at the core. At least, that’s what I saw.

Jason

Mike G. wrote:

How is it more powerful than any other language which allows reflection?
Including Ruby, with ParseTree?

Because in lisp, the metalanguage is the same as the language. Tweaking
ParseTree data is different than writing ruby code. In lisp, the two
activities are the same.

I consider that to be a strength of Ruby.

It’s possible I simply haven’t done enough Lisp to miss some obvious
cases where macros would be helping. However, all the other
metaprogramming (instance_variable_set, define_method, etc) all work
pretty naturally as part of the language. The ParseTree stuff, while it
makes ParseTree itself slightly harder to learn (as you have to learn
how it represents Ruby code), allows the language to be easier and
cleaner when you don’t need it.

Even when you do, I’d argue that ParseTree tends to match the structure
that you have in your head for that code, anyway.

Reflection is different from code-data equivalence.

Code-data equivalence is a kind of reflection.

“Power” is subjective.

No, not in the way I used the term. Because of code-data equivalence,
lisp can do things which ruby cannot.

I believe I’ve shown that either of the following is true:

Ruby can do everything Lisp can (ParseTree, etc)…

  • OR -
    there are things Ruby can do that Lisp cannot.

If we accept that ParseTree counts, Ruby can do everything Lisp can,
with the additional point that not all dialects of Lisp have a concept
of objects.

If we decide that ParseTree doesn’t count, then “power” is at least
somewhat based on a superficial, syntactical difference when writing
functionally-equivalent code. In which case, I can find plenty of things
I can do with Ruby syntax that I can’t do with Lisp.

In this formal, objective sense,
lisp is more powerful. Even if ruby greenspuns its own tools like
ParseTree, the language will still be different than the metalanguage.

Again, a syntactical difference.

For this kind of reflection, Lisp wins. For everything else, Ruby syntax
is much more readable, at least to me.

Don’t take it personally. This fact is well understood. There is no
sense wiggling around it just to somehow respond with a
counter-argument.

Then try responding to that counter-argument, rather than “wiggling
around it” by simply repeating your own, and tacking on an argument from
authority.

Brian A. [email protected] writes:

           (ie = [["." , e , :end]])
              (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)

Pascal, I’m curious about your use of parentheses above. Do you use
them because it makes some things easier in your editor,

Yes, definitely. I use emacs with paredit-mode.

or to compare
more directly with the Lisp example I elided,

Not specifically, but it’s a nice side effect.

or simply to try and
make your Ruby code look as much like Lisp as posisble, or … ?

Yes, definitely. It makes me feel if not at home, at least, at a
strange aunt’s, vs. in a totally strange home in a totally strange
land.

On 25.02.2009 01:41, Eleanor McHugh wrote:

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.

Of course, this provokes the question “what is beauty?” (or “what is a
beautiful program?”). Pascal seems to like cascades of brackets so he
even writes Ruby code that way (or maybe it’s just a habit) - other
people will like something else. IIRC there is this saying about the
“eye of the beholder”… :slight_smile:

What I probably wanted to say was: if you consider beauty as a criterion
for discussing languages it comes as no surprise that there is so little
agreement among people. :slight_smile:

And yes, we’ve gone completely OT. :slight_smile:

Kind regards

robert

PS: For me beauty in a program is clear structure and few but well
chosen lines of code.

On 25 Feb 2009, at 21:24, Pascal J. Bourguignon wrote:

Brian A. [email protected] writes:

or simply to try and
make your Ruby code look as much like Lisp as posisble, or … ?

Yes, definitely. It makes me feel if not at home, at least, at a
strange aunt’s, vs. in a totally strange home in a totally strange
land.

And that is precisely the point that many Lispers overlook. Lisp is a
mathematical notation and so people of a mathematical inclination feel
at home, however languages with “complex” syntax approximate natural
language notation and that’s a place where the vast majority of
literate humans feel comfortable.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

raise ArgumentError unless @reality.responds_to? :reason

On Feb 23, 2009, at 11:02 PM, M. Edward (Ed) Borasky wrote:

Actually it dates back to Algol. The people who designed it did it for
a reason, but I can’t remember what it was. I think it was to remind
people that assignment was not equality, and the purists pronounce

a := b

IIRC, that’s similar to how the production is written in BNF, and made
sense in the context of creating compilers. But really, this
discussion is primarily about syntactic sugar. The whole point of a
high level programming language is to enable to let people think as
people do and translate those constructs into something that machines
can process efficiently. Many people, myself included, don’t have
stack-based architectures and thus don’t think well in RPN. So Forth
might not be my language of first choice.

But in the end, any T-complete language should allow you to (or should
I say “not prevent you from”) do(ing) your job.

On Wed, Feb 25, 2009 at 09:30:26AM +0900, William J. wrote:

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.

I don’t think that’s necessarily true of identifying flame-bait what it
is. If I did, I’d have responded to you with something like “Calling it
‘flame-bait’ is in itself flame-bait, proving that you are devoid of
integrity and possessed of overweening conceit and arrogance.” I don’t
really feel like saying all that nasty stuff about you though, William,
since I don’t even know you.

Tony A. wrote:

Homoiconicity doesn’t afford power so much as simplicity. Using parse
transformations in Ruby requires learning what the Ruby parser’s “sexps”
look like, whereas in Lisp you write your code directly in those sexps so
there is no disconnect.

Actually, you can have complex syntax and easy manipulation, by
delegating the building of the AST to the tool that already knows how
to do that anyway: the compiler.

The Converge Programming Language (http://ConvergePL.Org/) is a
great example of compile time metaprogramming in a language with
complex syntax (Pythonic in this case). It uses quasi-quoting to let
you build ASTs using the concrete syntax of the language and it uses
splice points to allow you to splice AST fragments back into the AST.

For things that are too complex for simple quoting and splicing,
Converge has an abstract standardized API to the compiler.

jwm

PS: Consider this my entry to “what Reia could steal from other
languages” (-:

On Wed, Feb 25, 2009 at 05:22:35AM +0900, Glen F. Pankow wrote:

Impressive, young Skyparenthesizer. And here I thought Darth Java
had won the Clone/Dup/Bloat War.

You forgot “Blub” amongst those pejoratives.

I find my randomly selected signature block stragely ironic.

Robert K. wrote:

even writes Ruby code that way (or maybe it’s just a habit) - other

robert

PS: For me beauty in a program is clear structure and few but well
chosen lines of code.

Not me. It was the beauty I saw in Ruby that drew me in. Beauty in art
is often about a kind of integrity - be it structural (music, sculpture,
architecture, programming), expressive (graphic art, poetry,
programming) textural (drawing, music). A very incomplete analysis, of
course, but the point is that certain abstract qualities tickle the
brain, and our brains all come from the same genetic pool, so we share
common joys. Drawing closer to a clear vision of how that happens is
also beautiful, I think.

Beauty also has something to do with novelty, with surprise. I find both
surprise (sorry, Matz), and integrity in Ruby, and love both. Surprise
that a relative few powerful ideas can be so gainfully permuted, and
with such integrity. Stravinsky knew how to do that.

t.

Tom C., MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< [email protected] >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)

On Wed, Feb 25, 2009 at 09:24:23AM +0900, William J. wrote:

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.

To be fair, I’m not terribly likely to learn Clojure any time soon, for
a
number of reasons:

  1. While code written for the JDK/JVM is very portable across systems
    with the JDK/JVM installed, and code written for the JRE is very
    portable across systems with the JRE installed, code written for one
    is
    sometimes not so portable to the other, and doG forbid you try running
    code written for either on some third-party Java VM. Since Clojure is
    a language designed to run atop a Java implementation, this could be
    relevant, and results in it not providing me a whole lot of benefit
    over Ruby, Perl, et cetera, for purposes of portability. At least,
    that’s my experience.

  2. The JVM and JRE distributions of the official Java implementation
    are not as protable as people like to think, themselves. On some
    OSes,
    it’s a real bear to get 'em installed and keep 'em updated.

  3. I like to get started in a language with simple command line tools,
    and don’t much like having to start up a huge effin’ VM like Java’s to
    run simple command line tools.

Clojure sounds like a great language, though.

On Thu, Feb 26, 2009 at 05:18:24AM +0900, Sebastian H. wrote:

depending on your point of view, of course).
I’m not sure about the specifics of how I’d want to set up the syntax,
but I don’t see why the potential problems you bring up can’t be worked
around. Hell, just adding “let” to the assignment operation could clear
that up – though I’m not convinced that’s the best way to do it,
because
I’m not sure how much I care about the addition of an additional
syntactic element there.

while let item = get_item

On Wed, Feb 25, 2009 at 03:57:48PM +0900, Dylan E. wrote:

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.

I’m not sure how that “seems funny”, considering you just confirmed some
of what I said – that RPN parsers are easier to write than Polish
notation parsers.

On Wed, Feb 25, 2009 at 09:41:56AM +0900, Eleanor McHugh wrote:

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.

Meh. I’m pretty big on both. I guess I’m neither an “ass man” nor a
“breast man”, but more of a “total package man”. Pray pardon my
reference to a crude, but common, idiom by way of analogy.

After years of battling with VB, C++ and Java the discovery of Ruby
was one of those doh! moments. I haven’t looked back :slight_smile:
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.

I love Ruby. Ironically, though, I seem to be going in the other
direction, somewhat – getting (back) into C a bit more now.

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.

I have to guess you haven’t seen beautiful C code using the GNU style
guide. That stuff makes me shudder, as does the ritual abuse of GCC
specific compiler features.

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.

That’s an analogy I hadn’t considered before. I guess, if CL is like
Esperanto, Ruby is like Japanese, Perl is like American English, Python
is like English as spoken in India, and Scheme is a bit like Toki Pona.

Of those, Toki Pona and Japanese are by far my favorites, in terms of
the
basic structures of the various languages, but American English is the
language with which I’m still the most comfortable, the most fluent, and
the most expressive.

I’m not sure where C would fit into all that.

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.

quoth Rainer Maria Rilke:

"For beauty is nothing but the beginning of terror which we are
barely able to endure, and it amazes us so, because it serenely
disdains to destroy us."

On 25 Feb 2009, at 21:54, Robert K. wrote:

a beautiful program?"). Pascal seems to like cascades of brackets
so he even writes Ruby code that way (or maybe it’s just a habit) -
other people will like something else. IIRC there is this saying
about the “eye of the beholder”… :slight_smile:

What I probably wanted to say was: if you consider beauty as a
criterion for discussing languages it comes as no surprise that
there is so little agreement among people. :slight_smile:

A lot of these arguments though have less to do with beauty per se
than they do with an evangelical zeal to save the poor benighted
heathens from their dark and superstitious coding ways. Personally I
like my superstitious ways and I’m happy to leave benighted heathens
to their own devices :slight_smile:

And yes, we’ve gone completely OT. :slight_smile:

Kind regards

robert

PS: For me beauty in a program is clear structure and few but well
chosen lines of code.

The same here, and I like to believe that insofar as there are any
objective criterion for beauty in code those are the most easily
expressed.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

raise ArgumentError unless @reality.responds_to? :reason

On Thu, Feb 26, 2009 at 4:01 AM, Chad P. [email protected]
wrote:

I find my randomly selected signature block stragely ironic.


Chad P. [ original content licensed OWL: http://owl.apotheon.org ]
Common Reformulation of Greenspun’s Tenth Rule: Any sufficiently
complicated non-Lisp program contains an ad hoc informally-specified
bug-ridden slow implementation of half of Common Lisp.

But don’t forget: Any sufficiently well-documented Lisp program
contains an ML program in the comments :slight_smile:

martin