Lightweight Languages

Denise writes: "'What happens if you get a bunch of academic computer scientists and implementors of languages such as Perl, Python, Smalltalk and Curl, and lock them into a room for a day? Bringing together the academic and commercial sides of language design and implementation was the interesting premise behind last weekend's Lightweight Languages Workshop, LL1, at the AI Lab at MIT.' Simon Cozens report, on perl.com, says it wasn't the flame fest you might have imagined."

Comments

Ruby

[thing12]

Ruby is an excellent lightweight language. They had made a comment that it was sadly not mentioned too often during this workshop.

Re:Ruby

[ryanflynn]

Yes, apparently at least Dave (co-author of the pickaxe book) were invited, but unable to attend. Bummer.

Re:Ruby

[thing12]

Big Bummer. This is a language that needs more exposure. I'd love to use it in place of perl if there were more toolbox modules out there for it. It needs to reach a critical mass before the really complicated modules, like template toolkit, get written - and before they get written people aren't able to write the quick and dirty programs (that languages like perl are famous for) that give it the critical mass... vicious circle.

Re:Ruby

[Phantasiere]

Both matz and Dave Thomas were invited to attend the conference, but unfortunately they both had prior commitments at the time.

Lua

[Hougaard]

All my votes goes to Lua. www.lua.org. A fantastic language, small and very fast!

Re:Lua

[ecki]

I second that. Lua is really neat and compact. It is in a way a sort of meta-language, allowing to override many of the built-in functions like variable access, function calls or arithmetic operators so you can build your own language.

Last I checked it has gained some popularity in the game developer scene but I don't know how that has evolved.

Re:Lua

[Anonymous Coward]

I third that. It's faster and smaller than Perl, Python or Ruby and with a cleaner syntax than any of them. It's also much easier to embed in applications.

XML and Lisp.

[DGolden]

XML is, as is touched upon briefly in the aritcle, just lisp s-expressions, but with phenomenally annoying syntax.

If you have to work with XML, and you know some Scheme, I recommend translating it into Scheme form, via ssax. It makes XML not quite such a pain in the arse.

Re:XML and Lisp.

[JamesOfTheDesert]

And what does that buy you? XML is a meta-syntax for markup languages; Scheme is a programming language. You don't "code" in XML any more than you code in HTML.

This is not a troll: what's the equivalent in Lisp to XML namespaces, or attributes, or DTDs?

Re:XML and Lisp.

[benwb]

Note: all examples taken from http://okmij.org/ftp/Scheme/xml.html

Here's an xml file:

<Forecasts TStamp='958082142'>

<TAF TStamp='958066200' LatLon='36.583, -121.850'
BId='724915' SName='KMRY, MONTEREY PENINSULA'>

<VALID TRange='958068000, 958154400'>111730Z 111818</VALID>

<PERIOD TRange='958068000, 958078800'>
<PREVAILING>31010KT P6SM FEW030</PREVAILING></PERIOD>

<PERIOD TRange='958078800, 958104000' Title='FM2100'>
<PREVAILING>29016KT P6SM FEW040</PREVAILING></PERIOD>

<PERIOD TRange='958104000, 958154400' Title='FM0400'>
<PREVAILING>29010KT P6SM SCT200</PREVAILING>
<VAR Title='BECMG 0708' TRange='958114800, 958118400'>
VRB05KT</VAR>

</PERIOD></TAF>
</Forecasts>

and here's the equivalent in sxml

(Forecasts (@ (TStamp "958082142"))
(TAF (@ (SName "KMRY, MONTEREY PENINSULA")(BId "724915")
(LatLon "36.583, -121.850")(TStamp "958066200"))
(VALID (@ (TRange "958068000, 958154400"))
"111730Z 111818")

(PERIOD (@ (TRange "958068000, 958078800"))
(PREVAILING "31010KT P6SM FEW030"))

(PERIOD (@ (Title "FM2100")
(TRange "958078800, 958104000"))
(PREVAILING "29016KT P6SM FEW040"))

(PERIOD (@ (Title "FM0400")
(TRange "958104000, 958154400"))
(PREVAILING "29010KT P6SM SCT200")
(VAR (@ (TRange "958114800, 958118400")
(Title "BECMG 0708"))
"VRB05KT"))))

Namespaces are dealt with as in
(c:part (*NAMESPACES* (c "http://www.cars.com/xml")))

Re:XML and Lisp.

[Anonymous Coward]

Unfortunately, parts of the W3C _are_ trying to "code" in XML, with XEXPR. They're reinventing the wheel, of course, given the existence of scheme.

Namespaces just work. Attributes just work. Dtds are more "interesting", though i think xml schemas are probably more applicable, and have interesting schemey ramifications, like "typing" list strctures based on their content, not a type-tag.

Re:XML and Lisp.

[Anonymous Coward]

But this gets you nothing - the output isn't any shorter, or easier to read, unless you have a pathological aversion to angle-brackets. I'm not sure it would even be that much easier to parse, even from lisp/scheme.

Nice sed script, but it doesn't really do anything, does it?

Re:XML and Lisp.

[brenfern]

Even though it would be nice if things were simple, there is no clear division between "markup" and "programming" languages. XML may be a good syntax for markup languages but is used increasingly to represent data structures. The point here is that Scheme is better at representing data structures than XML. It is also better at representing algorithms. So use XML when you really want to do markup, and Scheme when you want to do any data representation or programming.

Incidentally, XSL is based on Scheme. This is a situation where XML is being used as a meta-syntax for a programming language.

Re:XML and Lisp.

[HiThere]

Nice, but there are tools that understand XML, but don't understand Scheme. And some of them do useful things. Scheme is inherently more meaning filled, but that also means that it may contain expressions that require a Scheme interpreter to understand. Which means that you can't use your tools.

OTOH, XML is being extended in all sorts of incompatible ways, so it may soon loose the advantages that it has held.

Is there a Docbook parser for a Scheme representation? Can it be used to, e.g., generate pdf, rtf, dvi, tex, etc. representations of the code? If so, then my objections are probably wrong. Otherwise, perhaps not. Perhaps if I wrote the Scheme representation, I would need to translate it into XML for useability. (Though in that case, I might prefer the older Docbook format.)

This is a serious question, as right now I'm having difficulty in getting Docbook working on a Win95 system, but I can easily get, e.g., MS Scheme (and others) working.
.

Re:XML and Lisp.

[ajm]

The idea is that by using the s-expression representation for the xml, i.e. by having the xml represented as scheme you can make the xml self executing among other exciting things. The fact that the xml looks to scheme like scheme code which looks to schem like scheme data lets you do the same sort of things to xml that you can to scheme. Hygenic macros to generate chunks of xml, being able to perform transforms using a real language instead of xslt etc. (btw xslt is ok, and I've done a fair amount of work with it but once you get past the simple stuff it is so wordy and restrictive you just pray for a "real" language instead)

Re:XML and Lisp.

[rodentia]

Which is cool, I love Scheme. But can I inline Scheme and make my ten-year-old, SGML-based pagination engine understand it? Let go of your hype, Luke. Use the code.

Or better:

Dammit, Jim, I'm a publisher, not a data-modeller.

Re:XML and Lisp.

[scrytch]

> But can I inline Scheme and make my ten-year-old, SGML-based pagination engine understand it?

Probably. Good SGML processing tools understand DSSSL, which is, of all things, scheme. SGML used to just break down entirely to sexps, but that approach wasn't fast enough, given the state of the art of scheme at the time.

Re:XML and Lisp.

[jacobm]

I don't think you correctly understand what the OP was saying. What he said, translated into CS-ese, was "The set of XML expressions is isomorphic to the set of Lisp s-expressions," a true statement. What you heard was, "The set of XML expressions is isomorphic to the set of Scheme programs," which is clearly not at all true -- as you point out, XML (and s-expressions) can be used to describe any sort of data, while valid Scheme programs are much more constrained and can only describe a particular set of computations (though the cool thing about Lisp is that programs are themselves represented as a subset of the very same sort of data that Lisp programs are best at manipulating, which is why Lisp macros are so incredibly more powerful than C macros). However, there's a trivial map from XML expressions to S-expressions, and Lisp loves S-expressions more than any other kind of data, which means that Lisp loves XML expressions almost as much.

Re:XML and Lisp.

[jacobm]

You are confused. There are such things as s-expressions, which are, loosely, any sort of balanced nested parenthesis thingy:

((() ((hi) (there mr)) slashdot) guy () () ())

is one, for example. Lisp (and Scheme, a dialect of Lisp) both a) represents programs as a particular subset of s-expressions, which we'll call the set of s-programs (which makes sense, right? Every program is a piece of data, but not every piece of data is a program), and b) has facilities for very easily manipulating s-expressions -- they are Lisp's favorite datatype (the name LISP comes from "LISt Processor," in fact, and s-expressions are really just a way of writing down lists). The appeal of using Lisp dialects to process XML is based not on the fact that those programs are S-expressions, but that they process S-expressions easily -- and, as it turns out, XML expressions can be trivially converted to S-expressions -- let's say that there's a subset of s-expressions called X-expressions, and there's a trivial bidirectional mapping between X-expressions and XML expressions.

So, let's say you want to write a program that reads and/or writes XML to communicate with the world. You can just write your program as a normal old S-expression-manipulating program, like Lispers have been doing since 1958, and then right where you read in the data, you call some function that reads an XML datum instead, and right where you write it out, you call some function that writes an XML expression. Now you can still use all the XML-processing gizmos you already have, but you can also write your own XML-processing gizmos really easily. In fact, I've been involved for some time in a Web programming language project, and that's how we manipulate XHTML: we read in XHTML expressions, manipulate them with Scheme code that's easy to write because the XHTML-to-S-expression mapping is so thin, and then write out XHTML expressions to the web browser. None of the other XML-based tools in the chain (the web browser, XML editors you use to generate the web page templates, et cetera) need to know or care about the fact that my implementation is in Scheme.

The only smugness you hear from the Lisp people (and this is where the faux comparisons between Lisp and XML come in) stems from the fact that Lispers have been storing their data the way XML does, only more cleanly and with less typing, for years. Now XML comes along and everybody thinks it's going to usher in world peace and change the way we put our pants on. Well, dammit, Lispers were already putting their pants on a different way, thank you very much!

Re:XML and Lisp.

[rodentia]

Not the one I'm using. Show me, master, I am eager for enlightenment. I know about DSSSL and its grandchild XSL, which has inherited its Schemy goodness. Which SGML processor are you thinking of? Clark's implementation did not, unless I wasn't paying close enough attention.

This is something I want. Not some crusty: Bah, its just sexps; but some working code.

Re:XML and Lisp.

[HiThere]

I'm not confused, particularly. But I don't believe that the tools that I am currently thinking of handle Scheme formatted s-expressions (presuming that you call XML s-expressions). I was particularly thinking of Open Jade.

In particular, I am contemplating ways of getting Docbook, etc. to process correctly as a component of other programs. Easy on Linux, on Win95 ... I haven't figured it out yet (well, the Open Jade site was down when I went there, which may have some effect on this....)

And it was in this context that I ran across an argument claiming that Scheme expressions were better than XML.

I suppose the short form of my question would have been "Better for what?", but that seemed discourteous. And besides, if there were a way to do this in Scheme, I wanted to hear about it. So far, no answers.

Re:XML and Lisp.

[statusbar]

"Better for what?"

Scheme is better for manipulation of XML.

Translating XML -> scheme is easy.

Manipulating s-expressions in scheme is powerful.

Translating s-expressions back to XML is easy.

It won't help your problem, though.

jeff

Re:XML and Lisp.

[jschrod]

You are right that languages from the Lisp family are a good tool to manipulate XML data streams.

But you are wrong when you tell that simple s-expressions are a good way to represent XML data streams in Lisp, due to their untyped nature.

1. Simple s-expressions make it hard to cleanly separate elements, attributes, and PCDATA.
2. One cannot dispatch methods over parts of simple s-expression, therefore code reusibility is lower.

Take a look at STIL (SGML Transformations In Lisp) (this is a link to a PS document). There you'll find an early experiment in the usage of Lisp for this problem class, an experiment that has influenced other style sheet language creators later on.

slashdotted - heres the summary

[CProgrammer98]

