C#-C#-C#-C#-C#anges...

Why, was I supposed to? Are you ASKING me to dis your language choices? What purpose would that serve?



Considering I didn't offer a straw man, your red herring is hereby denied.

/327/99/361945/1.html gets around to kippers at post #82.

In any case, if the page on the LSL Wiki that I linked to above is correct, we can use ANY language we like, as long as it compiles to the CLR.

And the list of CLR languages is VERY long. I did a very quick googling and found this list, which I *know* is incomplete.

http://blogs.ugidotnet.org/nettools/articles/8060.aspx

It even includes Ada, Cobol, APL, Eiffel, Lisp, Scheme, Fortran, Pascal AND Oberon, Prolog, SmallTalk, SML, Haskell, Java, Forth, Perl, Python, Ruby, etc.

.... I dare anyone to write lsl scripts in ADA (with requisite notes) or cobol.... I dare you =)

So what benefits will new languages bring?
Whatever one you choose you'll still have to use llFunctions() for everything in-world as no other language knows anything about a prim.
Yes, we'll have arrays, pointers, boolean values, RPN and possible even objects if you can handle them in 64k. Isn't it all made irrelevant though becaUse ALL non-trivial, non-prim-processing is simply better off-world?

(PS: (because someone had to) LISP is an acronym but Smalltalk isn't. So why isn't it Thmalltalk?)

APL! Bliss! MUMPS! LOGO! Snobol!

Good point, Intermediate. But I kind of tend to the view that doing stuff off-world relies on, well, off world things to be there. But then again, relying on in-world stuff to be there can be problematical too

I think that using other languages might be useful for writing pure data processing scripts, like data storage scripts and maybe for utility scripts like a dialog handler, but yeah, I guess for actually messing around with prims LSL will remain the favourite.

I'm kind of a language nut, and I looked at Bliss and Snobol. Bliss has a great name, and at the time it was probably good, but now it seems like a very machine-specific form of C.

Snobol inspired an interesting language called Icon, which has then evolved into Unicon.

I notice that you haven't mentioned any languages from the ML family.

Yes Pete. Mind you, with a bit of reflection, I just think of the joy that freedom from LSL lists will bring. Hie thee hence BubbleSort and never darken our doors again! (I used to refuse to even teach it until the end of any course, just to illustrate why it should never, ever, ever, be used). Ahhh, the arguments we shall have about whether unstable Quickort is worth the bits and whether making it stable is worth the bother.

Has anyone thought how on earth we're going to handle questions about all these different languages? LSL on its own is bad enough, what about when someone comes in with some FRED (for Framework) and wants it debugged?

The name Thmalltalk would suggest that someone had implemented LISP in Smalltalk... which has been done, but under a different name.

Someone apparently used the name Thmalltalk when they were adding object-oriented extensions to Lisp.

Bliss is one of the early structured assembly languages, most of which haven't survived their original platforms. C is a *typed* structured assembly language, really a later generation... Bliss is more a late peer of BCPL.
Only pure/functional programming I've done has been in Scheme. Plus, apart from CAML they don't really have cool double-entendre names.

There won't be a 64k limit anymore by the time more languages are available. As part of the "script limits" deal, scripts will be able to request as much, or as little, memory as they need, subject to the overall limits imposed.

There's quite a bit of logic that is more economical to be done in scripts than off-world; not to mention that not everyone has off-world resources available for use, and using off-world resources adds an extra dimension of instability and support requirements.

the question is, will it allow certain operations, or in the case of the notorious list sort list, if it's even being implemented on the script side, or if you have to write your own function for it. will we actually be able to leverage the full language?


I dread the thought on on hand, on another it'd give us all some practice in other languages... though I wonder what curious LSLisms will sneak into the compiler on LLs end...

Forth code can be extremely compact, especially if you're good at stack juggling.