Lua is about to become history

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Reuben Thomas-5
On Wed, 3 May 2006, Roberto Ierusalimschy wrote:

>> Paul Graham made a remark to the effect that all languages attempt to turn
>> themselves into LISP as they evolve.
>
> I guess he really thinks so; but it is not true :)
>
> "Original" Lisp had no lexical closures, no pattern matching, no
> coroutines (or threads or continuations, for that matter), no API to
> other languages, no exception handling, no module system, and I think it
> did not require proper tail calls.  (What it had always excelled was in
> "extensible semantis", aka macros.)

So, we count LISP itself among the languages that attempt to turn
themselves into LISP. No contradiction there.

--
http://rrt.sc3d.org/ | wet nurse, n.  lactating lackey
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Bret Victor
In reply to this post by John D. Ramsdell-2
> I think you have to be very careful about making this case.  How
> tolerant of backwards-incompatibility do you thing the Lua user base
> would be if the Lua authors modernized the language to support
> zero-based array and string indexing?

I believe that one-based indexing was very intentional.
Most people (who haven't had their minds warped into
conflating ordinals with pointer offsets) expect the
third item in a list to be #3.  That's certainly what my
grocery list looks like.  Lua was designed to be usable
by these people.

But even so, zero-based array indexing would be a
minor change in comparison with, say, throwing out the
preprocessor, replacing tag methods with metatables,
replacing upvalues with lexical scoping, scooping
global functions into packages, overhauling the
C API, etc. etc.  Even the 5.0 -> 5.1 incompatibilities
are beyond what many language communities would
tolerate.  Making changes of that scope to Javascript
would break the world.

Imagine a Lua that was forced into preserving tag
methods and upvalues and arg and the rest of the
obsolete cruft for fear of breaking a large installed
base of programs.  Actually, you don't have to imagine;
it's called "Perl".

-Bret


Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Lisa Parratt
In reply to this post by Roberto Ierusalimschy
Roberto Ierusalimschy wrote:
> I guess he really thinks so; but it is not true :)
> "Original" Lisp had no lexical closures, no pattern matching, no
> coroutines (or threads or continuations, for that matter), no API to
> other languages, no exception handling, no module system, and I think it
> did not require proper tail calls.  (What it had always excelled was in
> "extensible semantis", aka macros.)
>  
"Any sufficiently complicated C or Fortran program contains an ad-hoc,
informally-specified, bug-ridden, slow implementation of half of
CommonLisp <http://c2.com/cgi/wiki?CommonLisp>." - Philip Greenspun
"Including Common Lisp." - Robert Morris


--
Lisa

Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Hisham Muhammad
In reply to this post by Norman Ramsey-2
On 5/3/06, Norman Ramsey <[hidden email]> wrote:

>  > > Paul Graham made a remark to the effect that all languages attempt to turn
>  > > themselves into LISP as they evolve.
>  >
>  > I guess he really thinks so; but it is not true :)
>  >
>  > "Original" Lisp had no lexical closures, no pattern matching, no
>  > coroutines (or threads or continuations, for that matter), no API to
>  > other languages, no exception handling, no module system, and I think it
>  > did not require proper tail calls.  (What it had always excelled was in
>  > "extensible semantis", aka macros.)
>
> Hurrah!  I've never liked that bit of parochialism and am happy to see
> it debunked.  (Though I do think parallel evolution of languages,
> e.g., in acquiring lexical closures, is a fascinating phenomenon.)

Hear! Hear!

> Now, to get really off topic, what shall we do about 'every program
> evolves until it is powerful enough to read mail'? :-)

Well, once something is already Lua-extensible, it's just a matter of
'require'ing a POP3 module, isn't it? ;-)

-- Hisham
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Luiz Henrique de Figueiredo
> Well, once something is already Lua-extensible, it's just a matter of
> 'require'ing a POP3 module, isn't it? ;-)

See FreePOPs: http://www.lua.org/uses.html#167
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

John D. Ramsdell-2
In reply to this post by Luiz Henrique de Figueiredo
When programming in Lua, I nearly always use one-based array indexing.
I think one should always strive to write code that others can
maintain, even when there is little chance the code will be used by
anyone else.  The pervasive use of zero-based indexing needlessly
confuses readers of Lua source code.