Interesting weekend! Here's the summary in case you can't get on, (or if you're lazy!)

As I've indicated, the interest of the workshop was as much what was going on outside the talks as well; Dan and I got to meet a load of interesting and clever people, and it was challenging for us to discuss our ideas with them - especially since we didn't always see eye to eye with our academic counterparts. Sadly, few people seemed to have heard much about Ruby, something they will probably come to regret in time. Dan seemed to have picked up a few more interesting technical tips, such as a way to collect reference count loops without walking all of the objects in a heap. Oh, and we found that you should pour liquid nitrogen into containers first rather than trying to make ice cream by directly pouring it into a mix of milk and butter. And that the ice-cream so produced is exceptionally tasty.

But seriously, what did we learn? I think we learned that many problems that we're facing in terms of Perl implementation right now have already been thoroughly researched and dealt with as many as 30 years ago; but we also learned that if we want to get at this research, then we need to do a lot of digging. The academic community is good at solving tricky problems like threading, continuations, despatch and the like, but not very interested in working out all the implications. To bring an academic success to commercial fruition requires one, as Olin Shivers puts it, "to become Larry Wall for a year" - to take care of all the gritty implementation details, and that's not the sort of thing that gets a PhD.

So the impetus is on us as serious language implementors to take the time to look into and understand the current state of the art in VM research to avoid re-inventing the wheel. Conferences such as LL1, and the mailing list that has been established as a result of it, are a useful way for us to find out what's going on and exchange experience with the academic community, and I look forward intently to the next one!

Re:slashdotted - heres the summary

[Linux Ate My Dog!]

Where do they get clean liquid nitro? The people at Harvard Med or Harvard Public Health always tell me that the liquid N they work with always has ugly icky brown dusty crud at the bottom of the containers, and thus they'd never eat it.

Best language for...?

[Ziviyr]

So, did they get around to figuring out which language is best suited to control a robotic arm in such a way to dump milk and butter into liquid nitrogen?

"My language tastes better!"

Re:Best language for...?

[connorbd]

Butter? Don't you mean cream? I wonder what exactly the definition of "lightweight languages" is here. Perl is not my idea of lightweight; lightweight *programs* are pretty easy to write, but the language and its environment are *huge*. Python isn't that small either.

Pascal is a lightweight language, even with extensions. Take a look at pax -- that's very possibly the smallest non-obfuscated functional language out there. Take it to another level: Befunge. False. Brainf*ck (the smallest Turing machine implementation I've ever seen). OISC, living proof that Subtract and Branch If Negative is all you need.

Though to be honest with you, when I think lightweight... HTML is precisely one example. The Unix Shell(s), with the possible exceptions of bash and ksh93. JavaScript, if not in execution, is lightweight in concept; Java is not, though it was intended that way. Scheme is lightweight; Common Lisp is not. Snobol probably was. *roff is, PostScript is not. Forth is; var'aq is not. Lightweight implies two things to me: small overhead and specialized (though not necessarily limited) functionality.

So yeah, I don't much like the name of this conference.

/Brian

Re:Best language for...?

[Anonymous Coward]

They should use liquid hydrogen instead -- at least, it is lightweight.

8oP duh!

Windows XPires.

Whats the "lighest" you can get?

[Anonymous Coward]

How "lightweight" a language can you produce, yet keep it usuaable?

To me, it would seem that the lighest I can come up with is:

• The ability to create variables, and assign an absolute value to them
• Comparision, with equals, is less than and is greater than
• Branches to an absolute position in the code
• Math operators + & - only
• Ouput to screen.
• Input from keyboard

So would that be usuable? A simple program such as:
VAR A
VAR B
INPUT A
INPUT B
C=A+B
PRINT C
GOTO 3

Can we get even more lightweight? :)

Re:Whats the "lighest" you can get?

[Voidhobo]

How "lightweight" a language can you produce, yet keep it usuaable?
To me, it would seem that the lighest I can come up with is:
<snip>

You sir, are mistaken. The only ability a programming language really needs is to output "Hello world" to the screen. Here's an interpreter (in Perl), let's see if you can guess the syntax:

print "sansChoice interpreter\n> ";chop($code = );print "\nHello world!\n";exit;

This is a powerful, intuitive, interpreted, simple, no-point-oriented (NPO) helloworlding-language.

Re:Whats the "lighest" you can get?

[popeyethesailor]

Usable for what?

Re:Whats the "lighest" you can get?

[Tom7]

Well, we can see that you learned to program in BASIC. ;) Not all languages need assignment as their primary form of computation ...

I'd say that the lambda calculus is more lightweight, and also easier to program in than your example:

exp ::= x (variable)
| exp1 exp2 (application)
| (fn x => exp) (function)

Basically the key is that you have higher-order functions (you can pass them around), and that's it. With this, it's relatively easy to code up booleans, integers, lists, recursive functions, trees, or practically anything. (If you wanted to do IO, you'd need some kind of primitive functions for interfacing with the machine.) Since everything is higher-order, it's easy to code these once and then pass them around. It's not as nice as a modern language, but it's nicer than a turing machine...

Actually, there is a simpler language that uses only two functions (!), but this one is pretty hard to program in directly.

Re:Whats the "lighest" you can get?

[dmorin]

VAR A
VAR B
INPUT A
INPUT B
C=A+B
PRINT C
GOTO 3
Can we get even more lightweight? :)

Sure. Why do you have to specifically declare variables? And why have a special syntax for "input a", why not just have input return it's own value?

(print (+ (read) (read)))
Heyyy, that looks familiar....:)

Re:Whats the "lighest" you can get?

[Anonymous Coward]

General use. For example, could you write a simple game (Say, Pong) with it? How about the perenial favourite "What is your name?" Could you do more complex things with it, such as mangle a simple email address into an RFC 2822 compliant address? Sort a list of values?

Think simple tasks that you would do with e.g a shell, or Perl, or even small C programs. How far can you strip a language down, yet still be able to acomplish those tasks?

Re:Whats the "lighest" you can get?

[Anonymous Coward]

O.K, i'm replying to myself, bad form I know. I want to clarify my "challenge". Namely

How "lightweight" a language can you produce, while still being Turing complete. Also, I'm thinking more from an implementation view, rather than the language itself. That is, not only would the syntax itself have to be simple, but also the lexical scanner and code generation.

P.S: Thats why my example specifically declares the variables, as it's much simplier for the scanner to manage in my experience. ;)

Re:Whats the "lighest" you can get?

[StrawberryFrog]

The lightest computer mathematically proven to be equivalent to any other lanuage is the Turing machine,

If you want to experience the Turing tarpit (where anything is possible, but nothing is easy enough to actually do) firsthand, try the Brainfuck language, based closely on the turing machine. the language has 8 instructions, and only one of them (input) has any arguments beyond an implicit current location. The compiler is 240 bytes!

Re:Whats the "lighest" you can get?

[BiggyP]

Lightweight? you mean Visual Basic?
yes i know it's very usefull for some purposes, but ultimately it's a lightweighrt language.

Re:Whats the "lighest" you can get?

[DaoudaW]

try the Brainfuck language

Bf is a lot of fun, but not light in the sense of perl or scheme. Since the article didn't define light language, I'll give it a shot. Looking at their choice of languages, light appears to mean: easy to program, easy to understand, but powerful, interpreted languages. Bf is none of the above. About all you can say for it is Turing-complete!

Re:Whats the "lighest" you can get?

[Black Parrot]

> You sir, are mistaken. The only ability a programming language really needs is to output "Hello world" to the screen. Here's an interpreter (in Perl)...

That's nothing. I'm putting the finishing touches on my new processor design, and includes a native PHW opcode, no arguments.

Re:Whats the "lighest" you can get?

[MarkusQ]

If you want to experience the Turing tarpit (where anything is possible, but nothing is easy enough to actually do) firsthand, try the Brainfuck [muppetlabs.com] language, based closely on the turing machine. the language has 8 instructions, and only one of them (input) has any arguments beyond an implicit current location. The compiler is 240 bytes!

There's an x86 compiler for bf at ~170 bytes, but isn't the smallest bf compiler written in bf well over a gigabytes?

-- MarkusQ

Re:Whats the "lighest" you can get?

[orlovm]

Heh, your notion of "relatively easy" and "not as nice" must be somewhat different from mine...

Actually, there is a simpler language that uses only two functions (!), but this one is pretty hard to program in directly.

Are you talking about the IJ basis for the lambda calculus?

Re:Whats the "lighest" you can get?

[Hater's Leaving, The]

YEah, they don't really say what 'lightness' is. Given the examples listed above, I'd say not were light. I'd say they are all bloated pigs. And I program professionally in at least 2 of them.

For what I consider to be light I'd suggest C or Lisp personally.

Forth is lighter, but it's 15 years since I've done any of that, even though it is still quite popular in the embedded realtime world due to its lightweightness.

THL.

Re:Whats the "lighest" you can get?

[Doomdark]

One thing about 'lightness' of a language is that people often forget the division between the (core) language and libraries. For example, Java as a language is still reasonably simple (and was even more so before 1.1 added new class contstructs for anonymous inner classes etc). However, its class libraries are... um... obese. :-)

Of 'real' languages, I think JavaScript is reasonably light-weight (keeping in mind that DOM is not really part of language) yet complete enough, although often overlooked as a toy language. That has more to do with usage of JS, than with the core language itself. It is kind of interesting doing OO stuff in JavaScript... bit like doing OO things in C (although JS does have more support for objects, so its easier to fake stuff as classes and inheritance through prototypes) or in Perl. Sadly, most JS books all but skip over the features that make usage of language more bearable to 'real' programmers.

Re:Whats the "lighest" you can get?

[Tom7]

> Heh, your notion of "relatively easy" and "not
> as nice" must be somewhat different from mine...

Well, maybe I think differently. I really do think it is easier than at least the example I was replying to, since it is possible in the lambda calculus to write a piece of code once, and then bind it to a variable, and then use it anywhere you like. (So I could write Zero and Successor and Plus and If and True once, and slowly build up a much more useful programming language.)

> Are you talking about the IJ basis for the > lambda calculus?

I was talking about the S and K combinators, which are these closed functions:

K x y = x
S x y z = (x z)(y z)

It turns out you can rewrite any lambda calculus program, and thus, any computable function, with just these! (One of the neatest things I've ever learned...)

Re:Whats the "lighest" you can get?

[StrawberryFrog]

Looking at their choice of languages, light appears to mean: easy to program, easy to understand, but powerful, interpreted languages

Yup, BF, turing machines & lambda calculus are "light" in the sense that they are tiny but theretically complete & of not much practical programming use. For instance, you can't do TCP sockets in Brainfuch no matter how hard you code, cos there's no way to get to the OS socket API.

The PHP that I use at work (and the Perl, Python, Ruby etc that other people use for similar tasks) are "light" in the sense of flexible, and quick to knock something together, inegrates well & comes with a great big heavy library full of usefull stuff.

Re:Whats the "lighest" you can get?

[Anonymous Coward]

Use the same technique used to make daemons out of postscript and bourne shell. Put the interpreter into inetd.

Re:Whats the "lighest" you can get?

[Anonymous Coward]

SBN.

Subtract and Branch if Negative.

It takes 3 operands (although you can reduce this to two and an accumulator register if you'd like). Its implementation is effectively:

if (A - B) 0 then jump C

Make variables defined by their first use, and have line numbers for branches and you're done.

Re:Whats the "lighest" you can get?

[scrytch]

Can we get even more lightweight? :)

Oh my, yes. All you need to compute is three operations (and another couple to do i/o). Check out unlambda. Lighter than brainfuck, probably even more maddening, since it doesn't have state like a turing machine does.

Change the i/o ops to read and write arbitrary memory locations, and you could write an operating system in unlambda (same goes for any other of these toy languages)

Re:Whats the "lighest" you can get?

[orlovm]

I was talking about the S and K combinators, which are these closed functions:

K x y = x

S x y z = (x z)(y z)

It turns out you can rewrite any lambda calculus program, and thus, any computable function, with just these! (One of the neatest things I've ever learned...)

Oh, thanks - now I remember :) I and J are similar to S and K, but for another variant of lambda calculus, where all variables must be "used" (so, K would not be valid anymore).

By the way, did you know that you can express both S and K using only one combinator?

If you define X as lambda x . (x S K), then (X (X (X X))) and (X (X (X (X X)))) resolve to K and S, respectively. This one was invented by Mayer Goldberg, our CS faculty member.

Re:Whats the "lighest" you can get?

[Anonymous Coward]

I was talking about the S and K combinators, which are these closed functions:

K x y = x
S x y z = (x z)(y z)

You can actually get down to just one function! Moses Schonfinkel invented the S and K combinators, and in the paper in which he proposed them he suggested that you could define a function J:

J J = S
J S = K

So you can write S as JJ, and K as J(JJ). Then you can write any function with just J's and parentheses.

There's even a more natural way. Henk Barendregt points out (in his classic book on the Lambda Calculus) that you can define a function:

X y = y K S K

Then:
X X = X K S K
= (K K S K) S K
= (K K) S K
= K K

So (X X) X = (K K) X = K
and X (X X) = X (K K) = K K K S K = K S K = S.

Now that is cool!

Re:Whats the "lighest" you can get?

[Tom7]

I'm pretty sure the original paper (by Curry I think) had a J combinator that acted similarly, but this definition is nice and easy to remember... neat!

Re:Whats the "lighest" you can get?

[rabidcow]

aw, beat me to it...

This is known to some as "One Instruction Set Computing".

Re:Whats the "lighest" you can get?

[ignavus]

Why do you need the VAR statements? You don't have a VAR statement to declare the variable C - and quite right, too. But in any case, why do you need the useless assignment to C? You could just write:

INPUT A
INPUT B
PRINT A+B
GOTO 1

For every language, there is always a language lawyer waiting in the wings to correct you :-)

Re:Whats the "lighest" you can get?

[ignavus]

And if you REALLY want lightweight, why not just:

LOOP PRINT (INPUT + INPUT)

Coolest part

[Jerf]

