Slashdot Mirror
Sixteen Years Later: GNU Still Needs An Extension Language
Fresh from the 2011 GNU Hackers Meeting, Andy Wingo has written a long piece on the status of Guile Scheme, the woefully underutilized official user extension language of GNU. Wingo argues that Guile is the best choice for extension in GNU given the ability of Scheme to adapt to change over time. Presented with using e.g. Javascript instead of Scheme for its popularity: 'We should also consider the costs of using hastily designed languages. JavaScript has some crazy bad stuff, like with, var hoisting, a poor numeric model, dynamic this scoping, lack of modularity regarding binding lookup ... Finally, we have the lifespan issue. If GNU had chosen Tcl because it was popular, we would have a mass of dead code' (it should be noted that Guile does partially support Javascript syntax). With the proliferation of Firefox extensions, Greasemonkey, etc. it is clear there is a large set of power users who want to modify the programs they use without spending years becoming skilled programmers. Perhaps after Emacs has been ported to Guile the philosophy of user extensibility will spread to other parts of the GNU system.
from the article:
"Guile supports POSIX threads, with no global interpreter lock. "
Ouch...
(Besides a few hardcore geeks, (people (hate (shit that (looks) like ((this))))))
Why isn't Lua considered? Everytime I see Guile brought up as a possible extension language, the project in question always settles on Lua or Python. (Python being the poorer choice because it is not designed to be an extension (scripting) language.)
Why not?
Give me Classic Slashdot or give me death!
they still need a kernel.
"Finally, we have the lifespan issue. If GNU had chosen Tcl because it was popular, we would have a mass of dead code"
If Tcl had been used it may well have been alive I guess. I suppose it is Turing complete.
...Guile goes with everything!
Guile is LGPL. It's no more "locked down" than any of the other LGPL libraries that proprietary software uses, such as glibc or Gtk+ or SDL.
The port of emacs to guile is a breakthrough.
Perhaps if GNU had adopted TCL, then it would have stayed popular. Or what if GNU had provided a common backbone for extension so then it would be easy to plug in scripting languages (perhaps at run time)?
The simple fact is that paren languages are a really had sell outside of their niche. There is a hardcore who loves them, but the majority do not. Scheme is like the cilantro of languages -- you love it, or you hate it, but there isn't much of a middle ground. The Guile folk made all kinds of promises back in the day of supporting lots of syntaxes, but like Hurd what has come out has been very late, or comes no where near expectations.
And of course the fact that Emacs still hasn't adopted it, isn't a ringing endorsement either.
So give up on a single fixed scripting language, and provide an extension architecture so lots of options can be used... including Guile
What do you know I wrote a novel
It is, "Just another paradigm changer" (JAPC). These sorts of articles come out all the time (see the recent OPA article). Basically, this term is to be used when another invested developer harks a new or underused language that will change the way most developers code. The problem is, most ignore some big hurdles in adoption:
1. Saturation. If there are already established tools that do more-or-less the same thing, then there is little incentive for developers to learn something different (often radically) for no tangible gains.
2. Non-problems: Developers often get excited by "problems" that don't exist outside of their niche or mind, and then develope something to solve it. While this might work in the niche, it rarely works in the general case (thoguh there are a few notable exceptions).
while(1) attack(People.Sandy);
I'm not a fan of the GPL either, but I think licensing has little to do with it.
Extension languages fill a small void. People who are tech savy enough to want to make changes to the way their programs work and have basic programming ability, but arn't skilled enough or don't have the time/interest to make a full blown patch.
I think they've got it all backwards here. You don't ignore popularity and pick an extension language based on it's language features .. you pick a language based purely on it's popularity and ignore language features. Using some obscure (even if well suited) language just narrows that void even more to people who can't be bothered to write a patch, but can be bothered to learn a whole new language.
They have a kernel. If you're referring to GNU HURD, that's been deprioritized because as Mr. Stallman wrote in a Reddit interview, "Linux works ok as a kernel." Linux is one of many third-party components of a GNU system.
16 years? And people bitch about Parrot and Perl 6....
Having never heard of Guile, I think I can take a good guess as to why it has not been adopted:
Guile is an implementation and dialect of the Scheme programming language (Scheme is a dialect of LISP itself)
Oh my.
LISP found a niche as an AI research/programming language, and sometimes for symbolic math manipulation, but has never been used in the mainstream. Most programmers have never heard of it. Universities teach it in whatever token course covers 10 languages in one semester with no depth at all. Hardly anyone writes everyday software in LISP. It is not appropriate for general-purpose scripting.
I am prepared to be flamed...
No sarcasm meant, does this issue matter to more than a handful of people?
Will it matter once all of the "once ___ are done"s or will the tech world have moved onto other things?
I read into these comments just to see if anybody cares.
It seems not.
If the Slashdot crowd doesn't, then why would the wider world?
Go home and be a family language!
Using some obscure (even if well suited) language just narrows that void even more
If you don't like the parenthesized S-expression syntax commonly associated with Guile, use M-expressions. Guile supports a curly-bracket syntax called ECMAScript, as the summary points out. You already have thousands of web developers using JavaScript and ActionScript, both of which are based on ECMAScript.
Proposing a Lisp dialect as the "official" extension language of GNU is a stillborn idea. It might find favour with the small fanbase of Lisp hackers but nobody else. It would make more sense to define a language neutral automation interface that any process can implement. Scripting languages would soon acquire the bindings to use it.
Guile does partially support Javascript syntax
Anonymous Coward wrote:
Meanwhile, they have Guile which is both dead & unpopular.
GNU, swallow your pride and use Javascript. It may not be beautiful, but it works.
If Guile supports JavaScript, why is it dead and unpopular, as you claim?
Also, religions are tools and not languages.
Alternatively you can make the language popular. Get GUILE into HTML5, and its popularity will rise. :-) ;-))
(Or maybe the popularity of HTML5 will go down instead
The Tao of math: The numbers you can count are not the real numbers.
...and Lisp is weird.
Yes, Lisp's awesome, and has got all sorts of fascinating and powerful features such as continuations and hygienic macros, but the sad fact is that it's just not accessible. Any programmer with modern training is going to be familiar with Algol languages, specifically C family languages, and is going to take one look at the incomprehensible mass of free-form parentheses that's a Lisp program and simply won't be interested.
This is one of the reasons Javascript's so successful --- although I agree with the author that it's a terrible language. Someone with C or Java training can look at Javascript and read the structure; the learning curve is shallow enough to get people hooked. Guile's learning curve starts with a cliff. Why should someone looking for an extension language pick Guile when languages like Python or Lua are available that people already know?
(As a secondary note, the LGPL's not really a very friendly license for an extension language, as it makes it hard to embed in anything that's not GPLd. I realise that the FSF is doing this deliberately to try and encourage people to write GPL software, but it is a factor affecting Guile's popularity.)
In their defense (and I am no fan of LISP like languages or of Guile) is that you could use Guile as a kind of common VM, with transcompilers to transform the syntax of Lua, JavaScript, Python, or whatever into Guile and be executed at runtime.
The problem is that never really happened in any kind of satisfactory way. There is a partial implementation of JavaScript, they are "working on" Lua; etc. None of the efforts have felt very satisfactory to date. And part of the reason is that a language is a lot more than syntax. Unless people are willing to port the core libraries and make sure they run well, then Python (or whatever) with a different runtime and libraries isn't going to feel right.
A far better solution (IMHO) is to do what Java and .NET do and have a common infrastructure for scripting language and then let anything that conforms to it play. So your app has a common API for exposing its internals and entry points, and then scripting can be done in any supported language. It is easier because these are VM languages, but it wouldn't be hard to do for compile languages either. Then we could use the real languages, and not some kind of simulacra...
What do you know I wrote a novel
If you think Emacs lacks a good text editor, install viper-mode.
In the rather unixy context in which GNU software tends to operate(historically, yes, there is the strong lisp-derived strain; most prominently holding out in Emacs; but today's incarnations generally show up as the userland tools of a unix or unixlike system) the niche for extension languages is arguably even a bit narrower:
They have to address problems of interest to people technical enough to write them; but not technical or interested enough to modify the program(as you note); but they also have to address problems in programs that are sufficiently monolithic that you would use the program's internal extension language, rather than hacking together a bash script that stitches together a bunch of common utility programs. In a context where command line users are largely an afterthought, or a workflow situation that makes heavy use of big, monolithic, programs with minimally useful command line invocations, extension languages are the 'glue logic' you get(observe your local Office guru's bludgeoning about of VBscript, or some photo-pro's slightly alarming Photoshop batch processing abilities); but the unix 'flavor' has historically been that the shell, rather than the program extension language, has been the tool of choice for bodging jobs too big to tackle manually but to small to be worth delving into the guts of the programs themselves.
Because it partially supports JavaScript. not supports it. And it doesn't (the last time I looked) provide much of the common JavaScript libraries. Making it a PITA and minefield to use
What do you know I wrote a novel
The backend of http://biocyc.org/ is written in lisp AFAIK, and it's an impressive beast, connecting to and managing databases, generating graph images on the fly on the basis of query results and embedding them in lisp-driven web pages and so on, but it's the only lisp-driven heavy duty system I've ever come across.
Korma: Good
Out of concern that they might choose a language that would eventually die, they chose one that was already dead.
Scheme is taught in universities, for programming language design, and is used to prototype new languages amongst many other things ...
Loads of people write in Scheme/Lisp - It's just that they have been taught properly and so do not shout for help every 5 minutes on general forums ...
It makes a very good scripting language, and data language, and general purpose language, etc ... unlike most of the alternatives this is why it was picked as the GNU extension language (note not just scripting, a fully fledged extension language)
JavaScript is a mediocre scripting language and a bad extension language ...
TCL is similar
If you want a scripting environment (like .NET) where you can use any language, then why not get someone to write an extension (in Guile) that does this, it is more than capable ...
Puteulanus fenestra mortis
Actually, there are huge commercial uses of LISP. It is used for scheduling, modeling and rendering, CADD, and business analysis.
Examples include American Express' Authorization Assistant, Autodesk's AutoLISP for programming AutoCAD (my nemesis and love for many years), Gensym's G2 business rules engine, Marai (one of the rendering applications used for effects for Lord of the Rings), and the SPIKE scheduling system for satellites and telescopes.
Comment removed based on user account deletion
Quoting from the Guile Manual
That is hardly a ringing endorsement...
What do you know I wrote a novel
It's not just the parens, it's the order. Prefix order is only natural sometimes. Take (loop (print (eval (read)))) for example.
This is just a small example so the parens aren't a bother. What does bother you is that when you think, "how do I implement a REPL?" you don't think of the print before the read or eval. You think of the reading first. In a small example like this it isn't too hard to slow down and see what's happening.
In larger functions, it's a problem. Finding the "starting point in the maze" becomes a gruesome chore of navigating down a parse tree of parens. It isn't the parens causing the problem though. You'd have the same problem if this were done using some other syntax for a parse tree.
There are two big patterns in programming: hierarchy and sequence. IMHO, Lisp does a fantastic job representing hierarchy, but a lousy job with sequence.
There probably are more than a thousand developers who would like a better extension language, though a LISPy one certainly would not be it
Hey, Street Fighter matters! It just does. Now I wouldn't go with Guile necessarily, but he's good. Blanka was my preferred fighter.
The world is made by those who show up for the job.
From the Guile webpage:
Guile is an interpreter and compiler for the Scheme programming language, a clean and elegant dialect of Lisp.
OK, if I see a bunch of Lisps walking down the street, I'll be able the recognize Guile as the one wearing spats and carrying a walking stick.
Would somebody please tell me why we keep resorting to these ridiculously nondescript descriptions.
I generally subscribe to the idea that if something is good, it will become popular all on it's own.
16 years later and no one has heard of it.. not good.
There are of of course exceptions, where something is so far ahead of its time that no one appreciates it, or where something is never given a fair shake ... but I think guile falls under neither group. It was a nice idea, but let it die and use javascript/lua/python/whatever ..
I like scheme, I really do. But to point to javascript's dynamic scoping as an issue is bizarre. There are advantages to the lexical scoping that scheme uses, but there are drawbacks too. Scoping models seem to be ultimately a matter of taste, not a criteria for what makes a language good.
Great job! You found *an* example of lisp in real-world use. Tens of thousands of applications in the world (probably more), and you managed to indeed find a real-world application that uses lisp.
Back in 1994/1995, I spent some time working at Swiss Bank Corp. in Chicago. They had some older trading-related systems running on Symbolics machines.
September 2011: Looking for Cocoa/iOS work in Boston area Cocoa Programmer Quincy, MA
Guile is not Javascript, and Guile does not fully support Javascript.
Are you saying Guile is alive, prosperous, and popular? I'll agree it's alive, but only barely.
Sun's eGate Integrator platform (a predecessor to JCAPS) used a LISP derived language called Monk as a scripting language. Of course, it's been phased out in recent versions :P
Somebody should let these guys know so they can stop wasting their time:
http://www.tcl.tk/
You're missing one: clear communication of the purpose. I read the summary and couldn't work out what Guile was supposed to extend. Is it supposed to let me add non-POSIX extensions to the GNU POSIX tools? Add non-standard features to GCC? The blog post doesn't talk about any of that either.
When I really think about it I remember that GIMP supports scripting with Scheme, and GIMP plugins is an area which does have potential (albeit saturation is an issue - it's easy to write filters in other languages and chain them into a workflow). But if the people discussing this aren't clearly communicating the use cases no-one's going to care which language they choose.
Language designers love to argue about why this language or that language
*must* be better or worse a priori, but none of these arguments really
matter a lot. Ultimately all language issues get settled when users vote
with their feet. If Tcl makes people more productive then they will use
it; when some other language comes along that is better (or if it is
here already), then people will switch to that language. This is The
Law, and it is good. The Law says to me that Scheme (or any other Lisp
dialect) is probably not the "right" language: too many people have
voted with their feet over the last 30 years. I encourage all Tcl
dis-believers to produce the "right" language(s), make them publically
available, and let them be judged according to The Law.
Why else do we have BODMAS in our maths class?
Compared to the mainstream of Java/C++, JavaScript's prototype-based OO is pretty strange.
People put up with language weirdness for two reasons:
* It's the only game in town (JavaScript and browser extension, Emacs Lisp, tcl/tk and X GUIs)
* It has something you really need/want (Lisp macros, Java JVM, C++ low-level access)
Neither of those can really be used to drive a universal GNU extension language. Wishing for it is like wishing for something to displace the x86 architecture.
To a Lisp hacker, XML is S-expressions in drag.
I think we should just ask Larry for an embeddable perl script library. I mean if it's not Perl Its Just not Perl.
PS. I started writing an extension script language as a Lisp library 28 years ago. But My boss told me that Fortran programmers would not write in Lisp. We where using 'C' on a VAX at the time. So I fired my Boss. (Ya, I got a new job) In the next year or so I saw Tcl at a UseNix convention, and that would have been better for the Fortran programmers. So I would pick Tcl over lisp at this point. But Perl script over Tcl, if there was such a thing.
It just made its way into NaCL.
Expect to see more of it.
Comment removed based on user account deletion
They didn't choose Tcl because that would have required making a decision. The whole GNU community is plagued by indecision or "we can't do it this way because it's not perfect". So after 30 years, no kernel. Hell RMS will be dead before they release hurd one dot zero. Even a herd needs a leader.
We show geeks how to get their dream girl at EyesOfOdessa.com
I thought this was the whole point of Lua.
I'm god, but it's a bit of a drag really...
Also, tools are lang-- err, relig--, err... I got nuthin'.
Lisp is used for a whole bunch of things in highly complicated current fields. Like aircraft ticket booking, stock trading, and missile defence:
http://www.franz.com/success/
http://www.lispworks.com/success-stories/
Modern web-based applications use AJAX and therefore JavaScript in combination with DOM models of HTML and SVG to model user interfaces. This could be a nice design concept as the UI runs on another machine than the core of the application. However, it would be best when the DOM manipulation language would be designed with more safety in mind. I visited a week ago a symposium where someone was explaining all the goodies of JavaScript. And honestly they are cool as in you can do a lot of stuff and need not to write a lot of code. However, each construct leads to unsafe code when you are not constraining yourself with coding conventions. In combination they result in pure horror as you cannot see what really happens, you need to execute it.
A functional language like scheme or lisp can be much safer as they do not have state. Even though they might be more difficult to master. For UI concerns the language should be split in three.
a) Field evaluation
b) Triggers/actions meaning: sending requests and getting answers. You could even restrict reactions by specifying protocols. e.g.:
send getCityList(searchTerm) {
on ListOfCityNames do some-dom-modification
default do some-other-dom-modification
}
c) DOM modifications triggered by answers or other incoming messages
The same applies to GNU applications. A specialized language for these applications or at least a functional language using an application as a framework and source for an internal DSL is a good thing. And therefore Guile is a good thing. However, many people do their stuff in other languages which are unsafe and danger and which have a fucked up grammar, but it is what they can. So they won't switch to a ((())) language, which produces a lot of headaches due to the ((())) stuff.
Then there's Gambit, a Scheme implementation that compiles Scheme to C. Instant C compatibility!
http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Main_Page
-- hendrik
Not Invented Here Syndrome is why they didn't use Tcl either (which is still being actively developed). Why would switching to Lua be politically any easier for GNU than Tcl?
“Common sense is not so common.” — Voltaire
If your CS program at a university didn't teach at least a full class using LISP, you should ask for a refund, because it was a terrible CS program.
Not having much experience in LISP or Scheme, can someone explain the effective difference between a macro in a parenthetical language(as the article describes) and a function in a structural language?
In other words, Mr. Wingo asserts that Scheme's macros allow it to implement 'match' functionality(as an example) - don't Javascript's functions allow it to do the same? And don't libraries like jQuery and ExtJS "extend" Javascript in the same way that Andy claims would only be [possible/easy/etc] in Scheme?
The key thing about an extension language is NOT it's adaptability over time. The key thing is that it works as a tool for the people who might want to write extensions to applications. As a general rule, the extension developers won't be the full-time developers of the applications. Instead, they're going to be the slightly-more-technically-adept users of the applications.
If you want extensions to be developed, then you need to remove barriers to entry for those people. And probably the most important barrier is time. And it takes time to learn a new language sufficiently well to do useful things with it. Therefore, the sensible choice is to pick a language that is broadly known by the sorts of people who would be likely to want to develop an extension. The next best thing is to pick a language that is really easy for those people to learn (by virtue of being similar to other languages that they probably already know).
Guile fails on both accounts. It may be a fantastically great language, but it lacks the widespread use necessary to be a successful application extension language.
A better choice would to pick JavaScript and just accept that the language has warts. The language also has users, and that is way more significant.
-- Beer. It's what's for breakfast.
You've got VMs for JS, Python, Java, and all of Mono. Why not just support a generic VM integration?. Python has a tool called sip (thanks to Riverbank) that allows Python to use C++ objects, creating wrappers. Why not take a similar approach for other languages? Even if you do something horribly abstracted as a native REST client server with language bindings, you'll completely work around any deprecation issues.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
as an extension language? Emacs uses Lisp, GIMP uses some dialect or Scheme, but AFAIK it is not Guile, I know that there is a window manager that uses Guile, but I am not sure if it is officially a GNU software. Is there anything else?
AccountKiller
Forget about "geeks," no programmer wants to use a language that messy. All of the popular programming languages read more or less like English, and that is because we have already learned to read English (or perhaps a similar Western language).
Why do you think that programming is a lot like writing, and that good code reads like a good novel? Good spellers tend to be good programmers. We're using the same part of the brain.
Even mathematical expressions read like English. Why? Because of our language bias.
Done right, an extension language that exposes the right interfaces in the right ways could be to GNU software what AppleScript is to Apple software. And that support is what makes Automator work.
To elaborate: the extension language for Macintosh GUI programs isn't built into those programs. They're built keeping it in mind, but it's not built into them. Instead, they essentially expose verbs and nouns (via a "dictionary") that a shared extension language framework then leverages. Some they define themselves (like the way iTunes defines what a "track" is), and some are defined according to standard conventions (like the definition of what a "window" or "menu" is). It's all typed and stuff too.
(In principle, more than one language could take advantage of that stuff, and the frameworks in fact lay the groundwork for that. In practice, nobody actually uses a language other than AppleScript with this stuff, which is kinda too bad. If you're on a mac and want to know what the hell kind of nonsense I'm raving about, read the man page for or output from the "osalang" command-line program.)
The result is incredibly Unix-y in fundamental philosophy, even if it doesn't seem so in detail: you can write scripts that string together small special-purpose programs to do large complex tasks -- and I'm talking about GUI programs, not just command-line utilities.
I make very powerful use of this myself sometimes, just as I've made very powerful use of shell scripting to bind small special-purpose command-line programs together since the 1980s. It's niiiice.
Question: People aren't using Guile, should we switch to something else people will actually use?
Answer: No, all those people are wrong.
#DeleteChrome
In the time it takes someone to interpret what that even means
If tl;dr, then let me say it shorter: Guile supports a syntax with which JavaScript programmers are already familiar.
the niche of people who would use an extension language is pretty small. The fact that they have to learn something new makes it even smaller. This is why using actual javascript vice something that is based off the same thing would make more sense.
JavaScript is ECMAScript plus the HTML DOM (document object model). ActionScript is ECMAScript plus static typing plus the Flash DOM. So by definition, people who know JavaScript or ActionScript are already familiar with ECMAScript. Guile lets an application developer expose a DOM to a Scheme or ECMAScript interpreter, which in turn lets anybody familiar with Scheme or ECMAScript script the application.
I've been a Vim user for 15 years but discovered orgmode (http://orgmode.org) a year ago and absolutely love it.
But I've hit the point now where configuring it to match my needs requires me to write some code.
Free Manning, jail Obama.
Comment removed based on user account deletion
Because it partially supports JavaScript. not supports it.
If you start adding Guile support to an application, there is likely to be an update to Guile that adds more complete support for ECMAScript.
And it doesn't (the last time I looked) provide much of the common JavaScript libraries. Making it a PITA and minefield to use
How many of "the common JavaScript libraries" depend on there being an HTML document object model in document? I'm under the impression that libraries for manipulating an HTML document wouldn't apply outside a web browser.
I've been trying to get the fascination with Lisp for twenty years, and consistently fail. APL was the first high level language I enjoyed using. It was beautiful and ugly at the same time and I found it instructive. As an array language R sucks in a way that APL never did. The beauty of APL lies in its regularity. The mathematical identities are wired so that you rarely code a special case in an elegant formula.
In either the APL or Lisp case you run into this little difficulty that the human brain has a parsing stack not much bigger than the 8087 coprocessor. Top level programmers are supposed to be different because we can store nine working objects in short term memory instead of five to seven. Maybe the reason only the four sigmas ever liked the Lisp language is that you need an eleven element parenthesis mental stack to get to the point where those damn parentheses aren't the only thing you think about.
The story I like about this was some HOF baseball player (whom I remember as Mays) tried to become a hitting coach, but had little success. When his charges asked for advice, he suggested "just watch the seams as the pitcher releases the ball; if the seam is here, it's a curveball, if it's there, it's a fastball". Some people have trouble reading the seams in the blink of an eye on a baseball from 60 feet as released at 90 MPH, even your average MLB cleanup hitter. It wasn't a coachable skill, so his advice was useless.
I suppose we could inject a drug to show the four sigma Lisp programmer what those damn things look like to your one sigma script monkey. Ethanol might work. You should be able to erase three sigmas with one bottle of Jack. When the Lisp person returns to sobriety, the response will most likely be "How can you live!" not "Humanity is unfit for S-expressions!" Intelligence is a weird thing, you get to a certain point, you become so smart you're stupid.
You think I'm exaggerating?
From Lisping at JPL
The integration manager is clearly in a world of hurt, and somehow the golden child was at the nexus of pain. I perked up waiting for this brilliant JPL Lisp programmer to dig into how this could be. But no. Integration manager is daemon spawn, and we return to the original blind devotion. Yet again, I wander deep into the campfire of the illuminated, and come back having learned nothing. In the Lisp world, ripe for a teaching moment equates to "you don't get it already, clearly you're not one of us".
For the record, J makes my eyes bleed, but if I put in the work, I'm sure I would learn something. I think what Lisp has to teach me is that fundamentally syntax is a liability and not an asset. Except when it isn't. I got that long ago. When Kurzweil unveils Vitamin Booster Dust, this amazing nugget of truth will suddenly become useful to me.
You think I'm joking?
That's a neat compensation. Since we can already guess at the wise things we'll all say after Vitamin Booster Dust hits the store shelves near you, just start saying them already. Or, for bonus points, solve two equations of compensation simultaneously: if we're suddenly that smart, our big mess will be refactored faultlessly in no time, so why are we wasting our time projecting a future that will take care of itself?
He cites the Javascript with statement for special scorn. Check out the guy with 185 up-votes demonstrating an interesting use case.
but Tcl is an even worse language than Lua.
But wait, there's more.
I'm sure I'm mentioned this before in a slashdot screed. Long ago, around the time I was first exposed to Lisp, I was reading papers on the philosophy of mathematics, including one I recall as Hilary Putnam on the syntax of the integers.
As we all know (speaking at least for the fifth row), Dedekind is famous for the line: God made the natural numbers. Everything else is the work of man.
This is very nearly the only statement about god I believe in, as a Kolmogorovist in good standing. Computer scientists should perk up their ears.
What Putnam did is introduce two different set theoretic foundations of the integers (which you could think of as dressing the integers up in the syntax of formalism). Both formalisms captured every property of the integers we regard as god-given.
However, both formalisms introduced other decidable statements that were far from god given. In one formalism, j < k implied j was a subset of k. The set construction looked a bit like tail recursion. In the other formalism, you didn't have all the Russian dolls, so this tautology was not in effect. I recall Putnam was arguing toward the point that no matter what set theory apparatus used to dress up the integers, these irrelevant man-given tautologies spring to life.
Yes indeed, syntax sucks. Can't live with it, can't live without it.
Thanks!
Free Manning, jail Obama.
I generally subscribe to the idea that if something is good, it will become popular all on it's own.
I'm trying to think of a single instance in the history of computing where quality and popularity have been correlated. Popularity and marketing budget, sure. Popularity and vendor lock-in, absolutely. Cost and quality, quite a few times. Popularity and quality? Give me another few minutes and I may come up with an example.
I am TheRaven on Soylent News
It has been long time since GNU has taunted how they will release their own OS and Linux becomes obsolete.
How it is going with the Client-Server Architecture? Was the Monolithic architecture for the OS so obsolete after all?
except that porcupines are allergic to raisins...
The craggy looking dude is the JPL integration manager. The demilobular fellow is the Lisp programmer in training.
Its the best language in the world and should be used for everything, no exceptions.
I'm trying to think of a single instance in the history of computing where quality and popularity have been correlated.
Every single popular thing on the planet has high quality in the areas that matter to the popular opinion, your definition of quality is not the only one, and arguably its not even the right one according to popular opinion. Which, btw, I trust more than you out of the gate until proven otherwise.
There are many variables in something that determine is popularity.
Facebook is a complete and utter pile of shit from a technical perspective as well as a privacy view point, they get it wrong on both accounts far more often than right. If you measure them on these values, facebook is shit ... but the population doesn't give a fuck about privacy or technical cool factor, it works, they get to feel popular themselves for being part of the crowd, and life goes on regardless of how much I think facebook sucks.
Now prove me wrong, without being subjective.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
And both are things for which the human brain has a built in propensity but is then paramaterized primarily through early life socialisation.
So presumably the GNU people's parents babbled at them in scheme when they were toddlers whilst preaching that JavaScript developers will burn in the eternal fire. It's the only logical explanation.
Google also just acquired ITA and they use Common Lisp extensively.
On the contrary, it is almost invariably correlated, but only as a threshold value. Below a certain quality level, nothing will be popular. Above that quality level, things have varying degrees of popularity depending primarily on other factors.
Thus, it is not true that the lack of popularity implies lack of quality, but the converse is true.
Check out my sci-fi/humor trilogy at PatriotsBooks.
In Science Fiction, a trilogy is a book written in four parts. Once more to the fray.
Another symptom of failing to get the syntax problem is the premature evaluation of Perl 6. It could yet fail, but it's still too soon to tell. Maybe you can live with syntax after all.
Perl 6 is also a cultural experiment that couldn't have been tried in earlier decades: what comes next when you have a large pool of greybeards? Obviously, a wonderkind language needs to be out there and evolving before the wonderkind wears off. Most of our languages were either designed by wonderkind, or committees of sober realists (famous paper not yet written: Realism Considered Harmful). Perl 6 asks the question, "After gorging on the Tree-of-Life, what comes next?" One attribute of the Pak Protector is a longer-than-human attention span.
Whether YAVM is worth anything seems to depend on other pieces of the puzzle. The sentiment is noble--that's the worrying part.
The only thing Lisp ever says about syntax is "you can always change your mind". Syntax is like a woman. You can change your mind, but you might choose not to. Some of the syntax in Perl 5 was clearly the wrong syntax. When Perl decided to upgrade on the domestic front, the self-reflection went a little deeper than Tiger's template: 99 bundles of blonde on the wall ....
Perl 6 is aiming to become everything that Lisp isn't. Hardly surprising it's taking a decade or two. Perl 6 is answering the question "what would happen if you embraced syntax with a whole lot of worldly experience under your belt?" This isn't much appealing to a generation of programmers operating under the sentiment that syntax is like flavours of ice cream.
In the process, Perl 6 has drifted so far away from the careerist rabble, it might die on the vine. However, I think it's an important question: is there room in computer science for a sober rethink?
>Finally, we have the lifespan issue. If GNU had chosen Tcl because it was popular, we would have a mass of dead code'
Absolute complete utter bullshit. If GNU picked TCL as a scripting language years ago, it would have gathered more momentum and wouldn't be a dead language today.
I'd like to see Rexx as an official scripting language, or if you want to go to the other end of the spectrum, Lua.
And it's still not too late to resurrect TCL.
--
BMO
I know I'll be in -1 land as soon as I submit this, but why not? If popularity and longevity is the concern, I think Java has them covered.
In Soviet Russia, articles before post read *you*!
But If I want JavaScript, why would I use Guile, hoping that they'd fix their JS support - eventually? There are many other libraries providing embedded JS today.
From your link "But Tcl syntax seems strange to most users."
Because Scheme is so popular and everyone already uses it and languages like it.
Really if they where going to reject Tcl because of it's syntax then they should have done the same with Scheme.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
In 2006, I wrote a not insignificant program in Guile - loved it. Added CORBA bindings to communicate with our other processes. The program calculated derived parameters from various satellite telemetry values (e.g., compute the sun angle based on 3 telemetry values). My manager blew a gasket when he found out that I had implemented it in this strange language. What else could I do - the spacecraft engineers had specified the equations for the over 800 derived parameters in a variant of Scheme! (The variation came in the fact that, where a telemetry point was referenced like a variable, the computation had to check the status flags of the telemetry point to determine whether to use it or not. Depending on the function being applied, a bad point would either be skipped or the calculation [or subexpression] would fail. It was a simple matter to read in the equations and rewrite them to correctly take into account the telemetry point references.)
The program was beautiful, extremely fast, and worked like a charm. It wasn't my fault that I was the only one in the company who could look at the spacecraft engineers' documentation and realize they were using Scheme. When I left the company the following year (with the code well-commented), I imagine my manager, who wasn't a bad programmer himself, probably leaped in and rewrote the whole thing in C++, hand-coding each and every one of those 800+ calculations.
So presumably the GNU people's parents babbled at them in scheme when they were toddlers whilst preaching that JavaScript developers will burn in the eternal fire. It's the only logical explanation.
While producing semantically equivalent code to that of the Javascript developers. That is the tragedy of binary life.
From their FAQ.
Why not use language X instead of Lua?
We needed a language that matched all of the following criteria:
Lua was the first language to match all the criteria. The known scripting languages tend to be much too large for our use. Specifically, we have rejected Java, Perl, Python, Ruby, Scheme on one or more of those criteria.
I think that one of the most important points is "Fun to work with". Lua is fun.
Why is Snark Required?
And 26 years later, GNU's still trying to explain what "free" means.
There are many extension languages, for each purpose...
Despite some harsh words about Tcl, Tcl is alive and well in certain GNU projects, including one of the more prominent GNU projects - GCC, the GNU Compiler Collection. GCC's test suite is run with the DejaGnu testing framework, which written in Tcl. So the next time you use gcc to compile code, be assured that Tcl has helped to make your executable run as you coded it.
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/README?view=co
http://www.gnu.org/s/dejagnu/
No sarcasm meant, does this issue matter to more than a handful of people?
Welcome to Slashdot!
"Convictions are more dangerous enemies of truth than lies."
Haskell ain't dying out whether people use it or not. It's simply too critical to programming language theory. In addition, Haskell is the perfect extension language for many situations. Sage should've obviously been written in Haskell for example.
Erlang offers a significantly simpler programming langauge with similar benefits, a larger commercial user base, and is perhaps more optimized towards the sorts of problems GUIs encounter.
Why use a toy language?
Use a real language, compile it down to machine code, and link it with a DLL/so interface.
make Guile's cheme go with everything?
I do not disagree. But the Guile supporters -- like RMS -- says we shouldn't chase the flavor of the moment, and instead use guile and have implementations in that. My point is that approach hasn't worked.
What do you know I wrote a novel
The GNU Hacker's Meeting page has "GNU Operating System" at the top. The GNU Operating System was intended to be "a complete Unix-compatible software system", with "all improvements that are convenient, based on our experience with other operating systems".
However, that's not what happened:
so one could argue that the real result of the GNU project is not the intended complete operating system but, instead, a collection of pieces of free software that have been adopted by a number of operating systems, including Linux distributions, the *BSDs, Mac OS X, and perhaps other commercial UNIXes.
Those operating systems are, however, not built with a 100% GNU userland. So, at best, Guile might, at some point, be the extension language for all pieces of software from the GNU project, and perhaps even for many pieces of free software not from the GNU project (most of it is licensed under the LGPL, so even non-free software written for environments that provide Guile could use it as an extension language, as long as they avoid GPLed parts such as the readline module), but I wouldn't hold my breath waiting for an operating system where it's the extension language.
Perhaps when Andy Wingo argued that Guile should be the extension language for GNU, he meant "for all pieces of software from the GNU project", but I wouldn't hold my breath waiting for it to be the extension language for an entire operating system - relative technical merits of various languages nonwithstanding, the world will probably have to live with the languages that Wingo asserts "are at the height of [their adoption curves] and beginning [their] descent" or that "will fall out of favor" for quite a while. Perhaps he's right, and Python's fading away and JavaScript will become a legacy language; if so, whether what replaces them is some flavor of LISP is something to be determined by waiting and watching. After all, Worse is Better.
The article doesn't contain a single argument for the use of Guile as an extension language. It tries to show off a few language features that LISP people will obviously love (and all other people never miss), but for an extension language other things should matter: small footprint, easy to pick up, no nasty surprises, successful use cases, robustness. Why the hell would one need to make the extension language extensible in an elegant way or want it to be "multi-paradigm"?
The sensible choice would be Lua and the GNU people should think long and hard about whether they really want to hamper their GNU evangelism by burdening it with evangelism for obscure (sorry LISP lovers) languages or perhaps choose something that doesn't get in the way of their important goals...
"I love my job, but I hate talking to people like you" (Freddie Mercury)
'GNU still needs an extension language' .. extension to what? Extension to GNU HURD, extension to the GNU compiler? I'm not sure what the context of this language is, and it seems incorrectly worded to me. If by 'GNU' the author means the GNU userland tools, then isn't C/C++ already the official 'extension' language of choice?
http://pymacs.progiciels-bpi.ca/index.html
<preach>
python optimized the correct thing: readability. It has been around for 20 years, and is still growing. There are multiple free implementations. It has very good interoperability with C, which is very important since most GNU software is written in C. It is a language which has survived harsh competition with other languages. The GNU people could use the above modules to transition to it smoothly. It's the right answer.
</preach>
"Most programmers have never heard of it."
[Citation needed]. Are you kidding? Exposure to LISP-like languages is a basic tenet of a well rounded computer science education. Even if one doesn't use it in the real world, it is *invaluable* to know, because it can change how you see and think about problems. It was doing extremely advanced high level language features in the 1950's and 60's that MOST languages do not yet have even today.
Then again, given the absolutely shitty level of ability that 99.5% of the current generation of programmers have - half of them have never even written something in assembly language - perhaps you are right.
My point is simply that to say its not locked down is a lie. [...] Why do people insist on trying to pretend GPL and LGPL are something they aren't?
Because "locked down" lately is more likely to mean "mandatory verification of digital signatures on all executables, with no way for a home user to permanently add his own root CA". This is true of TiVo, iOS, and all modern video game consoles, specifically to prevent users from taking advantage of the freedoms that developers have locked down for them. Ultimately we've run into yet another case of Layne's Law: discussion breaks down once it becomes a debate over the definition of a word.
Until recently (moved to a new city), I was a volunteer at my old elementary school. Their gifted and talented math program had been shut down due to budget cuts: the teachers tried to compensate by getting professional mathematicians in to talk to the kids who should've been in gifted math programs. My role was simple: get fourth graders involved in math.
Each year on our first day together I'd use the LISP notation. I'd ask them, "if I told you to add the numbers one to ten together and multiply the result by fifteen, how would you write that down? Not the answer, but what I told you to do?"
They usually came up with 1+2+3+4+5+6+7+8+9+10*15. This got us into talking about precedence and order of operations and everything else. Their eyes would spin. So, multiply before add, but divide and multiply are co-equal operators and you do them in linear left-to-right order, unless grouped by parenthesis, and...
"You know, this is pretty stupid, isn't it?" I'd ask them. "It's too hard. How are we supposed to keep track of all that? Who came up with this, anyway?"
I'd then write, (* 15 (+ 1 2 3 4 5 6 7 8 9 10)).
Not once, not ever, did it take a class of fourth graders more than five minutes of using this syntax to realize it was so much better than the 'traditional' syntax. It let us communicate clearly about what we were doing and in what order. On top of it, it looks kind of weird and exotic, and kids love writing in codes -- the fourth graders took to it like ducks to water. It was something that neither their classmates nor their teacher understood, and a professional mathematician told them, "yes, this really is how a lot of us in the field prefer to write things."
GNU *already has* an extension language.
It's called "bash"
.
C|N>K
Performance is important
My benchmarks show that guile is a pretty slow. For example, on one machine, it was 238 times slower than C. So, instead of a 3.6 GIPS machine, we'll all go back to 15 MIPS. Who here wants to use a 486/66 again? Who here isn't old enough to remember when Intel had numbers for chip models? Perhaps the long jump support could be removed and half way decent performance could be put in. I mean, what good is a functional language when it's faster when you code loops?
I was researching LISP a couple years back and ran into a great quote. It talked about how a student had written an elegant matrix multiply function in LISP, which had the misfeature of being incredibly slow. It caught my attention because i'd written a nearly identical function, and was amazed at how poorly it performed. The author made the comment that no C programmer could make such a mistake. However, he totally failed to give the slightest hint on why the performance should have sucked. And, he continued to rant about how (compiled) LISP was as fast as C.
Javascript is finally getting some performance. Firefox 3.5.7's javascript is only 25.6x slower than C. The recent browser wars show rapid progress.
Readability is important
That said. I know dozens of languages. I understand my 30 year old BASIC programs without much effort. I was a bit more clever with my 25 year old C programs, so they're a bit tougher. LISP is one of only two languages where i actually took a class. But none of my LISP or scheme is halfway comprehensible two weeks after i've written it. Forth is a bit better, taking a couple months. Procedural languages are simply easier. At the end of the day, you spend most of your time in maintenance. If it isn't broken, then the requirements are changing. Oh, and time is money, just like Einstein said.
-- Stephen.
yes, their QPX software is used by Orbitz. Main engine is written in Allegro Common LISP http://www.franz.com/success/customer_apps/data_mining/itastory.lhtml
Other companies that use Allegro CL include Naughty Dog (for their playstation games dev environment) and Marai I mentioned.
Have to laugh when people say no one uses LISP anymore and their are tens billions of dollars of global business annually powered by it
Microsoft's COM scripting (aka OLE Automation) is a close equivalent to the AppleEvents mechanism, and it's pretty easy to use (with the slight downside of not being self-documenting, unless you count foofing around in a COM browser as documentation). Having done both, it's actually less painful to use COM-scriptable apps from Python (using win32com) on Windows than it is to use OSA-scriptable apps from Python on Mac OS X.
It seems like DBus could achieve the same role as OSA or COM scripting if most DBus interfaces weren't astonishingly half-assed.
I love cilantro, but I hate Scheme. Maybe your analogy is as accurate as one involving a vechicle. Guile might as well be Canturbury Tales to me.
32-bit HURD? Why didn't you run it on an UltraSPARC like a real hacker? I swear, the amateurs on slashdot these days.
How about libpeas, or something like that?
At the moment GNOME provides extending with Python, JavaScript and C via some FFI magic stuff...
I'm sure they can make something like that *if* they really decide to do it...
LUA is a piece of shit language compared to scheme
GNU sees the big picture unlike you and your tiny little brain
Where will LUA be in 10 years? nowhere
Lisp has been in use for more years that you've been alive
lots of people can't program. This probably means that the few that can actually can't - because, you see, they are unpopular and outnumbered. Should we replace all the programmers with laymen? Laymen are widespread you see.
Lisp was around for 50 years. And will be for 50 years more, irrelevant of popularity - which means "write once, never rewrite in other language again".
I am in the business of legacy mining. We are mining COBOL at the moment, but in 10 years time we are likely to mine Java. Guess what? We do it in Lisp!
based on it's language features
purely on it's popularity
"its".
all on it's own
"its".
Not to nit too much, but I am fairly certain (I may have secret inside information OR: planet lisp) that ITA moved to a mixture of SBCL and Clozure CL, with the main scheduling engine running on SBCL.
Of course, Google will probably just fire everyone, rewrite it in Java, and cause the entire airline industry scheduling infrastructure to collapse...
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
I did search on site:lisp.org for that but couldn't find it, maybe was another source (or google sucks)
picol.c is a subset of tcl written in 550 lines of C.
But...but...that's not yet-another-twitter-clone! It doesn't count!
"We live as though the world were as it should be, to show it what it can be." - Joss Whedon via Angel
Yeah, and on the way they made one of the slowest imaginable languages. Well, ok, Ruby is worse, but - serious constant overhead for function calls? Are you kidding? If you want OOP and readable, try Ada 2005. Hell, Haskell supports indentation closed blocks - though you need to spare some of the high end features.
I know tobacco is bad for you, so I smoke weed with crack.
The authors of the C code had written to strange constraints 20 years ago, and re-factoring C was so painful, no-one would touch it. A total re-write, thinking about the algorithms (which is possible when there is less code to worry about.) and for current machines, made it possible to make things much better. I don't know Haskell, I've heard good things about it, and I like rabbitMQ. I have had very good success with python, however. Readability really is the most important thing. Once you're doing the right thing, you can always optimize it later, and C will be there for you then.
Most programmers have never heard of it.
Proof that Sturgeon's Law applies to programmers.
programs with minimally useful command line invocations, extension languages are the 'glue logic' you get(observe your local Office guru's bludgeoning about of VBscript, or some photo-pro's slightly alarming Photoshop batch processing abilities); but the unix 'flavor' has historically been that the shell, rather than the program extension language, has been the tool of choice for bodging jobs too big to tackle manually but to small to be worth delving into the guts of the programs themselves.
I think that is sort of sad. Take VBA for example. From the windows script host you can create office objects, manipulate them, and send out through outlook, from one script.
Now, you can accomplish that with the UNIX model, but it's clunky as hell. Two streams of uni-directional unstructured data, everything is stateless, command switches cannot be discovered at runtime in a sane manner, and error reporting is often simply 0/1. Going forward, few people are really designing applications to any of that. Modern Linux apps usually lack documented exit codes, lack the ability to do anything useful to stdin, DO often have reasonable argument parsing, but often output text that is unnecessarily difficult to parse. Gnome & KDE apps are AFAIK still instrumented differently, and command line apps haven't adopted either system as any kind of standard.
BASH doesn't need to lose for standardized program instrumentation to win. BASH would benefit greatly from things like argument/method discovery, typed & structured IO, etc. At some point you have to drop notions of KISS and design things from an updated holistic view of the world. Simple should be from the user's perspective, because isn't it an engineer's job more or less to make complex things work for normal people?
Fast python code means that you are not CPU or cache constrained. And what is so unreadable about Ada. Or even scheme.
I know tobacco is bad for you, so I smoke weed with crack.