In Java, I hate the fact that they adopted the smooshed identifier
convention from SmallTalk, rather than the underscore identifier
convention used in many C programs.  Thus, instead of the much more
readable this_is_an_identifier, in Java, convention has it that you
write thisIsAnIdentifier.  My Java code follows the convention.

John
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Thomas Harning Jr.
On 04 May 2006 18:33:31 -0400, John D. Ramsdell <[hidden email]> wrote:
> In Java, I hate the fact that they adopted the smooshed identifier
> convention from SmallTalk, rather than the underscore identifier
> convention used in many C programs.  Thus, instead of the much more
> readable this_is_an_identifier, in Java, convention has it that you
> write thisIsAnIdentifier.  My Java code follows the convention.

I think the 'smooshed' identifier is much more practical.  It saves
you 1 stretched keystroke per extra-word.  As for readability, its
usually the case that the variable names are short and don't have
obnoxious sequences such as IsAWord or IsAnIdentifier.  Another
'bonus' for the camel-casing is the fact that WikiWords are based on
it, so it can simplify the documentation process.
That's my 0.02 $.

--
Thomas Harning Jr.
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Petite Abeille
In reply to this post by John D. Ramsdell-2

On May 05, 2006, at 00:33, John D. Ramsdell wrote:

> In Java, I hate the fact that they adopted the smooshed identifier
> convention from SmallTalk, rather than the underscore identifier
> convention used in many C programs.

By that token, shouldn't the class/file names follow that convention as  
well?

     - Capitalized_Words_With_Underscores (ugly!)

Instead you have:

     - CapitalizedWords (or CapWords, or CamelCase -- so named because
       of the bumpy look of its letters[4]).  This is also sometimes  
known as
       StudlyCaps.

Followed by:

     - lower_case_with_underscores

http://www.python.org/dev/peps/pep-0008/

I personally stick with Objective-C naming convention, out of habit I  
guess:

http://developer.apple.com/documentation/Cocoa/Conceptual/ 
CodingGuidelines/Articles/NamingBasics.html
http://developer.apple.com/documentation/Cocoa/Conceptual/ 
CodingGuidelines/Articles/NamingMethods.html

There is no accounting for taste :)

Cheers

--
PA, Onnay Equitursay
http://alt.textdrive.com/

Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Petite Abeille
In reply to this post by Hisham Muhammad

On May 04, 2006, at 16:18, Hisham Muhammad wrote:

>> Now, to get really off topic, what shall we do about 'every program
>> evolves until it is powerful enough to read mail'? :-)
>
> Well, once something is already Lua-extensible, it's just a matter of
> 'require'ing a POP3 module, isn't it? ;-)

Talking of which, here is a goofy SMTP server implemented in Lua:

local SMTPServer = require( "SMTPServer" )
local SMTPDelegate = require( "SMTPDelegate" )

local aServer = SMTPServer( 1025 )

aServer:setDelegate( SMTPDelegate )

aServer:start()

The server handles the SMTP particularities and let the delegate drive
the underlying logic by implementing optional methods (e.g.
smtpWillAuthenticate, smtpWillAddSender, smtpWillAddRecipient,
smtpWillAddData, etc).

http://dev.alt.textdrive.com/browser/SMTP

Cheers

--
PA, Onnay Equitursay
http://alt.textdrive.com/

Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Rob Shaw-2
In reply to this post by Luiz Henrique de Figueiredo

This thread revisited once again the question of whether
it is better to index an array starting at 0, or starting at 1:

"(Dijkstra said) everyone knows you should start counting at zero"
"Counting from zero labels one as a geek"
"User base happier starting at 1"
"Lua is NOT an inherently a 1-based language"
"That relies on pedantry: the string library IS inherently 1-based"
"Do you think that wart can be fixed?"
"Please let's not start this religious war"

I have a modest proposal, why not split the difference, and
start array indices with 1/2?

 > A = {}

 > for i = 1,100 do
 >>  A[i - 1/2] = i
 >> end

 >  print ( A[1/2] )
1
 > print ( A[3/2] )
2

Works fine in lua, everyone can be happy!
(What's a slight performance penalty in the interests of world peace?)

rob

12