I think we learned that many problems that we're facing in terms of Perl implementation right now have already been thoroughly researched and dealt with as many as 30 years ago; but we also learned that if we want to get at this research, then we need to do a lot of digging. The academic community is good at solving tricky problems like threading, continuations, despatch and the like, but not very interested in working out all the implications.... So the impetus is on us as serious language implementors to take the time to look into and understand the current state of the art in VM research to avoid re-inventing the wheel.

I think that's the coolest part of probably the whole conference. If perl/Parrot/Python can manage to take the best of both the academic and the practical worlds, they'll be unstoppable. Heck, it might even be a first! The two seem allergic to talking to each other, as if they'll become contaiminated, rather then treating each other as a chance to learn, grow, and test.

Re:Coolest part

[eddy the lip]

i'm not sure if they're allergic to talking to each other, at least at the level of people that are actually doing something with the language, instead of yelling "my dad is bigger than your dad" from the top of two equally high piles of mud. both camps seem interested in the possibilities of a vm that will handle both languages. (as a user, i certainly am). larry and guido take occasional shots at each other's creation, but it seems pretty good natured. if i recall, larry even mentioned a couple of python features he liked in one of his apocalypses. (could be wrong - no time to check).

i started with perl, love the language and have no plans on giving it up, but i've been looking at python, and i can see myself using both. i don't see the problem with that.

unfortunately, both languages have a lot of users that are ill-behaved children.

Have you tried UF ?

[Bug2000]

And what about this ? At least to represent the commercial side of language design...

Re:Have you tried UF ?

[sv0f]

Wow, that was seriously unfunny.

Just what we need more of

[Clovert Agent]

This is just the sort of discussion I like to see happening. Not a "my language is better than yours" bout, but a frank examination of what makes a language good, and what makes it better.

I get very tired of the "X is better than Y" fights. They're pointless, and if this collection of language pros can avoid it, so can we. The better language is the one that gets the job done best for you, period.

Rather than clinging to our cliques, getting together with users and creators of other languages is beneficial to everyone. Hybrid vigour, if you like.

It's this sort of cooperation the open source movement in particular should embrace, not petty squabbles over syntax preferences. In the end, everyone should win.

Re:Just what we need more of

[Bug2000]

A language is just a way to manipulate abstract concepts... The more concepts you have, the harder it is to make a language lightweight. It makes me think of those synthesisors with 3 buttons that had all functionalities through combinations of those 3 buttons. To me, it is just as hard as having more buttons. The essential thing is to understand the concepts you're trying to manipulate. Then anybody can learn any language...

Re:Just what we need more of

[spinwards]

Although i do agree that the petty squables are not very productive, they do create diversity between language syntax, which i think is a good thing. There is an amazing amount of overlap in functionality, and someitmes sytax is the only thing that really sets the languages apart. If i am more comfortable with algol descendant languages, why should i have to learn scheme syntax, when there are tools that will work for me in a style that i am comfotrable with. I know that it doesn't take too much time to aquire a cosmetic knowledge of a language (knowing what c functions aproximately map to what lisp functions, and such), but if i could use a tool that i am already comfortable with would mean NO learning curve. Colaboration is good, but not to the point if having only one or two languages left to use.

Liquid Nitrogen Ice Cream

[John Harrison]

From the article (seriously):

Oh, and we found that you should pour liquid nitrogen into containers first rather than trying to make ice cream by directly pouring it into a mix of milk and butter. And that the ice-cream so produced is exceptionally tasty.

Years ago I read an article about a guy from Jackson Hole, Wyoming who made gourmet ice cream. He had determined that the two things that separated good tasting ice creams from the rest were:

1. Fat. Ice cream needs lots of fat.

2. Size of the ice crystals. The water in ice cream can be frozen in big crystals or little ones. If you freeze it slowly, you get big crystals. Freezing quickly leads to small crystals. Small crystals == better ice cream.

So this guy found that he could make the smallest crystals by pouring everything into a big bowl with some liquid nitrogen and stiring it really quickly. This was after trying several different methods of freezing the ice cream, none of which were fast enough for him.

He said that a good test of ice cream was whether it floated in water. Good ice cream should be dense enough to sink. I guess this is due to the high fat content. Of course once you put it in water, it is no longer good ice cream, right?

Re:Liquid Nitrogen Ice Cream

[san]

???

Fat is *less* dense than water (it floats).

Maybe the right kind of cold fat sinks (as opposed to the water which expands upon freezing)?

Anyway, sinking ice cream is strange.

Re:Liquid Nitrogen Ice Cream

[bfree]

In the UK they have a very strange TV presenter called Jeremey Clarkson who came to fame as an over the top presenter on TopGear. For a short while he had a "chat show" where he would take a small part of each show to do something silly and extreme including making ice cream with Liquid Nitrogen! It was hilarious, simple, effective and brilliant, now if only I still worked at tarrc where their was a plentiful supply of liquified chemicals :-)

Re:Liquid Nitrogen Ice Cream

[PhilHibbs]

Of course once you put it in water, it is no longer good ice cream, right?

You could wrap it in clingfilm and fish it out again.

Re:Liquid Nitrogen Ice Cream

[mdahlman]

Good ice cream sinks, but it's not because of the fat content. It's due to the air content.

In some places there's a limit on how much air can be in ice cream: 50%. There's no lower limit, but at 0% you've just got a block of ice. So there's a de facto lower limit.

Something like Ben and Jerry's has much less air. That's why it's less dense, and that's why sinking ice cream can be a measure of quality.

Re:Liquid Nitrogen Ice Cream

[psavo]

He said that a good test of ice cream was whether it floated in water. Good ice cream should be dense enough to sink. I guess this is due to the high fat content. Of course once you put it in water, it is no longer good ice cream, right?

once upon a time there was a time when I and my gf didn't know eachother very well, well, basically we were dating. So, to make long story short, once we bought a packet of cheapo ice-cream (1kg, banana-chocolate). Well, at that night we couldn't eat it till the end.. so we desided to dump it. Into toilet.
Guess what? It didn't go down. That brick'o'**hit floated there. I read a short prayer upån it's soul, and we went to bed. In the morning it was all melted and went down beautifully.

And the moral of the story?

you tell me some.

Re:Liquid Nitrogen Ice Cream

[thing12]

Try freezing a stick of butter and dropping it into a bowl of water. Sinks right to the bottom. Being that water expands when it's in the temperature range where it starts to freeze, and everything else in the universe contracts (afaik). Water is unique that way.. it's really cool too if you think about it because if water didn't expand then we wouldn't have ice on the tops of lakes there would be no life on earth.

But anyway if you have lots of fat in the mix, it should sink when it gets cold because as a whole it will be more dense than the water surrounding it.

Re:Liquid Nitrogen Ice Cream

[Chelloveck]

We sometimes do this as a party trick at midwest SF cons. Take your basic ice cream recipe in a big bowl, then have one person slowly pour LN2 from the dewar while the other one stirs maddly. I'm not sure why the article recommends pouring the nitrogen into containers first.

Liquid oxygen works wonderfully as well. Last summer in Michigan we made LOX ice cream with freshly-picked thimbleberries. (And no, it doesn't burn! Not even when you put a blowtorch to it...) In a pinch you can even use dry ice. Have someone rub a block of dry ice on a cheese grater over the bowl. This method tends to leave some residual carbonation in the ice cream. Bring along root beer extract for flavor!

Other fun cryogenic tricks -- Everclear (198 proof grain alcohol) will freeze at liquid nitrogen temperatures. Small pieces chipped off evaporate marvelously on the tongue. An inverted scotch-on-the-rocks can be made by freezing scotch in an ice-cube tray and adding the cubes to a little water or soda. Winecicles are interesting, too, but beware the tongue-and-flagpole effect when you lick them!

Re:Liquid Nitrogen Ice Cream

[TheSync]

you should pour liquid nitrogen into containers first rather than trying to make ice cream by directly pouring it into a mix of milk and butter.

You can check out my video about making ice cream with liquid nitrogen. I'm a bit afraid about the butter part, generally LN2 ice cream is made with milk and heavy cream, plus sugar and vanilla. I'll have to try the pouring mix into LN2 rather than pour LN2 into mix.

Re:Liquid Nitrogen Ice Cream

[Elian]

The LN2 went into small containers because they got it in a rather large (like 1.5M tall) container. There was a hunk of copper tubing hooked to the valve on the big tank. Unfortunately the copper tubing was rather warmer than the LN2, so the LN2 had a disconcerting tendency to heat up and go gaseous by the time it hit the end of the tube. Gaseous nitrogen's just a little bit less dense than the liquid, so sometimes you'd get this huge gout of gas spewing into the ice cream mix. While much hilarity (and splattered ice cream mix) ensued, it didn't make for great ice cream.

Putting it into containers and pouring made it so the gas could spout out harmlessly, since the containers were empty.

Re:Liquid Nitrogen Ice Cream

[ceo]

At a weekend camping party that my crowd of geeks has every year, a major part of the event is making an incredible amount of LN2 ice cream. We started out making it the conventional way, then someone heard about making it with LN2 and brought some to experiment with, and we quickly discovered that it makes better ice cream and is much faster (important when you're making quart quantities of a lot of flavors. So now it's all LN2. Chocolate Peanut Butter Malted Milk Ball, anyone? How about Coconut Lime Habanero?

We stir the LN2 gradually into the ice cream mix. I don't know how putting the LN2 in the container first would work, because in our experience, different mixes seem to require different amounts of LN2.

A neat thing to do with LN2 is to extract LOX from the air. Pour some LN2 into a metal saucepan, and hold it over another container. Small drips of LOX will condense on the ouside of the saucepan and drip into the other container.

Re:Liquid Nitrogen Ice Cream

[Corporate Troll]

I could really imagine some other fun things to do with ice-cream and a girlfriend except eating it (I mean the ice-cream, not the girlfriend)
*evil grin*

Re:Liquid Nitrogen Ice Cream

[Anonymous Coward]

What happens when you put steel wool in LO2?

Re:Liquid Nitrogen Ice Cream

[Anonymous Coward]

Elemental Gallium also has the property of expanding when it freezes. Gallium metal is interesting stuff - you can melt it in the palm of your hand, and it wets glass and porcelain.

Re:Liquid Nitrogen Ice Cream

[John Harrison]

Could someone explain to me how this comment is currently rated a '4' but mine, which is the grandparent of this comment, got modded up to '5' then down to '-1' and now is resting at '0'?

Hooray for lemming moderation!

PS, this guy is right about the air.

What about INTERCAL?

[mfarah]

I can't believe it. They talked about Perl, Scheme, Python, etcetera. Yet they didn't invite ESR to talk about the unique problems (and solutions) that implementing INTERCAL poses.

I sure hope next year's LL2 addresses this issue.

Re:What about INTERCAL?

[Skraig]

ESR can be very controversal. Maybe they were trying to stay especially on topic. Hopefully next year they can invite someone involved with INTERCAL to discuss the topic.

As has been said elsewhere, these kind of conferences are really focused on trying to find common ground so knowledge can be spread between specialists.

ESR has an unfortunate reputation for stridency, this could have been a reason for his absence.

INSERT SIG HERE

Re:What about INTERCAL?

[zephc]

You gonna pass that crack pipe around, or are you just gonna keep it to yourself?

=]

Re:What about INTERCAL?

[Elian]

He was invited. He just couldn't make it that weekend. Which was a pity, because I wanted to discuss getting an INTERCAL parser for Parrot... :)

Re:What about INTERCAL?

[Skraig]

OH, my mistake then. I take it all back. I even take back several things said by other people.

Re:What about INTERCAL?

[Skraig]

alright you can have some

Re:What about INTERCAL?

[Greg Sullivan]

I'm the co-organizer of the LL1 workshop, at
ll1.mit.edu

Actually we did invite ESR, and we actually scheduled the workshop around his constraints. However, there were a few misunderstandings, and four days before the workshop we got mail to the effect that he wasn't coming.

Maybe next time.

didn't really expect a flamefest..

[TechnoVooDooDaddy]

any similar conference i've ever been to (including some W3C working sessions) have been extremely professional, even when working on standards. IMO the only time you get flamefests is on the internet on boards/newsgroups populated by wannabes who don't fully understand what they're flaming about, and the flames are pretty much just a front to cover their lack of knowledge/experience. on the other hand, stick a bunch of knowledgable people in the same room, and considerable respect for each other is shown.

cURL adresses the niche of Flash???

[Qbertino]

Well, I don't know cURL, but I shure do know Flash. And from what I get from the cURL site it doesn't seem to have anything to do with Flash or it's "niche".
I wonder what this guy is talking about.

Re:cURL adresses the niche of Flash???

[Mr. Fred Smoothie]

He's talking about curl, not cURL.

Not a flame fest, but a bit of tension

[srichman]

I was at the workshop, and while it was mostly congenial, there was definitely a bit of tension between the academics and the "industry" folks (if you could call them that...). Basically, the dichotomy was between PL researchers, who espouse the virtues of Scheme dialects and other well designed but not widely used languages, and the applied folks, namely Simon Cozens (Perl), Dan Sugalski (Perl), and Jeremy Hylton (Python), who implement widely used lightweight languages that aren't as "respectable."

There was a bit of a superior attitude from some of the academics, who feel that languages like Perl and Python reinvent the wheel and neglect the body of academic research by coming up with suboptimal solutions to PL problems that have long since been "solved" in the PL literature. Maybe "frustrated" is a better word than "superior." While I can totally appreciate their point of view, I found myself cringing in embarrassment once or twice when a harangue by one of the academics went a little overboard. There has already been one post on the LL1 mailing list that I feel crossed the line.

The discussion came to a bit of head during the (very interesting) "Worse Is Better" panel (based loosely on the writings of Richard Gabriel), which centered on the question of why the most popular languages aren't the "best" ones.

Like I said, though, it was mostly very congenial. Ultimately, I think each camp took something away from the encounter: both new-found implementation techniques, and a greater knowledge of and interest in the other community. There are some practical issues that the Perl/Python guys have to deal with (e.g., interfacing with legacy languages like C) that aren't really addressed by academics, and I think it was great that these issues were brought to light.

The LL1 website, if anyone is interested, is ll1.mit.edu.

Academia to Hackers

[Tom7]

I think we learned that many problems that we're facing in terms of Perl implementation right now have already been thoroughly researched and dealt with as many as 30 years ago; but we also learned that if we want to get at this research, then we need to do a lot of digging. The academic community is good at solving tricky problems ... but not very interested in working out all the implications.

This is the best paragraph in the article. Here's what makes me sad:

Slashdot-type hackers have an amazing ability to get things done. They can really come up with a working product faster than anyone.

BUT, slashdot-type hackers have a tendency to implement olddd ideas, and also frequently to make well-understood mistakes. It is true that we are on the cutting edge of implementing internet protocols and maybe window managers, but in other areas we are implementing 30 year-old ideas still. (OS design and programming languages come to mind especially.)

WHO, if not the hackers, will embrace this stuff? They are the only ones that are supposed look beyond the hype and marketing and status quo to evaluate things based on technical merits, and to create implementations of new ideas.

I know only the OS design that I learned in my undergraduate course. But that is enough to know that the design of the kernel is very conservative! Where are capabilities? Where is fine-grained access control? Does anybody *really* think that their internet daemons should run as *root* just so they can open up a port with a low number? (I know there are plenty of workarounds...) I am sure that there are dozens of great ideas in OS design from the last 20 years that would be totally appropriate for a hacker's kernel.

I know a bit more about PL design. Being in academia pollutes the mind, I know, but I am sure that almost all I see in the slashdot PL community is reworking of old, mediocre ideas. Who in the world will use and develop new programming languages if not hackers?

(So, the PL fanatic in me wants to point out caml, which, even though it is not my personal favorite, I think could become really popular with slashdot-style hackers. It is really fast -- probably the fastest, it is hacker buzzword-compliant (it has "objects"), and yet it has taken many great ideas from academia and put them in a really usable, accessible form. Try it if you are in for a taste of something different!)

Anyway, just trying to say that if you are tempted to go hack up your own programming language, please at least don't assume that Perl is the state of the art because it is the most popular scripting language or something. Take a class, read a book, and check out some of the weirder languages coming out of academia first. Hackers are how the revolution happens...

Re:Academia to Hackers

[Junks Jerzey]

I know a bit more about PL design. Being in academia pollutes the mind, I know, but I am sure that almost all I see in the slashdot PL community is reworking of old, mediocre ideas. Who in the world will use and develop new programming languages if not hackers?

(So, the PL fanatic in me wants to point out caml [inria.fr], which, even though it is not my personal favorite, I think could become really popular with slashdot-style hackers.

Of course ML languages are 20 years old, and Caml was developed *before* Perl and Python. So it isn't necessarily that the newer ideas are better, just that lots of good ideas tend to get lost to history for various reasons.

Re:Academia to Hackers

[vroomfondel]

You don't get to the cutting edge of programming language research by wasting your time working out the finer implementation details of real languages, especially since real languages frequently have to do things that don't make for terribly fascinating research.

You don't get to the cutting edge of programming lanugage implementation by wasting your time reading the many years of esoteric research published on the subject, especially since real languages frequently have to do things that don't make for terribly fascinating research.

Re:Academia to Hackers

[Tom7]

> You don't get to the cutting edge of programming
> lanugage implementation by wasting your time
> reading the many years of esoteric research
> published on the subject, especially since real
> languages frequently have to do things that don't
> make for terribly fascinating research.

Of course this is true, but I am not asking anyone to waste years on *esoteric* research. I am merely proposing that people designing a new OS or programming language look at the current state of the art; to at least know about and consider seriously the *known good ideas* in academia.

Here are some glaring examples of features that ML (for instance) has that are *damn useful*, totally not esoteric, yet typically don't even find their way to the table in the design of a slashdot programming language:

- parametric polymorphism. (No casts!! Java is slowly getting this, finally; they call it "generics").
- datatypes and pattern matching. (Makes processing recursive data structure like lists and parse trees beautifully simple!)

There are many other things I can think of, which have varying degrees of obscurity, but I think these two are firmly on the useful side.

My point is that people somehow bizarrely confuse "popular" with "state of the art". Like, in a slashdot discussion about programming languages, I invariably hear, "X is better than Y because X is object-oriented," as if object-oriented programming is the pinnacle of PL design. It's 30 years old! (Even the ideas I propose above are about that old!) It is worth looking at more recent ideas, and those aren't typically to be found in mainstream programming languages.

Re:Academia to Hackers

[vroomfondel]

I agree completely with your point. I wasn't trying to disagree with it in my earlier post, which was at least partially a poor attempt at a joke anyway. My only point was that everybody has a finite amount of time on their hands over the course of their careers -- there's time for keeping up with research, there's time for working on one's own projects, but rarely do the two meet. Most people in the field, I'm sure, have spent a significant amount of time on both. However, their experience will range along a sliding scale from 100% academic to 100% practical. It's a tradeoff, just like everything else in engineering and/or life (there are those who claim the two are mutually exclusive...). There's no such thing as a 200% career, at least for most of us. God knows I'd love to be the guy who knew everything and had done everything, but alas...

Re:Academia to Hackers

[alienmole]

...especially since real languages frequently have to do things that don't make for terribly fascinating research.

Actually, I think this is flat wrong. Can you think of an example? Just about every aspect that current "real" languages implement has been researched to death - and then some.

You don't get to the cutting edge of programming lanugage implementation by wasting your time reading the many years of esoteric research published on the subject

If you're a professional language designer - and I know a few - and you don't do this, you're pretty much doomed to failure, because someone who knows what they're doing is going to come along and eat your lunch. Java is a case in point - one of the designers was Guy Steele, co-inventor of Scheme. He knew what he was doing, and although Java is chock-full of interesting and questionable compromises, it still blows away many other "real" languages.

Intelligent people don't argue about language.

[Junks Jerzey]

it wasn't the flame fest you might have imagined

Not surprising. The only people who get into flame-fests about programming language choice are insecure newbies. It comes down to the same reason kids argue about whose game system is better: they got one for Christmas and feel compelled to defend their choice, because they can't afford another. Once you know a sizable number of computer languages--especially different styles of language--then you no longer feel a need to be so petty. Different languages have different strengths.

Re:Intelligent people don't argue about language.

[Anonymous Coward]

Looks like someone is jealous they cant afford a XBOX and a GameCube.

Dont feel bad. =(

Re:Intelligent people don't argue about language.

[Anonymous Coward]

The Tao gaev birth to machine language. Machine language gave birth to the assembler.

The assembler gave birth to the compiler. Now there are ten thousand languages.

Each language has its purpose, however humble. Each language expresses the yin and yang of software. Each language has its place within the Tao.

But do not program in Cobol if you can avoid it.

Re:Intelligent people don't argue about language.

[Anonymous Coward]

so spake bigego, little peepee, no wantum for
wampum, egregious malcoder.

It all boils down to bit flipping 1's and 0's

[3seas]

Since programming language vocabulary and syntax is the human side of a human -> machine translation process (a process of translation through an interpreter, compiler, whatever etc.. to 0's and 1's), and usually requiring human "logical" thinking, isn't the real objective here one of identifying and defining abstraction manipulation functionality, the logic of translation mechanics?

Certainly if the target is to be an optimized sequence of 0's and 1's then is it not the translation mechanics responsible for getting it there, and from whatever vocabulary(s) and syntax(s) used?

This is where I believe genuine computer science and software development research got seriously distracted by the carrot of money. And as it was mentioned in the article regarding not doing it right in a tradeoff of getting it out the door, getting back to genuine computer science may be difficult to do! But it also seems to be an ongoing and growing problem in genuine Software Engineering. The latest version of a need to solve the software crisis?

Note that IBM presents a white collar high dollar I/T solution direction intent, but without any identification of the base functionality mechanics of translation.Read Written Comment #4 after reading the "Manifesto" at the above IBM link.

With all this in mind, what are all these "Lightweight Languages", but examples of how many ways you can create a custom vocabulary, syntax and translator that outputs 0's and 1's not always in the optimum sequence?
.
.

Re:It all boils down to bit flipping 1's and 0's

[scrytch]

Thinking in terms of "1's and 0's" is seriously wrong. Binary data is simply data, it does not represent computation itself. You can encode a UTM in base 2, 3, 10, or 287 if you like. There is trinary computation, as covered on slashdot only a few days ago, there is quantum computation, which really flies in the face of a lot of classical computing rules.

The fact that every language is an application of basic computing concepts is no more help than telling a research pathologist that all viruses are made of matter. It's simply not science to keep pointing out things we already know.

Re:It all boils down to bit flipping 1's and 0's

[3seas]

When we actually have trinary state hardware then it will be a matter of translation processes that boils down to trinary states for that type of hardware. For quantum state, translation proceses that boils down to quantum states, for quantum state hardare. For analog computing, the translation process would .......

Encoding to a selected base is also a translation process, but not one that is directly compatable with the hardware without further translation (that you don't see), unless it is to the base compatable to the hardware.

Hardware is made of matter and apparently a refresher course wouldn't hurt you. Back to basics is always a good thing when you have forgotten them or have gone astray to the point of failing to solve problems like the software crisis.

.

Obviously...

[mirko]

If we don't take the learning curve into account, you might en up with Color Forth
(or any other Forth derivate, such as BigForth - for Linux and Windows - which include a breathtaking GUI RAD : Minos)...

Here's a small ColorForth program: This consists of an IDE disk driver.

Re:Obviously...

[Tom7]

ehehe... gotta love a language where "till" (as in "wait till") is a keyword. ;)

Lightweight Languages for Heavyweight AI

[Mentifex]

http://mind.sourceforge.net/ruby.html is the Mind-to-Ruby liaison page between the Open Source AI Mind in JavaScript for Web migration or Forth for robots and the several hundred other SourceForge AI projects in the various "lightweight" languages and the ones made of sturdier, sterner stuff.

A Mind-to-Visual-Basic liaison page leads to the 3 April 2000 Mind.VB port from Mind.Forth into Visual Basic.

The Mind-to-Java liaison page links likewise to the Mind.JAVA port of June 2001 from JavaScript into Java.

The so-called "lightweight languages" will play a heavy-duty role in the emergence of public-domain, open source artificial intelligence.

Parrot - new Lingua Franca?

[Ars-Fartsica]

The best development for little language writers could be Perl 6's Parrot "assembly" language. By focusing on the details of executing a very low level language very quickly on a huge number of platforms, the Perl team will be providing an excellent VM model that should minimize the need for language designers to worry about issues like GC and other system headaches.

I doubt this is the first effort to create a popular open VM, but it seems to be one of the most heavily promoted. Hopefully we will see Parrot-based languages springing up everywhere, and perhaps even ports of existing languages.

Lightweight Languages?

[CynicTheHedgehog]

What exactly constitutes a lightweight language? Is it a scripting (interpreted) language? Or one that serves as a building block for other languages (a micro-language, so to speak)? Or is it merely any language that can be used for Rapid Application Development? I thought I caught a reference to Java in that article (used as a comparison), which I don't consider to be "lightweight" by any means, and I've heard people swear by Python as a full-blown development platform (I don't know anything about Python, so forgive me if I sound ignorant). It seems as if a lightweight language is basically one that is an open source work-in-progress.

Best quote from the article

[avdi]

"Sadly, few people seemed to have heard much about Ruby, something they
will probably come to regret in time."

Re:Best quote from the article

[Anonymous Coward]

They'll regret not having heard much about Ruby
because they could have been programming in Ruby
all this time. Ruby is a joy to program in.

Re:Best quote from the article

[Anonymous Coward]

Ruby is very pretty. But it can do a lot too.

My favorite lightweight language...

[TheSHAD0W]

is C.

It's also my favorite language, period. I'm not talking about C++ either. Plain old C is as lightweight as you can get.

more

[Anonymous Coward]

The agenda with some presentations is available http://ll1.mit.edu/agenda.html

The Arc presentation (an unfinished dialect of lisp) seemed especially intresting.

How about this?

[Nindalf]

Sounded like fun, so here's a reverse-polish interpreter with a whopping 10 instructions (counting subroutine definition). It's not totally minimal, but it is useable, and Turing-Complete.

Odd numbers are true, evens are false, and control flow is through conditional return and conditional tail recursion. Comparisons and other arithmetic operations can easily be built up from addition and negation. Named variables can be created by making subroutines that return an address.

I call it, simply, rpol.

RPOL
#!/usr/bin/perl
%commands=();
%data=();
@mainstack=();
%builtins=(
'+'=>sub{push @mainstack, (pop(@mainstack)+pop(@mainstack))},
'neg'=>sub{$mainstack[-1]=-$mainstack[-1]},
'set'=>sub{$temp=pop @mainstack; $data{$temp}=pop @mainstack},
'get'=>sub{push @mainstack, $data{pop @mainstack}},
'in'=>sub{read STDIN,$temp,1; push @mainstack, unpack('c',$temp)},
'out'=>sub{print STDOUT (pack 'c',(pop @mainstack))},
'eof'=>sub{push(@mainstack, (eof STDIN)?1:0)},
'<?'=>sub{(pop(@mainstack)&1)?'repeat':0},
'ret?'=>sub{(pop(@mainstack)&1)?'return':0},
);

open(PROGFILE, "<$ARGV[0]") or die "Couldn't open program file.";
while(<PROGFILE>){
chomp;
if(/^#/){
#ignore comment
}elsif(/^:\s*(\S+)\s+(.+?)\s*$/){
$command=$1;
$commands{$command}=[split /\s+/,$2];
}elsif(/^\s*(\S.*?)\s*$/){
rpol_exec(split(/\s+/, $1));
}
}

sub rpol_exec{
REPEAT: ;
for(@_){
if(exists $commands{$_}){
rpol_exec(@{$commands{$_}});
}elsif(exists $builtins{$_}){
$temp=$builtins{$_}->();
if($temp eq 'repeat'){ goto REPEAT }
if($temp eq 'return'){ return }
}elsif(/^(\d+)$/){
push @mainstack, $1;
}else{
print STDERR "Unknown token: '$_'\n";
exit(1);
}
}
}
#END FILE

For a sample, I wrote a program that swaps every two bytes of input, then writes them to output.

Sample Code (test.rpol):
#unused cat utility
:cat in out eof not <?
#unused newline function
:nl 10 out
#main program
:not 1 +
:swap 1 set 2 set 2 get 1 get
:cleanup eof not ret? out
:swapcat in cleanup eof ret? in swap out out eof not <?
swapcat
#END FILE

How the hell is this "flamebait"?

[Anonymous Coward]

Do moderators actually read the post before modding it??

Reinventing the wheel and money

[Anonymous Coward]

The article touches on the idea of academics looking down upon programming languages that badly solve again and again problems that have already been satisfied in the academic literature.

Is this literature free? Can I find it on the internet somewhere? Is someone maintaining a repository of best practices? Better yet, is there someone who sees mistakes being made and points the team to this freely available information?

I am asking because I don't know. My suspicion, however, is that most of this knowledge is locked in high-priced peer-reviewed journals, overpriced textbooks, and papers distributed among an elite group, rather than being released freely to the community of developers who work on free software.

Re:Reinventing the wheel and money

[StormyMonday]

Bingo!! Give the man a C-gar!

The academic stuff that I've seen, in addition to what AC says above:

• Has "intellectual property" booby traps up the wazoo (A requires B which requires C which requires D which has a nasty restrictive patent).
• Comes with utterly crappy "demonstration programs", if any at all.
• Zillions of references that you need to track down to have any hope of understanding anything at all.
• Tend to wander off into abstract mathematics ("proof of correctness" gibberish, for example.)

Note to academics:

• Put your stuff on the Web if you want anybody to read it. Make sure your vital references are also on the Web. Make sure your URLs are stable.
• Come up with a usable index. I know that the most important thing, to you, is your name on the paper. Nobody outside academia cares.
• Learn how to write usable demos. Do so. Put the code on servers accessible from the Internet.
• Release your software under the GPL or Berkeley licenses. Remember, we've already paid for this stuff through your grants.

that's why the event didn't take place on slashdot

[brlewis]

[see subject]

BF's second advantage.

[MarkusQ]

Bf is a lot of fun, but not light in the sense of perl or scheme. Since the article didn't define light language, I'll give it a shot. Looking at their choice of languages, light appears to mean: easy to program, easy to understand, but powerful, interpreted languages. Bf is none of the above. About all you can say for it is Turing-complete!

No, it also has the advantage that, if some poor sap goes to all the trouble to write a deamon in it, you get to smile and say "bfd!"

-- MarkusQ

P.S. It's also occasionally useful to drive a spike in "you can't do Y in language X" debates that have gotten out of hand.

That complicates things immensely.

[Nindalf]

If you want to be able to use it directly for real general-purpose programming, in the existing environment, it has to interface to any C library. That's a long way above and beyond Turing completeness.

This changes it from a "closed" language, with fully-specified behavior, complete within itself, to an open language which may be extended to arbitrary behavior with external modules, so it's not really a small language at all, just a small interface to a huge language. It either needs to be a compiled language, or to have compiled modules.

On the other hand, if you are willing to allow an environment designed as needed, to access all needed functionality in the form of one input and one output line, it returns to the sort of task a Turing machine can do.

I make a prediction...

[Snard]

From the review:

Paul Graham rounded off the talks by talking about his new dialect of Lisp, which he called Arc. Arc is designed to be a language for "good programmers" only, and gets away without taking the shortcuts and safeguards that you need if you're trying to be accessible.

I predict that someone will later come out with a new and improved version of this language which is backward compatible, and runs 10 times faster. That language will, of course, be called Zip.

Re:I make a prediction...

[Anonymous Coward]

And 10 years later we will finally have gzip.

Re:I make a prediction...

[Furry Ice]

Anyone who's a lisp fan (and those who'd like to be converted) should really read Graham's writeup of his LL1 presentation at http://www.paulgraham.com/arc.html

I'm really excited about this language. They're going to give an honest shot at making a lisp that will have more general appeal (read the part about onions: they're taking the "onions" out of common lisp), yet still maintain the raw power of macros. It should be very exciting.

Re:I make a prediction...

[Anonymous Coward]

and bzip2, a much better alternative that is mostly overlooked ;-)

Useability testing

[Anonymous Coward]

Do any language designers do any useability testing on what they implement?

I always get the impression that they just run a few ideas past the bloke in the next office.

BTW, They talked to industry, but no-one mentioned COBOL, Fortran, PL/I or Rexx? Maybe they need to invite players from large systems (Banks, airlines, etc) too.

...and the light language winner was

[Anonymous Coward]

Forth

we need

[Anonymous Coward]

The Ease of Use and Readbility of PHP
The Power and Speed Of Perl

And then, a way to generate executable programs with that language, without the need of a parser, that is, not a scripting language, but a compiled one.
Need GUI? There's PHP GTK.

Then again, there's also Delphi/Visual Basic.

Bottom line, can you, PHP guys, just make the language faster? It doens' really need to get compiled. Just freaking faster.
Bye, \n\n\r or just <br><br><p>

Re:we need

[Anonymous Coward]

• btw

ai ave nou aidia uote aime tolquingue aboute.

• translate please

I have no idea what I'm/I am talking about.
bye.

Re:we need

[Anonymous Coward]

The Ease of Use and Readbility of PHP

Please god no. Not that, anything but PHP.

Why the hell anybody thinks a crippled perl clone whose sole distinguishing point is that it is embedded in HTML (another evil practice BTW - all 'code embedded in webpages' systems should be stamped out), is good for anything is beyond me. And yes, I have used it, many times, and bear the scars.

Re:we need

[Anonymous Coward]

• • The Ease of Use and Readbility of PHP
  
  Please god no. Not that, anything but PHP.
  
  Why the hell anybody thinks a crippled perl clone whose sole distinguishing point is that it is embedded in HTML (another evil practice BTW - all 'code embedded in webpages' systems should be stamped out), is good for anything is beyond me. And yes, I have used it, many times, and bear the scars.

PHP is really more readable than Perl. It's sintax is more C like, wich I prefer.
One can write good systems with embedded code. The same way one can write bad systems with non-embedded code. I really don't like much having to

• print "<br><sometag>$somevar<sometag>" ;

if I can plain and simply do

• // php logic
  ?><br><sometag><?= $somevar ?><sometag>
  <?
  // more php & logic

and have the PHP code really nice and well separated from markup (html/etc).

PHP fails because it ain't as fast as Perl.
Fix that, and PHP gets really nicer.

Then again, you eat what you want, I eat what I want, and none of us get to be hungry.
snatch.Later

Re:we need

[Anonymous Coward]

While PHP can be embedded in HTML it's not true that it is embedded in HTML (it's executed when it fits the URL). PHP allows you to be messy and blend HTML and I appreciate this for a quick hack.

One thing that I have learnt is that you can't restrict bad programming through syntax or features. People who don't understand the nature of the task will always go astray - just probably a higher concept level that you can't control.

Embedded in HTML is a good thing mostly because it's an excellent learning curve. First you <? print "Hello world" ?> then you print a line and an if statement, then more and more and more.

Being Larry Wall

[MarkusQ]

To bring an academic success to commercial fruition requires one, as Olin Shivers puts it, "to become Larry Wall for a year" - to take care of all the gritty implementation details...

First John Malkovich, then Andrew Plotkin, now this. Aren't things getting a little out of hand?

-- MarkusQ

Definition

[srichman]

From the call for participation:

We use the term "lightweight languages" to describe some of the common features of these new languages. The term "lightweight" refers not to actual functionality, but to the idea that these languages are easy to acquire, learn, and use. Examples that would fall into this category include Perl, Python, Ruby, Scheme (and scsh), and Curl.

They are also often (but not necessarily) dynamic, interpreted, and/or loosely typed.

How about MSIL instead?

[Anonymous Coward]

MSIL exists and its performance on m$ platforms is unlikely to be beat, and its being ported.

Re:How about MSIL instead?

[Anonymous Coward]

MSIL is not particulary well suited for dynamic
OO languages like Ruby or Python. Though apparently there is a SmallTalk superset
(SmallScript) which supposedly has solved these
problems - but no details are yet available.

Definition time

[HiThere]

One of the big advantages of using objects with languages like Python, Ruby, Smalltalk, and sometimes Lisp is that one doesn't need to know the type of object that one is dealing with when one writes the code. One can ask it what it is, and proceed from there.

This is much more difficult with languages where the type of an object is expected to be know when you write the program. CaML seems to be of this latter class. (So are Java, Eiffel, Ada and C++.)

Notice that the second group of languages tends to be faster, but less flexible. This appears to be an inherent trade-off (though Java paid extra by having an interpreter for security and portability reasons).

Ruby in a Nutshell now available

[Anonymous Coward]

And now that the "Ruby in a Nutshell" book by Matz
(published by O'Reilly) is available that should
give Ruby a continued boost. In fact three other
Ruby titles are due out by year's end:
"The Ruby Way"
"The Ruby Developer's Guide"
"Learn Ruby in 21 days" - well, ya gotta have one
of those to make a language legit ;-)

Ruby Rocks!

Type inference to the rescue!

[Tom7]

Caml does full type inference for you, so that you have to write fewer types than you would in C or java.

In fact, in Caml you really only have to write types when you write down an interface to a module -- and this is exactly what languages without sophisticated type systems lack. It is very difficult to write precisely what your interface is without writing down types, and if the type language is poor (ie, Java, or worse: perl) then writing interfaces becomes more an exercise in documentation and finger-crossing.

(Personally, I also find that automatic type checking is very conducive to writing maintainable programs. It keeps me from making the gross hacks that are so tempting in perl. Typically it doesn't make my programs any longer or more difficult to write, since ML-family languages have lots of features to capture the common idioms that require this "flexibility" in perl et al.)

Careful not to make too many generalizations. I think Caml is much nicer than other typed languages you mention.

Re:Type inference to the rescue!

[HiThere]

It may be very nice in many ways. When I've looked at it I've been interested in reading in self-identifying objects from files. I'm not expert in CaML, by any means, so I may well have overlooked options, but it didn't look feasible to me. The only way that looked at all reasonable involved having a master type that could deduce which sub-type was appropriate by examining a string header. This is sort of the opposite of what an Object system should do, and felt rather like retreating to UCSD Pascal. (Mind you, I didn't study this issue closely, so I could easily be wrong about this. But even the bare references to random acces file IO was ... either I gave up, or I was so totally unimpressed that I didn't bother to remember it. [Well, I missed this in Common Lisp the first time I check the documentation too. For some reason this info seems to tend to be hidden.])

Re:Type inference to the rescue!

[Tom7]

> It may be very nice in many ways. When I've looked
> at it I've been interested in reading in
> self-identifying objects from files.

By objects, presumably you mean programming objects -- bits of code and data. I think this is kind of a weird thing to want to do (I can imagine some circumstances, but not many, where you wouldn't have your whole program written before running it), so I personally don't know how to do it, and it may be that highly compiled languages like caml are just in the wrong domain for this kind of dynamic behavior. However, I do know that caml lets you dynamically load and link bytecode-compiled modules, so it is possible that you could do it rather cleanly through that facility.

Re:Type inference to the rescue!

[gmarceau]

Serialization is called Marshalling in caml. Check it out.

What it buys you

[epepke]

The actual syntax is relatively unimportant.

Thinking about XML as equivalent to S-expressions buys you nothing, unless, of course, you count about three decades of extensive experience and solid, mathematically-proved algorithms that do way more than one could imagine, all of which exist.

If, of course, one is simply interested in declaring that XML is a Hot New Revolutionary Concept and things like LISP are Dead Languages, none of this is important.

4 different groups put together?

[anshil]

What do you get if you put ...
implementors of languages such as Perl, Python, Smalltalk and Curl, and lock them into a room for a day?

- 4 smashed-in heads.

Those who've watched the sometimes religious language discussions might get an idea.

Re:4 different groups put together?

[questionlp]

I thought it would be a Parrot that can do a lot of small talking with a curled feather on its head?

Inheritance and Namespaces

[vulg4r_m0nk]

. That's to say, if there's a Perl module Foo and you subclass it to Foo::Advanced by adding a frobnitz method, then what happens when the original author of Foo produces the next version of Foo that already has a frobnitz method?

What am I missing here? In the subclass frobnitz() would be overridden, and the superclass should not care about subclasses.

Relational Programming

[Baldrson]

Since functions are degenerate relations, and people need relations (remember the relational databases need stored procedures etc. guys) my favorite foundational prototype for "light-weight programming languages" is Libra -- a programming langauge based on binary relations. It's not what I would have done as a prototype, but hey, the guy DID IT and here I am talkin' about it! :-)

CiteSeer

[srichman]

Note to academics:

• Put your stuff on the Web if you want anybody to read it. Make sure your vital references are also on the Web. Make sure your URLs are stable.
• Come up with a usable index. I know that the most important thing, to you, is your name on the paper. Nobody outside academia cares.

Try NEC's CiteSeer.

Ruby rocks!

[hodeleri]

I wrote a web site in it (about 3500 lines of ruby, not entirely polished) and it was super quick to write, includes an output class for generating content in various formats (HTML, plain text, whatever else you want to implement), a system for processing form data (not great, but reusable), and a template-ish system (uses the decorator pattern) for attaching arbitrary content to a page. The only problem is that it is far too slow to put into production, I'm porting it to perl, but I really hope that the execution times of ruby programs will increase, ruby is pure joy to program in.

The lightest language of all

[marko123]

Brainfuck

Here is a program:

OK, but....

[Tom7]

I'm curious. What about perl is easy to understand?

I think I would agree that, say, the core of scheme is lightweight according to your

You didn't claim that perl is a lightweight language, but those at the conference seem to think it is. To me, perl is quite complicated, since there is so much implicit activity meant to make certain things briefer or automatic. I am thinking in particular of its rules about automatic conversion in various contexts. (I suppose it usually does the right thing, but the ease of understanding why something is wrong falls into the "easy to understand" category for me!)

Maybe, "languages for writing throwaway programs for small tasks?"

Next time include the requirements

[alext]

Yes, great idea, but one could argue that both academics and the worthy hackers are somewhat removed from typical user contexts. There are plenty of requirements in the 'enterprise applications' space (not to mention the scientific modelling space etc.) that are virtually never addressed in basic programming language, but only in endless 'frameworks', 'wizards' and other add-ons that are really band-aids for concepts not considered at language design-time. For example:

Commercial information tends to be persistent, not transitory. A good language should work directly with stored data.

Processes in organizations are long-lived and distributed, whereas typical programming languages just deal with transient threads etc. (outside workflow systems such as WebLogic Integration).

Programs represent rules, algorithms and other forms of knowledge that end-users will want to add to (e.g. a discount formula). Not only should the environment allow run-time modification and extension, it should also support representations and syntaxes accessible by non-programmers.

Every action has a principal actor associated with it, and typical commercial environments need to record who it was for auditing and access control purposes. If a programming language has no concept of Principal, one has to be stuck awkwardly on the side (e.g. Java EJB isCallerInRole).

Transactions are a very common programming model. At the very least, there should be support for creating and propagating transaction IDs, restarting procedures etc.

What else? Run-time metrics, versioning, SQL-style set predicates... well, you get the idea. People have to wake up to the fact that there is still a huge disconnect here.

(Amazing to think that Java gave Microsoft some ideas and a wide-open goal, and they came up with C#).

Re:Next time include the requirements

[gmarceau]

Very interesting comment indeed. If I claim to be a bridge accross the academia and real-life languages, I do not know of the enterprise reality you are talking about. However, the issues you gave as example seems to be library issue.

Commercial information tends to be persistent, not transitory. A good language should work directly with stored data.

Is that you wish your developers used more memory-mapped files rather than file streams?

Processes in organizations are long-lived and distributed, whereas typical programming languages just deal with transient threads etc. (outside workflow systems such as WebLogic Integration).

Check out channels threading primitive. Although I'm not sure what you mean by transient threads.

Programs represent rules, algorithms and other forms of knowledge that end-users will want to add to (e.g. a discount formula). Not only should the environment allow run-time modification and extension, it should also support representations and syntaxes accessible by non-programmers.

You would like languages that ship with an interpreter within the library, like lisp.

Although I clearly don't understand everything involved in the rest of the examples you give, it seems to me they can be solved with either lamba's ("SQL-style set predicates") or meta-language extension.

I would sugest you check out ocaml, which a natively-compiled, c++ fast, safe web enabled language with a browser applet plugins (if thus is your focus). Very buzzword compliant, very worthy.

Re:Next time include the requirements

[alext]

Merci pour le feedback (how's my French? I'm going to Calais tomorrow... think I might be struggling!)

Unfortunately, Slashdot had a spasm and I couldn't post my earlier response. Here's another attempt:

Persistence: Not sure about memory-mapped files - these lack transactions, queries and those other good 'enterprise' features. I think you're closer when you mention meta-programming further down.

Long-lived processes: I checked your link, but from what I could understand this seemed to be more about passing objects between threads. Anyway, the idea is that the process state is preserved without the kind of explicit programming involved in a workflow system - 'business process' and program process are congruent.

Dynamic / user programming: Yes, I agree LISP-like languages are attractive for this reason. Python and Java can do some dynamic and reflective stuff, but it's much more awkward than in some LISP-derived systems.

OCAML: I've heard really wonderful things about this, but people tend to emphasise the type-safety and functional programming aspects. I'd certainly like to check out the meta-programming-like features to see how far it could be turned into 'enterprise programming nirvana'!

cheers
alex

Re:Next time include the requirements

[gmarceau]

Merci pour le feedback (how's my French? I'm going to Calais
tomorrow... think I might be struggling!)

Short, obviously english inspired, but clearly understandable. I'm
sure your trip went well, hasn't it?

Persistence: Not sure about memory-mapped files - these lack
transactions, queries and those other good 'enterprise' features. I
think you're closer when you mention meta-programming further down.

Alot of the issues you are bringing seems to involve difficult
tradeoffs of memory usage, safety and performance. This would explain
why they are not making way into language support. This is were
metaprogramming comes in nicely : once you have picked a library which
implements the balance you are looking for, if its syntax is the
simplest and cleaness, can ensure a more regular usage across your
programming team.

Anyway, the idea is that the process state is preserved
without the kind of explicit programming involved in a workflow system
- 'business process' and program process are congruent.

Oh, I see now. You want programmable access to coredumps. mm, tricky.

OCAML: I've heard really wonderful things about this, but people tend
to emphasise the type-safety and functional programming aspects. I'd
certainly like to check out the meta-programming-like features to see
how far it could be turned into 'enterprise programming nirvana'!

The caml's meta-programming tools and called camlp4. I also got excited
about openc++
and its sister openjava.

Re: Programming in XML.

[Anonymous Coward]

Don't forget XSLT. It's already out there.

the language thing is a dead horse.

[aminorex]

The real action right now is in the VM architecture.
CLI has leapfrogged JVM. Will they respond with a
JVM that supports continuations and memory-mapped
registers? Or will the open-source world end-run
them all? Is Parrot even in the game? Will silicon
JVM cells ever reach a mass-market CPU?

Screw syntax.

Lambda Calculus beats Turing Machine

[alienmole]

The lightest computer mathematically proven to be equivalent to any other lanuage is the Turing machine,

This depends on how you define it. Lambda calculus is a contender for the same title, and in fact has largely superseded the Turing Machine as a model for computation.

If your metric is the size of the compiler, a Turing machine might win on current hardware - but that's at least in part because standard hardware has a similar architecture to a Turing machine. Someone should build a lambda calculus CPU... (No, Lisp chips don't qualify.)

Lambda calculus is certainly easier for humans to program in, and is more expressive in that it supports functions and named parameters. So I would say LC is the lightest, most powerful language that's easily usable by humans.

Re:Lambda Calculus beats Turing Machine

[Anonymous Coward]

Yes!!

I wish it was as easy as..

[Anonymous Coward]

make file menu
put in file menu
"new"
"open"
"close"
"exit"
import "quake3 engine"
make game fun
end game

The research is there for the taking!!

[alienmole]

I am asking because I don't know. My suspicion, however, is that most of this knowledge is locked in high-priced peer-reviewed journals, overpriced textbooks, and papers distributed among an elite group, rather than being released freely to the community of developers who work on free software.

You couldn't be further from the truth. Someone's already mentioned CiteSeer. I've read and downloaded hundreds of papers from there. Google is great for tracking down papers, too.

Another nice resource is library.readscheme.org. It's Scheme-specific, but Scheme is the root of much research about programming languages and the underlying concepts - it pretty much spawned the field of functional programming.

The biggest barrier to entry for this sort of stuff is your own existing knowledge. There's no pill you can take to pick it all up overnight. You have to work hard at it. This is the real reason to go to a real universities - not to learn how to program in the language du jour, but to learn about what some very smart people have already figured out over decades, centuries, millenia, and to learn how to think like those people.

There aren't many shortcuts here. It doesn't help to be told that there's a simple solution to the problem you're working on, if it involves a network of deep concepts you've never heard of and are totally unfamiliar with. To take some examples from functional programming: closures, continuations, continuation passing style, fold operators, polymorphic type inference... If you don't know what all those things mean, and can't use them in your code, you're unnecessarily limiting yourself and denying yourself leverage that can help get big, complicated things done more quickly, with less fuss.

One way to start out is to learn some advanced languages. Scheme is a good starting point because there's so much tutorial literature for it. You can pick up the computer science concepts as you go along. Read Structure and Interpretation of Computer Programs (SICP) and How to Design Programs (HTDP). Join the ACM. There's so much stuff out there, go look for it, and apply yourself!

rebol

[Graspee_Leemoor]

I am a bit of a language freak and have a long-time habit of hearing about a new language, reading a brief feature list, getting really excited, reading the language and library docs, discovering something I don't like, e.g. in C# the way methods aren't virtual by default, going off the language intensely then adding it to my cv anyway.

But when I checked out rebol that was mentioned in the article I found it was in fact as good as it first seemed, maybe better.

Within an hour of first hearing about rebol I had written a gui program that displayed the live picture of the Tokyo Tower on the net and updated it every 60s.

When I first wrote this program, it was as a learning experience for c#- and it took a hell of a lot longer to write and the code is much longer.

So maybe for me rebol is the ultimate lightweight language!

Re:rebol

[RockyJSquirel]

I just did a web search on Rebol and while I can find scripts in Rebol and lots and lots of hype, I can't find any meaningful description of what the language is. You know something useful to an actual programmer like "rebol is a tiny interpreted, untyped functional language with idl bindings and libraries for email and tpcip" or somesuch.

Rocky J. Squirrel

Re:rebol

[Graspee_Leemoor]

http://www.rebol.com/core-info.html

Re:rebol

[Anonymous Coward]

Yeah, I just checked this out and downloaded as a result of the article.
This is really a kickass little language.

I am totally uncertain about the "security"
however. And it is definitely a closed show.
I'll be watching my firewall logs alot until I know more about this beast.

Turing..

[Anonymous Coward]

Turing is so powerfull I once made a replica of Unreal Tournament but since it was made in turing it was so fast you could only see a few flashes and stars on the screen.. I mixed in some drawmapleleaf commands just so it feels like you are in canada.
I also made the BobOs. it kept crashing and telling me that there was a error in bobby's special area.. I dont know what was up with that!.

Hey mod that up

[RockyJSquirel]

Mod Re: what it buys you up.

felt like a big deal

[bugbear]

I was at this workshop and it it really felt like something unusual was happening. I think everyone who was there will remember it.

Most conferences are deadly boring, because people go to them to present things they've already thought of. At this one you had a feeling that people were having new ideas right there.

There was also a strong feeling that the topic was an important one, where new things are happening every day. That, I think, is because new programming languages matter now more than they used to. In the 1970s and 80s, there was a vogue for inventing new languages, usually to prove a point about types, and they all just disappeared into a black hole, because no one used them for anything.

If you make a new language now, people can actually use it. In 1980, if you wanted to use a new language, you had to convince your sysadmin to install it. Now everyone (at least everyone who reads slashdot) is sysadmin of their own server. That changes everything: if you build it, they will come. I think that will make the next few years a period of rapid innovation in programming languages.

(At the very least, we'll probably see more Lisp features in Perl and Python. ;-)

No, actually, it doesn't.

[alienmole]

With all this in mind, what are all these "Lightweight Languages", but examples of how many ways you can create a custom vocabulary, syntax and translator that outputs 0's and 1's not always in the optimum sequence?

You completely miss the point. If you want to address your so-called software crisis - which is only a crisis when you have unrealistic expectations, based on ignorance or denial of the issues being faced - then you need to provide humans with languages that allow them to express programs in powerful ways, that make programming easier and more reliable. Focusing on the 1's and 0's completely misses the fact that the challenges lie at the level at which the humans controlling the machines operate.

Academia has produced many innovations in these areas. All modern mainstream languages can benefit from these "new" language technologies (some of which are actually decades old). The LL1 workshop was about communicating between those who have developed sophisticated and powerful ways of dealing with language problems, and those who have a record of having implemented languages that are popular with humans - languages that are used not because of mandate from on high, but because they're perceived as easy to use and also powerful, and thus desirable to use.

An additional interesting element here is that the mainstream "Lightweight Lanugages", like Perl and Python, have a better track record than the big commercial languages of incorporating these ideas - witness the fact that Perl and Python support advanced capabilities such as closures and continuations, whereas other recent languages, like Java, have limited to nonexistent support for such things.

A collaboration between the authors of mainstream lightweight languages, and academic language researchers, opens the possibility to accelerate language development in a sorely needed way - instead of innovations taking literally decades to make their way from academia to the mainstream (e.g. the way object-orientation did), this lead time could be reduced to mere years.

In addition, via lightweight languages, these features would be delivered in a form more palatable to the audience consuming them. Lightweight languages tend to recognize the pragmatic needs of their users, as opposed to imposing restrictions based on aesthetic constraints such as "elegance".

In summary, the plethora of lightweight languages is a simple reflection of a dynamic and fast-evolving ecosystem, an absolute requirement for further progress in the extremely complex endeavour of humans programming machines.

Re:No, actually, it doesn't.

[3seas]

I didn't create or define the term "software crisis" The computer industry did in the mid 1960s. And the computer industry continues to use the term as an identification of a class, and sum total effect, of problems"

Your failure to know this seems to be consistant with failing to understand that it's not "language" and "syntax" that's the real issue, but rather getting the translation mechanics figured out.

This way it really won't matter what vocabulary (language) set and syntax you use. But rather opens the door up for combining languages as well as extending and creating them. Allowing you to use the better vocabulary and syntax for what you are expressing.

Translation simply takes whatever you have written and converts it into the optimum bit sequence for the machine to deal with.

Or for that matter, Translation from whatever form to whatever target form that is defined. Like Human to human Translations (i.e. English voice input to german audio/spoken output.)

The translation mechanics are going to be the same.

There is nothing wrong with defining new concepts, such as language does. But in having the science of translaion mechanics figured out, it will enable new concepts to applied alot sooner and probably alot easier too.

.

Re:No, actually, it doesn't.

[alienmole]

I didn't create or define the term "software crisis"

No, but you used it as though you believed it. In my experience, now that it's no longer the '60s or '70s, the phrase gets thrown around by people who know little about software development, usually to sell a product or idea.

Translation simply takes whatever you have written and converts it into the optimum bit sequence for the machine to deal with.

Or for that matter, Translation from whatever form to whatever target form that is defined. Like Human to human Translations (i.e. English voice input to german audio/spoken output.)

The translation mechanics are going to be the same.

You might want to read Joel Spolsky's piece on "Architecture Astronauts". Suggesting that all translation from any language to any other language involves the same translation mechanics, to me simply indicates that you've never actually done any work or studying in this field, and are indulging in armchair speculation. Any abstraction at that level will be essentially useless to the task of actually translating the material in question.

Take a look at what's involved in rewriting code in a functional language to a compiled form - an area that's enjoyed a lot of academic attention - and compare that to tools which translate human languages. The commonality there is minimal, at the level of stratospheric overviews like "get input; translate input; produce output". Architecture astronauting indeed! Dare I point out that all computation follows this pattern - "translating" a problem into a solution - so once your universal translation mechanics have been developed, we'll never have to write another line of code? "O great translation mechanics, what is the answer to the question of life, the universe, and everything?" Sounds good, let me know when you're done!

Re:No, actually, it doesn't.

[Anonymous Coward]

Perhaps you should explore my web pages. I'd posted the url before but have been working on a new homepage.
(warning - new home page does use a little java script - will be doing a decafe version in a day of two.)
me home page

BTW, there is a history of others making claims regarding me to only prove it of themselves in the same
communication. (shrug)
.

dot c

[Anonymous Coward]

just use PHP, based on THE language.c.

Little languages

[olin-shivers]

Some folks have asked me about the talk I gave at the workshop, that Simon described so kindly in his review on perl.com.

I wrote a paper about it. Although it's true I am a pointy-headed academic, I do occasionally hack a few lines of code, and I when I've solved a problem over in the research world whose solution would be useful to hackers, I try very hard to write papers that are readable by your generic hacker.

If you go here http://www.cc.gatech.edu/~shivers/citations.html you'll see a list of papers I've written. These are the ones that people in the perl/scripting/lightweight-languages community might find interesting:

1. A universal scripting framework
2. The SRE regular-expression notation
3. Atomic heap transactions and fine-grain interrupts
4. Automatic management of operating-system resources
5. Continuations and threads: Expressing machine concurrency directly in advanced languages
6. Supporting dynamic languages on the Java virtual machine
7. A Scheme shell
8. Scsh reference manual

#1 is the lightweight-languages paper on which my talk last week was based. By the way, the expect/chat & make replacements I mention in the future work section of that paper are basically done. I've three students at Georgia Tech who are wrapping up the implementation of a nice recompilation system called sake (pronounced "sah-kay," like the fish), which I like very much. A student who worked for me at MIT two years ago did an expect & chat replacement. (Lots of the scripts in my /etc directory are now written in scheme rather than sh, and I wanted something for my ppp subsystem.)

#2 has an opening flame about a problem in the open-source community I call "the 80% solution" problem. The regex notation it describes is now standard with scsh.

#4 & #6 will be of interest to VM designers.

#8 is, ahh, somewhat more well known for its non-technical content. But I'm on a new set of meds now, and doing a lot better, really.

-Olin

You have to be joking

[brentyoung]

"Christopher Barber gave a talk on Curl, a bizarre little language that fills the same sort of niche as Flash."

Come on now ... that's terribly myopic.

Your web pages

[alienmole]

In another message, you pointed me to your web page.

Actually, I had looked at your pages prior to writing the previous message, to make sure I wasn't missing something. I don't see anything to contradict what I was saying. In fact, there are some great examples of hand-waving on your pages: "doing stuff" qualifies as a perfect one.

All of the real problems that computer languages are designed to solve pretty much fall into the category of "doing stuff". Your nine steps don't seem to be much more than a shell architecture, or taken to their logical conclusion, a design for an operating system that has a more streamlined and integrated user interface model. Plan 9 comes to mind. Good for you.

However, this has nothing to do with solving the problems addressed by even the simplest computer language, except in exactly the sense I mentioned: every program consists of "input stuff", "do stuff", "process stuff". You've identified nine such steps - so what? Many more have been identified in work on these kinds of subjects, but it doesn't do anything to simplify real programs in any significant way, since the real work is what's done within the steps. This sort of analysis amounts to little more than an application framework, and in this case, not a particularly rich one.

I even went so far as to read some of your writings about patents. Grand visions are great and fun to play with, but it helps to have some understanding of the issues you're brainstorming about. I get the distinct impression that your formal background in these fields is limited. You might benefit from reading some of the material which I mention in this article. Some great research has been done on the sort of things you're talking about, and to ignore it would be foolish. You've written about the "failure of computer science", but you clearly don't know much computer science, so don't seem to be qualified to make such a claim.

Related to the material I mention in the above-linked message, you might find SCSH (Scheme shell) relevant to your work on VIC. Scheme's hygenic macro capability and support for developing higher-level languages within Scheme lends itself quite nicely to this sort of work - if you want to be able to create and manipulate abstractions, Scheme provides an excellent language to do that in. Learning Scheme is also a wonderful doorway to advanced directions in current language research.

You've made reference to computer science and related fields being elitist - but given the free availability of so much research and educational writing, the only qualification for entry is the ability to understand. If you don't have that, that doesn't make the field elitist, it just means that you need to seriously consider whether this sort of work is really what you're suited to. If I wanted to be a carpenter yet was incapable of visualizing or dealing with 3D forms, so that the items I built collapsed, what would your advice to me be? Would I be justified in suggesting that carpentry is elitist, that carpenters are imposing arbitrary requirements on the field, and that I ought to be able to build things without knowing any of the boring and petty details of carpentry?

---

"The mark of a truly intelligent person is the ability to introspect realistically."

Re:Your web pages

[3seas]

The fact is, is that you are going to hold to the position you have, no
matter what I say or write.

Also Slash dot is a limited message board, in that the board is not
designed to support ongoing threads but rather to obtain pretty much
initial feedback on articles posted.

I'm sure that if you seek you shall find any article you want, typically
what is supportive of your own perspective.

Your perspective is one that does not recognize the existance of the
"software crisis" and as such there certainly can't exist a solution for a
problem that doesn't exist. And to support your perspective you will of
course ignore anything suggesting otherwise. In this case it means that
you also have to ignore the fact the term "software crisis" came from the
industry and still being used today. In essence you are saying the
computer industry lies. Which then is a problem to solve. As a consumer
and potential producer, I'm tired of being lied to by the computer
industry, but I'm not going to ignore the potential of the computing tool
I call an Abstraction manipulation machine.

You can go from the extream of astro-architexture to the opposite of not
seeing the forest for the bark of the particular tree you are looking at,
but the only thing that proves is that any perspective can be presented
with bias of against or for, and even applied in ways proving either is
the fact. It's rather inherent in the ability of an abstraction machine to
be able do so, follow what a human directs it to do.

But in all of this, you cannot avoid using the nine action constants.
You can of course chose to not be aware of this. But so long as you are
doing this ignoring, you will not be able to progam complexity of the level
of what would be required of just the programming side of a High Quality
Virtual Reality holodeck, and certainly not at the direction of a small
child.

So as long as you are happy and can function productively within the
ceiling of constraints as is the current approach to programming, there is
no problem such as the software crisis. But for those, like myself, who
see how to go way beyond current ceilings of constraints, those who resist
and either prevent or suppress such advancements to only allow them to
happen under their control, there is in fact elitism. And as a result of
elitism there is inherently failure due to incomplete satification of
client and user, especially for those clients and users who want to do it
for themselves or add to what is or customise, but are not allowed to due
to lack of the availability of down to earth tools of abstraction
manipulation, automation mechaincs.

There is no majic algorythim, only the human programming of dynamic
automation, which includes automation of programming, of an endless amount
of things and actions upon those things in order to translate or convert
input to output. And as such is the endless amount, compatability and
integratability become issues to resolve.

The common conversion point is the carrier signal, the gears and bearing,
the action constants. What is abstraction manipulation, translations
mechanics. It's not a language, but an action set.

There is no rule of knowledge or of putting things together that says I
need to study all written works ever existing in order to be smart enough
to be able to put things together. But if it will make you happy, I'll use
the nine action constants to add your suggestions to what is becomming an
endless list of what others think I need to do before I'm somehow qualified
enough to become aware enough of what actions I use with consistancy, to do
anything I may chose to do.

However, Being that I do realize these actions, I can certainly see how
such awareness of these actions, and control of, can help me create "word
= definition" and that with enough words, I can create new words with new
meanings, etc.

Really, just because something has become second nature in ourselves
doesn't mean we are always aware of our use of such second nature things,
though when they are pointer out we may think nothing important of them.

But the thing is, computers don't know "second nature" but only what we
program them to do. And it seems that although the computer software
industry can automate anything no matter how complex it is, the one thing
they consistantly seem to fail at automating is the field of programming,
and to the extent of failing the ability of the typical user making use
of such automations.

Human language converted to the language a machine understands at the
physical hardware level is an act of transation that uses gears and
bearings of translations to do so. Which are the natural laws of the physical
phenomenon of abstraction creation and manipulation.

Why I have taken the time out to try and get you past all the things you
do not want to pass? Because someone else will see this here on an several
day old slash dot article reader response list?

There is a link near the bottom of my new home page regarding an arguement
for a python installed system.....
.

Re:Your web pages

[alienmole]

I appreciate your response. I'm not going argue with you point for point, but I will clarify a few things.

The reason I object to the term "software crisis" is because those who use it almost invariably go on to suggest "solutions" to this crisis which don't recognize basic realities of the underlying situation. You're doing exactly the same thing.

A paper was recently discussed here on Slashdot that gives an interesting take on the subject, and some excellent insights: Mathematical Limits to Software Estimation. One interesting observation quoted in the paper is "The creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line". Many people, apparently including yourself, would like to deny this; but until it is acknowledged, those who refuse to acknowledge it will continue to perceive a "software crisis", and continue to pursue solutions which don't ever achieve what they want, because, as has also been famously observed in the software industry, there is no silver bullet. That seminal paper says, "Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any--no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware."

Before I go any further, I should qualify what I'm talking about. There are many classes of applications that are pretty much solved problems, because they have been developed over and over, and software frameworks have been developed which make it much easier to churn out variations on that particular kind of application. No-one is suggesting that no improvements in software productivity can be made - over time, the range of problems which are well-solved will certainly increase. However, the issue is that of dealing with new problems. And new problems arise more frequently than you might imagine. When it comes to simple business form-based applications, for example, the basics of such applications were essentially solved by the 1980's. However, any application written in the 1980s would have been written for environments which are now obsolete. Greater abstraction was nearly impossible back then, because the hardware simply didn't have the necessary resources. So the evolution of computers and software as a field itself creates new problems, as just one example.

The fields is still incredibly young and immature, there's no question of that. In just the last five years, things have fallen into place that were never possible or practical before, and that trend will continue for the forseeable future.

On its commercial side, plenty of "lying" takes place - it's called marketing. But there are millions of honest people, myself amongst them, who are doing our best to implement best practices and further the state of the art.

You're trying to do that too, which I applaud, but I don't applaud your attitude. Since I don't know you, I don't know what background has led you to be so antagonistic to the computer "industry". The industry is really an incredibly large and diverse ecosystem, which only superficially moves with one mind. The many languages you were complaining about earlier are a reflection of all the people who are trying hard to improve levels of abstraction and make computing a better place.

All of this has very little to do with the specific project you're apparently working on.

There is no rule of knowledge or of putting things together that says I need to study all written works ever existing in order to be smart enough to be able to put things together.

There is, in fact, a common-sense rule that's so widespread that it has a name: "reinventing the wheel". Another common sense rule is that it's dangerous to ignore a large body of work in the field in which you're attempting to innovate: can you really afford to dismiss the work of the large number of smart people that have gone before you? Are you saying that you don't need to know about prior art in order to advance the state of the art? There's another "rule of knowledge" that boils down to a single word: hubris.

I'm going to leave it at that. I wish you luck in your endeavours. If you're actually developing code, you will eventually learn some truths about software development, even if it has to be the hard way. Some reading and research could save you from a lot of dead ends.

Re:Your web pages

[3seas]

(for the first link you mention here) Math is a subset from the spectrum of available abstractions. Would you like to deny this? In other words, and contrary to popular belief, to constrain computing to the abstraction subset of math is, in analogy and recursiveness, like constraining math to the abstraction subset of roman numerals. And then trying to explain algerbra.

The no silver bullet article is not currently available through my ISP but like most other links to articles you have posted, I'm aware of them and their content.

Did I not already say that there is no majic algorythim? but for what you quoted, there is no "invention" is true, what is the physical phenomenon of the natural laws of how we use abstractions is three for three not something you can claim is an invention.

You mentioned plan9 and I'm aware of the plumber but realize it's rather limited, but a concept in the right direction.

As far as solving problems goes, there is a genuine class of problems to resolves and that is a task for genuine software engineering, but it should also be a task that once solved then made available for everyone to use and make use of in an automated manner. Such an example might be the business-form based applicaion you mentioned. As it seems to be figured out well enough to be then automanted in such a manner that the user can design and creae their specific applications of these concepts.

I really don't need to spend my life inputing into my brain all the "stuff" the computer industry comes up with. Such expectations from the computer industry for anyone to do this in their creative and productive use of computers is absolutely foolish and arrogant, if not just plain immature and ignorant. For who in all these other industries and uses of computers has the time to do what even those in the computer industry have a hard time keeping up with?

I don't! But what I do have the time for is to make use of consisant physics and nature base (intuitive - as far as intuitive goes) translation tools that allow me to put things together in the 2 deminsional spaced of the abstraction world, where the details are accessible for the benefit of fixing and/or customizing but the use of which is automated so that those who don't have the time to create the details or even know what the details are, can still use them in their own creations via automated use, "auto-coding."

So while you are arguing that I need to know all about creating a car, from it's first invention to design and recent breakhroughs to manufacturing all the parts including the mining of metal and the development of rubber... all the way out to the junk yard.

The fact is, I don't need to know any of this in order to learn to drive the car and make creative producive use of it.

Granted a computer is a different vehicle, it's far more versatile and can be shaped/programmed in very specific ways. And just as cars and other road vehicles have an established way of using them, with some variation, the tool of abstracion manipulation mechanics needs one, and as it turns out it needs to be something that's natural logic of abstraction creation and use and as such inherently not patentable. And that is what the VIC is.

There are over 3000 programming languages that have been developed over the history of electronic computers. That's far more then the documented human languages in the recorded history of man. But in all of these programming lanuguages, the list of programming concepts is by far, a great deal smaller. So from the user making use of auto-coding to the binary based hardware, there is translation mechanics which are the same physical and natural laws of abstraction manipulation - of which the user is capable of making productive use of, in being creative with concepts others have developed.

Re:Your web pages

[alienmole]

Math is a subset from the spectrum of available abstractions. Would you like to deny this?

Not at all. However, the article in question is using established principles in logic and mathematics to assess the complexity of software development. It has nothing to do with constraining computers or the abstractions they use; it's more like using physics to describe phenomena we observe - it may be only one possible abstraction, but it's one we don't know how to violate. So the point is simply that there is solid evidence that developing software is a tough problem, and you won't solve the problem by railing against the computer industry and claiming that you alone have the solution.

I certainly don't think that users of computers should have to learn anything at all about computer science. However, you seem to be attempting to go beyond what users usually do, creating an apparently ambitious software framework. As such, you're no longer simply a user, whether you admit it or not; and as such, if you ignore other efforts in similar areas, you're simply making your own life more difficult and not doing anything to diminish your chances of failure.

Along those lines, you've repeatedly indicated that you consider your VIC to be some kind of absolute truth - "natural logic", "cannot avoid using", etc. Yet you seem to understand that no abstraction is all-encompassing - you alluded to that when you said "Math is a subset from the spectrum of available abstractions." Don't fall into the trap of thinking that VIC is the only way of looking at the problem you've chosen to explore. In fact, as a flexibility exercise, I'd suggest starting from scratch and coming up with a completely different way of looking at the problem. If you can't do it, it may mean that you're stuck in a rut. If you can do it, you're likely to find that your original model will be strengthened by the experience.

You've objected to the idea that you need to learn about computer science; how far do you extend that approach? For example, another field of study I can recommend, outside computer science but certainly relevant to it, is that of philosophy of science. It's worth learning and understanding how scientific theories are developed and how they evolve. Kuhn's "Structure of Scientific Revolutions" makes a good starting point. What applies to scientific theories applies equally to almost any abstract model. Formal thinking about such things can help avoid unproductive blind alleys.

But in all of these programming lanuguages, the list of programming concepts is by far, a great deal smaller

Although probably not as small as you think, based on your limited experience of programming languages and computer science. In a sense, programming encompasses the whole of mathematics, and functional programming exploits this fact. In another sense, programming is mathematics - as demonstrated by the lambda calculus, and by the Church-Turing thesis - notably, a postulate of mathematical logic rather than computer science as such.

The article on /. today about evolution and the Linux kernel (quite relevant to the discussion we've been having) included an interesting quote by Alan Cox on the linux-kernel mailing list, to the effect that engineering doesn't need science, that brick walls were being built before we understood how concrete worked. But as one of the /. postings pointed out, that led to problems, a famous example being that of the perceived need at one time for enormous "flying buttresses" to stop large cathedrals from falling apart.

There are plenty of equivalents to flying buttresses in existing computer systems; but to avoid them, and learn how to do things that don't need them, things that allow you to scale to higher levels of abstraction, you really need to learn about the fundamentals of the field. If you don't, well, again, I can only wish you the best of luck...

Re:Your web pages

[3seas]

you've repeatedly indicated that you consider your VIC to be some kind of absolute truth - "natural logic", "cannot avoid using", etc

It is. Maybe having the objective of first identifying the action constants had something to do with this outcome?

I think you'd have better luck starting from scratch and comming up with a different way to preceive gravity in order to solve problems with the theory.

There is just something about me changing what it is I'm interfacing with (AI) to get to your last post (ID) in the thread (PK) and read it (OI) on my monitor (IP) and access the links you gave (IQ) before I can respond thru the web editor (OP) within the limit (KE) of space to write and time I have to spend on a response. All of which I do in a sequencial (SF) manner.

Although the human application of these nine action constants goes much further in the example than given, the point is, selection of where they are identified for control is the key. Computer are less complex than we are and as such we do have choice as to where to identify the action constants in using them thru computer to automate.

In any event, they are action constants, not abstractions. They are what you use to process abstractions. And although I have assigned to each of them a two letter absraction symbol, this symbol is itself redefinable so that there is not conflict within the scope of a given use. And they are redifinable on the fly.

You cannot solve a general langage problem by inventing another language. You can however understand the underlying action constant that is used in all languages and as such be able to change which language you are using in order to avoid the limitations of given language. By going to a language that has not the same limitations.

Sorta like using a saw to cut the wood but then a hammer to nail it, changing the tool as needed. And language is a tool.

Re:Your web pages

[alienmole]

I think you'd have better luck starting from scratch and comming up with a different way to preceive gravity in order to solve problems with the theory.

That's kind of my point. There are multiple theories of gravity. That's why I suggested philosophy of science as a worthwhile field of study - it might give you some perspective.

Like physical theories, when it comes to software models, most models are essentially really "views" when you get down to it, i.e. they inherently embody a particular way of looking at the problem in question. A comprehensive model can certainly be widely applied, and that's what you're claiming for your model. But if you think that's the only way of looking at it, I can safely say that you're wrong.

Re:Your web pages

[3seas]

On the other hand, a field like chemistry today is such an established science that we have chemical mega plants and it no longer is a matter of how to do something, make a new compound, but what compounds to make. This is a field that began where? Alchemy, majic potents. Trial and error?

Sure you can view chemicals as majic dust but how far is that really gone to get someone?

With software, and no matter how you "view it", it's still going to be a matter of manipulating abstractions in order to control the physical state of the machine, be the machine binary, trinary or whatever. In doing this, there is an identifiable physical set of actions that is used regardless of how you view and define the tools of "computer languages".

The whole point of creating computer languages was not for the sake of creating computer languages but in order to control a massive count of switches that exist in reality. A count way beyond what any human can manually handle. The solution is in creating word=definitions to define a given state or change in state. Like the most simple act in math, addition. Only here the available set of usable abstractions is only limited by imagination and real hardware limitations (the potential on both sides of the equation). At the very core, it's bit flipping but on such a massive scale that the only way to do it is to define and used such abstractions.

word = definition -the most fundamental act of programming.

But the action set remains the same and regardless of what you call it, how you "view it" or how you use it.

The VIC is an identification of these, defined in terms of computer functionality (inherently limited to the scope of the physical hardware) and in a configuration that supports maximum possible versatility. Even the name "Virtual Interaction Configuration" was taken from the field of physics, not some invention of some computer industry marketing hot hype of abstract words. Look up "Virtual Interaction" in the book "Tao of Physics" (which you should be able to find in any decent book store - the original source is probably alot harder to find but mentioned in Tao of physics).

So we have a mass of physical switches to control and use the tool of "word=definition" in making it easier to do. And as the mass count of "word=definition" grows we then create languages and syntax to help us better deal with the count while adding versatility. But at this point it's not a matter of dealing with a mass problem of physical based switches but rather a mass problem of absractions.

And it is here where recursion should be identified. Recursion in using the same solution direction and physical action set to solve the "mass" problem.

You can go to higher and higher level abstractions, languages, but every time you run into a "mass" problem, the same action set will be used to solve it. And that proves the action set valid. And regardless of what level you use the action set on, be it in creating the hardware (i.e. transistor = layer configuration of chemicals at the atomic charge level, cd player = a hardware configuration, etc.), hardware to software, or abstraction level of software.

So after creating over 3000 programming languages, you'd think the science of software would have figured this out already.

Oh wait! There is no science of software yet. And that is because the dragon of money has blinded and made witches and warlocks to create majic potents. Potents that give them power over the ignorant. If you sail out there, you'll fall off the edge of the world if you make it past the sea dragons....

Isn't that what you keep trying to tell me?

You know, astro-architecture....etc..

.

Re:Your web pages

[alienmole]

Oh wait! There is no science of software yet. And that is because the dragon of money has blinded and made witches and warlocks to create majic potents. Potents that give them power over the ignorant. If you sail out there, you'll fall off the edge of the world if you make it past the sea dragons....

Isn't that what you keep trying to tell me?

No, what I'm trying to tell you is that there is a science of software, which apparently you haven't investigated at all. You're focusing on the shortcomings of a relatively immature "industry" without looking at what the scientists are doing, much of which will drive what happens over the next 5, 10, and 50 years, as it has done to date.

Industry often tries to ignore the science, for reasons of its own; science usually wins in the end, because it's hard to ignore reality for long periods of time. What I'm trying to tell you, is that you shouldn't ignore the science.

Re:Your web pages

[3seas]

another slashdot thread that only goes into the forest from one direction.

Perhaps you can give me a link to those scientist you are refering to?

But how does Arc get implemented?

[Christopher B. Brown]

The not-braindead way to implement Arc would be by defining a readtable and some macros, all bundled into a package probably invoked by (require 'arc)

That way the sets of "library stuff" already existant could be used, and they're not left re-implementing everything from the compiler on down...