Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Two Years of GNU Guile Scheme 2.0

Unknown Lamer posted about a year and a half ago | from the better-lisp-for-a-better-tomorrow dept.

Programming 107

Two years ago Guile Scheme, the official extension language of the GNU project, released version 2.0, a major upgrade to the implementation. As part of the two year anniversary, the maintainers organized a challenge to hack a small project using Guile in 30 days as part of a birthday software potluck. The two coolest dishes appear to be OpenGL support using the FFI, and XCB bindings built using the XML specification for XCB: "guile-xcb is a language implemented in the Guile VM that parses the XML files used by the xcb project to specify the X protocol and compiles them into Guile modules containing all the methods and data needed to send requests to the X server and receive replies/events back. If new X extensions are added to the xcb library, guile-xcb can compile and add them with no additional work. " See the release announcement for details on the other dishes.

cancel ×

107 comments

Sorry! There are no comments related to the filter you selected.

Dumb (0, Interesting)

Anonymous Coward | about a year and a half ago | (#42955611)

Sounds stupid and pointless. *golf clap*

scheme, bitches! (-1, Troll)

Anonymous Coward | about a year and a half ago | (#42955669)

You better learn a second programming language and the programming language should be scheme.

Face it -- Perl is dead, ruby is full of idiots that were too dumb for php, and don't get me started on python. No, you need to learn scheme. Parenthesis, continuations, monads, all that shit.

Re:scheme, bitches! (3, Informative)

Anonymous Coward | about a year and a half ago | (#42956027)

Perl is dead

Only in my happiest, wildest, wettest dreams.

Re:scheme, bitches! (0)

Ryan Ray (2846655) | about a year and a half ago | (#42957121)

You need to dream wilder, wetter.

Wet? (0)

Anonymous Coward | about a year and a half ago | (#42964979)

You a Java guy? And have *wet* dreams?

Sheesh.

Guile supports curly-infix, too! (4, Interesting)

dwheeler (321049) | about a year and a half ago | (#42955677)

Another cool thing about GNU guile is that the most recent version supports SRFI-105, "curly-infix-expressions" [schemers.org] , as developed by the Readable Lisp S-expressions Project [sourceforge.net] . Curly-infix expressions let you write stuff like {a + b} instead of (+ a b), which is a big improvement in readability.

Re:Guile supports curly-infix, too! (2, Insightful)

Anonymous Coward | about a year and a half ago | (#42955783)

Correct me if I'm wrong, but wouldn't that break the fact that in Lisp everything is supposed to be a list? In (+ a b) it's clear to both user and interpreter what the first member of the list is, but with {a + b} the interpreter may know what is what, but the user no longer sees firsthand that the s-expression is a list like any other. The key to groking Lisp is to learn to think recursively like the interpreter, and I would think that this change in notation unhealthily forces thinking patterns derived from other languages.

Re:Guile supports curly-infix, too! (3, Insightful)

cduffy (652) | about a year and a half ago | (#42955935)

Correct me if I'm wrong, but wouldn't that break the fact that in Lisp everything is supposed to be a list?

Plenty of LISPs break that "rule", and usually for the better. Clojure wouldn't be the tremendously practical and useful language it is if it didn't have vectors, maps, queues, and the like.

What's important is that the language retains isomorphism (and thus, LISP's full measure of metaprogramming power) -- as long as your parse tree and your code map 1:1, adding some additional types does no harm and a world of good.

Re:Guile supports curly-infix, too! (0)

Anonymous Coward | about a year and a half ago | (#42956119)

He means code is supposed to be a list, not that the language should only supports atom and list types and nothing else. (Why Clojure, anyway? All that stuff is in Common Lisp.)

as long as your parse tree and your code map 1:1

Jeez, that's the whole point GP is making! It doesn't map 1:1, if you have {a + b} as a secondary representation for the list (+ a b).

Curly-infix-expressions are just abbreviations (2)

dwheeler (321049) | about a year and a half ago | (#42956479)

Curly-infix-expressions (as well as sweet-expressions, which are a superset) are just additional abbreviations. In curly-infix, the surrounding "{...}" indicate that it's a list, but that parameters are written in a different order than they are actually stored. So {a + b + c} is just (+ a b c). We're now wrapping up sweet-expression notation, which is a superset that uses syntactically-relevant indentation (like Python). Check out http://readable.sourceforge.net/ [sourceforge.net] for more info, and in particular, please join the mailing list!!

Re:Curly-infix-expressions are just abbreviations (1)

Anonymous Coward | about a year and a half ago | (#42957071)

From that page I see that they make the same error as Python, to allow both spaces and tabs for indentation (however I don't see any specification how tabs are treated). That's a great recipe for hard to find bugs (because you literally don't see the difference between spaces and tabs). Especially given the fact that different people tend to use different tab sizes (while traditionally a tab goes to the next multiple of 8 characters, nowadays it is usually configurable, and people do configure it).

Spaces vs. tabs (2)

dwheeler (321049) | about a year and a half ago | (#42957127)

There's no problem. You can use spaces or tabs, but you HAVE to be consistent when you use one or the other. So if you indent a line with a tab, all sibling and child lines MUST start with a tab... multiple spaces don't count. You can even mix, but you still have to be consistent, so if you use tab space space, all later siblings and child lines must start with tab space space.

Re:Spaces vs. tabs (0)

Anonymous Coward | about a year and a half ago | (#42957885)

Python specifies it simply and sensibly: TABs indent to the next tab stop. Tab stops are at 8-space intervals.

I wish that primordial rule were employed universally.

Re:Spaces vs. tabs (1)

Urkki (668283) | about a year and a half ago | (#42958021)

That's not simple, and I'd argue it's not sensible either. Sensible thing is to specify that there is just one indentation character, and for practical reasons it has to be space (tabs can always be converted to space only by any programming editor, but spaces can't be converted to tab-only by common editors). Problem solved.

It would be neat if all indentation was tabs, and tab width would be purely visual thing, up to each individual looking at the code, much like font is. Then meaning of tab in source code would be "exactly one indentation level", and programming world would be a better place. But alas, real world conflicts with that ideal.

Re:Spaces vs. tabs (0)

Anonymous Coward | about a year and a half ago | (#42958157)

Well, we won't ever agree on that, but maybe we can imagine a world where there is no TAB character and no editor misalignment problems.

Re:Spaces vs. tabs (1)

Darinbob (1142669) | about a year and a half ago | (#42958917)

Ya, tab was a bad character to be included in the character set as it is. It is nice to have as a key though but should have been a non-printing character. Just my opinion though.

Re:Spaces vs. tabs (1)

dwheeler (321049) | about a year and a half ago | (#42958841)

The *notation* is more flexible. That said, if you want to use the notation a particular way, then feel free. I normally use two-space indentation in sweet-expressions. However, to get a notation accepted for wide use, the notation has to accept the different ways that people work. Python accepts either spaces or tabs, specifically because you can't get agreement on one or the other. The same argument applies here, too.

Re:Spaces vs. tabs (1)

maxwell demon (590494) | about a year and a half ago | (#42958811)

There's no problem. You can use spaces or tabs, but you HAVE to be consistent when you use one or the other. So if you indent a line with a tab, all sibling and child lines MUST start with a tab... multiple spaces don't count. You can even mix, but you still have to be consistent, so if you use tab space space, all later siblings and child lines must start with tab space space.

So what happens if I start the next line with spaces?

Re:Spaces vs. tabs (1)

Darinbob (1142669) | about a year and a half ago | (#42958877)

This fails in practice. I don't do Python so I don't know how they solve it, but when I used Occam it was a major hassle. Problem one was that youc ould not visually see the difference between spaces and tabs and very few editors enable this (no fair using language specific editors. Additionally once you have multiple programmers touching the same file it all goes to hell, because everyone has a different notion about spaces vs tabs and tab width. Similarly, it's a pain in the ass in Makefiles, it's a pain in the ass in some versions of Fortran, etc.

With "normal" languages there is no such ambiguity and no reason to impose style guidelines just to make code compile. The tiny benefit from reducing the number of characters being typed does not exceed the drawbacks that arise.

Re:Spaces vs. tabs (1)

dwheeler (321049) | about a year and a half ago | (#42959447)

Actually, it turns out there's no problem.

The tools require consistency, and report an error where it's not. Then if you are a tab-only person, you can use tabs. If you are a spaces-only person, you can use spaces. If you try to use them inconsistently (tab on one line, where space was used on the previous line), then it reports an error.

Notice that this is COMPLETELY DIFFERENT from Makefiles. The problem with Makefiles is that there are cases where you can't tell where an error is, and so it quietly does the wrong thing. Requiring that you MUST be consistent means that you can use either spaces or tabs... but the next line that's indented better be consistent with its parent.

Re:Spaces vs. tabs (1)

goose-incarnated (1145029) | about a year and a half ago | (#42964155)

Actually, it turns out there's no problem.

Actually, it turns out that there is a big problem.

The tools require consistency, and report an error where it's not. Then if you are a tab-only person, you can use tabs. If you are a spaces-only person, you can use spaces.

That's nice, but not everyone is a lone coder working on toy projects of no relevance which never get maintained by other devs. Here in the real world it's rare to find a single source file for even tiny (but real, not toy) projects that hasn't been touched upon by at least three different people over the course of three years.

Hell, in one system I worked on, the original comments in the source code dated from 1992 when the code was written for some 8-bit machine. When I started working on it I was building it for arm, and there had already been over 35 developers named in the comments ...

It would be nice to write code that I knew for sure would never be edited by another dev. I don't think that that's ever gonna happen though.

Re:Guile supports curly-infix, too! (1)

TaylanUB (2846617) | about a year and a half ago | (#42956337)

The curly syntax can be purely lexically transformed to normal s-expressions. E.g. {x + y} turns directly into (+ x y) as soon as it's read in, before it's even evaluated as code. So homoiconicity is retained and there is absolutely no problem. You can read SRFI-105 or look at the "Sweet Expressions" project yourself to see the details of how exactly things work, and what the limitations are. (Hint: It does NOT save you from learning the true underlying prefix-notation, it's merely a convenience for when you already know how "true" Lisp code looks but you want something that just looks better at a glance.)

Re:Guile supports curly-infix, too! (0)

Anonymous Coward | about a year and a half ago | (#42956619)

Correct me if I'm wrong, but wouldn't that break the fact that in Lisp everything is supposed to be a list?

No, it doesn't, because it's just another way to write down a list (just like 'a is just another way to write down the list (quote a)). So if you write {2 * {a + b}}, it's equivalent to writing (* 2 (+ a b)) (or (* . (2 . ((+ . (a . (b . ())) . ())) for that matter, because strictly speaking it is not true that everything in Lisp is a list; the fundamental data type is the dotted pair, not the list).

Re:Guile supports curly-infix, too! (0)

Anonymous Coward | about a year and a half ago | (#42958017)

(or (* . (2 . ((+ . (a . (b . ())) . ()))))
fixed that for ya...

Re:Guile supports curly-infix, too! (1)

Hentes (2461350) | about a year and a half ago | (#42956715)

As long as the braces are implemented with a macro, that's not a problem.

Braces are implemented in the reader (1)

dwheeler (321049) | about a year and a half ago | (#42959525)

Actually, the braces are implemented in the reader. In Common Lisp terminology, they can be implemented as a "reader macro", but this is a completely different step than the Lisp "macros" usually refer to. This means that you can use {...} with data or code, and you can even use them as inputs to macros (in the usual sense). Thus, you can combine Scheme's "define-syntax" with {...} without problems. The SRFI-105 spec has some examples you might want to look at.

Re:Guile supports curly-infix, too! (2)

larry bagina (561269) | about a year and a half ago | (#42957017)

You should read John McCarthy's original lisp paper sometime. He used m(eta)-expressions -- eg, +[a, b] -- rather than s-expressions. S-expression evaluation was implemented first and now you're stuck with it.

Re:Guile supports curly-infix, too! (0)

Anonymous Coward | about a year and a half ago | (#42957951)

I like S-expressions and don't care too much about syntactic sugar that tries to hide their beauty. No infix for me and my scheme code.

I keep using emacs' *scratch* buffer as a programmable calculator. I feel no need to deviate from the S-expression syntax. It's clear, it's tidy, it's unambiguous.

Re:Guile supports curly-infix, too! (0)

Anonymous Coward | about a year and a half ago | (#42957293)

Correct me if I'm wrong, but wouldn't that break the fact that in Lisp everything is supposed to be a list?

Only if you're still living in the first half 1960's. Very few things are lists in any Lisp from 1970's onward.

Re:Guile supports curly-infix, too! (1)

tibit (1762298) | about a year and a half ago | (#42958445)

Lists are general but poorly performing data structures. Modern Lisps aren't all about lists at all. They have multiple data types.

RPN is scarey! (1)

Anonymous Coward | about a year and a half ago | (#42955851)

RPN has always scared people. It's why HP calculators don't dominate the market.

Re:RPN is scarey! (1)

usmcpanzer (538447) | about a year and a half ago | (#42956293)

RPN has always scared people. It's why HP calculators don't dominate the market.

Scheme (and Lisp) uses prefix notation, i.e. the operation symbol + comes first, (+2 2). Reverse polish notation, also known as postfix notation, the operation symbol comes last, (2 2 +).

Re:RPN is scarey! (0)

Anonymous Coward | about a year and a half ago | (#42957107)

not sure whether your comment is sarcasm (HP dominates the market), off topic (RPN?) or trolling (well done?).

Re:RPN is scarey! (0)

Anonymous Coward | about a year and a half ago | (#42958351)

I think the GP posted on the wrong article. So off topic I guese but understandable I think.

I think it's coincidence that the stories are close enough for the GP to seem just wrong rather than massively offtopic

Re:Guile supports curly-infix, too! (0)

Anonymous Coward | about a year and a half ago | (#42955901)

How is reverse polish notation hard to read unless you have a sub-average intelligence?

Re:Guile supports curly-infix, too! (0)

Anonymous Coward | about a year and a half ago | (#42956651)

Notation polish reverse read to hard is Yoda I am not because.

Re:Guile supports curly-infix, too! (0)

Anonymous Coward | about a year and a half ago | (#42956001)

This SRFI is in ``final'' status.

What kind of clown types quotation marks like that?

Re:Guile supports curly-infix, too! (0)

Anonymous Coward | about a year and a half ago | (#42957313)

This SRFI is in ``final'' status.

What kind of clown types quotation marks like that?

Probably someone used to write in LaTeX. Because that's the way to get the correct quotes there.

Re:Guile supports curly-infix, too! (1)

Anonymous Coward | about a year and a half ago | (#42956007)

(is
        (about 'GNU guile' (another 'cool thing'))
        (support 'most recent version' (clarification (clarify 'SRFI-105'
                                                                                                                                                  (developed 'Readable Lisp S-expressions Project')
                                                                                                                                      "curly-infix-expressions")))

Another cool thing about GNU guile is that the most recent version supports SRFI-105, "curly-infix-expressions" [schemers.org], as developed by the Readable Lisp S-expressions Project [sourceforge.net]. Curly-infix expressions let you write stuff like {a + b} instead of (+ a b), which is a big improvement in readability.

Re:Guile supports curly-infix, too! (1)

semios (146723) | about a year and a half ago | (#42956627)

{{(another 'cool thing') about 'GNU guile' } is
    {'most recent version' supports
(clarification (clarify 'SRFI-105'
                                                (developed 'Readable Lisp S-expressions Project')
                                                "curly-infix-expressions"))}}

Re:Guile supports curly-infix, too! (2)

rmstar (114746) | about a year and a half ago | (#42957099)

For Common Lisp there is the "infix" package, which you can just load as part of your program. You can write infix using a #i() reader macro. Thus, #i(1+1) is equivalent to (+ 1 1), etc.

Programmers that use Lisp or Scheme for a while end up using plain prefix. The percieved inconvenience of prefix notation is due to not being used to it. After a while you realize that prefix notation is a lot more readable and less error-prone than infix.

Re:Guile supports curly-infix, too! (1)

dwheeler (321049) | about a year and a half ago | (#42958971)

"Programmers that use Lisp or Scheme for a while end up using plain prefix."

Sure, for those few programmers who keep using (Common) Lisp or Scheme. But almost all developers say, "what, no infix?", and ignore or stop using Lisps. And those who stick around find that it's hard to use infix in most Lisps today because there's no standard mechanism for using it. We're working to fix that, while keeping Lisp homoiconic and general.

The percieved inconvenience of prefix notation is due to not being used to it.

Prefix and infix have exactly the same capabilities, notationally. But of COURSE people are used to infix. Are you saying that schools will stop teaching and using infix in school? That math books will stop using it? I do not think so, and that means that while infix and prefix have the same capabilities, failing to support the standard (infix) has been a long-standing problem in Lisps. All developers show up with 15+ years of experience with infix, and 0 with strict prefix. Even if YOU like prefix, all future developers will have a 15-year head start in reading infix. So saying, "everyone will do it this non-standard way" doesn't really make sense, and more importantly, is provably false. Lisp has has had 50 years to convince people to only use prefix and failed to convince most developers; time to do something different.

After a while you realize that prefix notation is a lot more readable and less error-prone than infix.

I disagree. They are the same in terms of capability. And when people spend 15+ years being trained in one notation, all other notations are less readable and will remain so for many years. I've been writing prefix code for 30 years, and it isn't magically more readable. Indeed, what I find is that many people are unwilling to use a language that cannot handle infix.

Re:Guile supports curly-infix, too! (1)

jbolden (176878) | about a year and a half ago | (#42961631)

I use Haskell which has infix and prefix and does a pretty good job of letting your pass between the two

i.e. you can take infix star and write ((*) 2 3) for (2*3)
and you can take prefix f (a `f` b) for (f a b)

That being said what makes LISP, LISP is the complete lack of syntactic structures that parsing is trivial. The fact that you can write in a LISP evaluator in a few hundred lines and thus whip up a DSL inside of anything is what makes LISP. I don't mind curly braces. I don't mind Clojures additions but ultimately I think those things absolutely should just be macros that all resolve to infix notation.

Re:Guile supports curly-infix, too! (1)

Darinbob (1142669) | about a year and a half ago | (#42958827)

A real lisper would find (+ a b) to be easier to read and less ambiguous. This is similar to someone going to the HP calculator fans and telling them that you have a patch to allow it to work like a TI calculator, they're just not going to be impressed. The real reason perhaps is that people want to get rid of what they mistakenly think are redundant parentheses, however in order to do that you dont need infix what you really need is operator precedence, and that's an ugly bag of worms with no business appearing in a functional language.

Emacs and Guile need each other (3, Interesting)

Anonymous Coward | about a year and a half ago | (#42955683)

I've wanted to get into Lisp, but it's frustrating that my everyday GNU environment is split between Guile and Emacs Lisp. I wish that the project, talked about for years, to rewrite Emacs and base it on Guile would take off. It would save Guile, in a sense, because in spite of Scheme's status as the official GNU extension language it tends to be overlooked, and Emacs would benefit greatly from the bindings already developed for Guile.

Re:Emacs and Guile need each other (4, Informative)

Unknown Lamer (78415) | about a year and a half ago | (#42955763)

It's close to being reality [hcoop.net] . Guile has an Emacs-Lisp compiler to its VM that can run actual elisp programs, but lacks... the emacs part. And last summer's GSoC (perhaps this summer, finishing it?) saw emacs's lisp interpreter ported to guile... as in, the C representations of Emacs's internal data types and control structures are done using libguile. The code is currently being rebased on the latest emacs trunk; hopefully it'll see public release sooner than later.

Now the two pieces just have to meet in the middle.

So that's the first 95%. Now just for the other 95%!

Re:Emacs and Guile need each other (1)

Darinbob (1142669) | about a year and a half ago | (#42959101)

I dunno, I still prefer Lisps with good old fashioned dynamic scoping (aka, special variables). Scheme is statically scoped and thus can be a very different style of programiming. Not that there's a whole lot of stuff in Emacs still that uses dynamic scoping, it would just feel wrong to kill off the last bastion of that style. I haven't used Guile much but I always got the impression that it was bulkier than Emacs Lisp (but then most FSF projects seem to bulk up fast, ala GNU Hello World).

Re:Emacs and Guile need each other (1)

guacamole (24270) | about a year and a half ago | (#42961201)

One goal does not need to interfere with the other. Emacs Lisp and Scheme are trivial to learn. Scheme is a more of a general purpose programming language. It's trivial to learn (see HERE [neu.edu] )It's also worth learning simply because one of the best CS books, the SICP [mit.edu] , is using Scheme. As for Emacs Lisp, I don't see a need to get very deeply into. Scheme is nicer and more simple. Emacs Lisp is the language much of emacs is written in as well as its modules. Unless you have in mind writing Emacs modules, picking up elisp from Emacs's built in tutorial is more than enough for hacking your personal .emacs file. (however, coding a text editor in elisp sure kicks the ass of using Cs for that)

I honestly, don't know why Scheme hasn't picked up steam in the mainstream. Yes, we know people don't like the aesthetics of s-expressions, but other than that it's a fantastic programming language. It has the nicest cleanest implementation of lexical scope and closures I have seen so far, dead simple syntax (you can write a minimal scheme interpreter in Python or Scheme in 100-200 lines), first class functions, higher order functions, dynamic memory management, powerful lambda expressions (this is to name just a few features). In fact, Scheme had things 20 years ago that other programming languages are still copying from it.

Re:Emacs and Guile need each other (1)

jbolden (176878) | about a year and a half ago | (#42961665)

If by mainstream you mean professional. Common Lisp stagnated and until Clojure there really wasn't a LISP with professional libraries. The LISP community all during the 1980s and 1990s simply didn't want to make the compromises needed to have a mainstream language. I think that in many ways Haskell has taken the role that LISP used to play in terms of language of the future.

If by mainstream you mean educational. It is a pity. Racket is fantastic for educational scheme. The AP exam is based on Java, but arguably that's a chicken and egg thing.

Re:Emacs and Guile need each other (1)

Unknown Lamer (78415) | about a year and a half ago | (#42962515)

Common Lisp only had a few years of stagnation... It more suffered from being a decade ahead of its time so folks took "you can still run code from 1995 in the aughts" as a sign of decay instead of stability. Of course, it never really did regain the GUI capabilities (except for Clozure on OS X) the proprietary stuff had since the whole compiler/tools industry just collapsed suddenly.

I've used CL professionally, and I'd put it on par with C++ for that... powerful, well supported, without the annoyances of Java, but fundamentally flawed... at least the development environment (Emacs + SLIME) is better than anything other languages provide (sadly, that's what keeps me coming back to it for more abuse).

Re:Emacs and Guile need each other (1)

jbolden (176878) | about a year and a half ago | (#42962711)

I don't know about that. QuickLisp may have solved so of this but the situation was bad for many years. Have you gone through something like Perl or Java library collections to see what a full set of libraries looks like? It isn't just GUI is it everything.

A far as IDEs, yeah it is a problem for most non static languages. The static Algol based languages have the best IDEs. Clojure has fairly good support because of its ties to the Java community, you might want to check that out. I keep my eye on http://leksah.org/ [leksah.org] for Haskell an hope.

Re:Emacs and Guile need each other (1)

muuh-gnu (894733) | about a year and a half ago | (#42963851)

> I wish that the project, talked about for years, to rewrite Emacs and base it on Guile would take off. It would save Guile

Exactly, and this is exactly its problem. It is not the Emacs people who are pushing this rewrite, but the guile people. in order to get a "killer app" as a vehicle to advertize Guile, because nobody else wants to write a killer app in guile from scratch.

Of course, Emacs would benefit from an vastly improved Elisp engine too, but my feeling is that the usual Emacs users actually do not want to switch from Elisp to Scheme in the long term. Elisp is a descendant of Maclisp, and as such much more resembles the look and feel of Common Lisp than Scheme. There is even a big subset of Common Lisp implemented in Elisp. There is no similar Scheme package, because Emacs people do not like Scheme. They like Lisp.

The problem is, even though they have two Lisp implementations under their umbrella, CLISP and GCL, GNU made the decision to _not_ use Common Lisp as their "official" high-level language some 20 years ago, because RMS had problems with Lisp companies during the 80s, and they are now sticking with Guile no matter what against all opposition. It was a bad decision, but now they have invested 20 years of effort into guile an do not or can not go back. The push to get Emacs onto guile is purely political. I have the feeling that the political push by GNU to start writing in Scheme instead of Lisp will alienate a lot of people in the emacs community and maybe lead to a fork.

In short: Pushing people to write Scheme instead of Elisp will either lead to Emacs dying (because people do not like Scheme) or lead to a fork (because people do not like Scheme). If you absolutely have to rewrite Emacs because the Elisp engine is so kaputt, rewrite it in Common Lisp. Having a high quality Common Lisp available with every Emacs install would benefit _Emacs_. Having Guile installed with every Emacs will only benefit Guile, but Emacs will die. And why? You'll guess it, because people simply do not like scheme.

Scheme rocks, but lost the race (2)

WaywardGeek (1480513) | about a year and a half ago | (#42955715)

I love Scheme. I even wrote my own scheme interpreter way back and used it as the embedded control language in QuickLogic's P&R tools. However, only software geeks like Scheme, making it a terrible language for tool control for anything but software dev tools. TCL beat the heck out of Scheme in terms of popularity for this purpose. Python beat the heck out of Scheme as well. Perl got adopted by the text mashing crowd. Also, Guile, at least in the 1.0 version had issues. For example, it really wanted to have main in it's code, while your entire application was something it called. TCL has a better architecture for embedding. Anyway, this is nice, but I don't personally see a significant future for Scheme.

Re:Scheme rocks, but lost the race (0)

Anonymous Coward | about a year and a half ago | (#42956415)

Anyway, this is nice, but I don't personally see a significant future for Scheme.

Python and Ruby are almost there. Nowadays even closures are a must-have in business languages like C# and Java. Really, only S-expressions are macros are missing from lisp being the beginning and the end of programming languages.

So just wait. Lisp might yet be the winner that replaces the rest of the bunch and XML as well.

Re:Scheme rocks, but lost the race (1)

dkf (304284) | about a year and a half ago | (#42958219)

So just wait. Lisp might yet be the winner that replaces the rest of the bunch and XML as well.

People were saying almost the same thing 20 years ago (except not about XML; work on that started in 1996). How long do we have to wait? Is it just the case that Lisp is the programming language of the future, and will always remain so?

Re:Scheme rocks, but lost the race (1)

Darinbob (1142669) | about a year and a half ago | (#42959355)

Ruby kind of messed up blocks though, which makes closures a bit messy. It seems like Ruby wanted to copy Smalltalk but in a more textual style, but then it messed out on flexible blocks. Ie, Ruby blocks only at the end of an expression and to turn a block into a first class object you have to jump through some hoops. Compare to Smalltalk's "[a block] on: Exception do: [another block]".

Re:Scheme rocks, but lost the race (1)

jbolden (176878) | about a year and a half ago | (#42961677)

Python doesn't have lambda expressions or first class functions. Python is far less like Scheme than it was 15 years ago.

Re:Scheme rocks, but lost the race (2)

WaywardGeek (1480513) | about a year and a half ago | (#42962545)

Huh? Here's Python's lambda expressions. [python.org] And of course, from the fountain of all knowledge, Python has first class functions [wikipedia.org] . Now, that said, it's still not Scheme.

Re:Scheme rocks, but lost the race (1)

jbolden (176878) | about a year and a half ago | (#42962807)

fs = [(lambda n: i + n) for i in range(10)]
fs[3](4)
returns 13
should be 7.

Python has a broken non-functional semi lambda. This has been an issue of controversy.

_____

I didn't realize they added partial application. I'll take my comment about first class functions back.

Re:Scheme rocks, but lost the race (1)

Anonymous Coward | about a year and a half ago | (#42956559)

I've seen a lot of higher-order and first-class written in Python, but I've always been able to model semantic flows in LISP and Scheme faster. Half of what people need in that kind of model could be done in Prolog, and the rest could be done in OCaml or Haskell; however, how many commercial shops have more than a token programmer who might have a dusty tome of such arcane knowledge?

Different OSes, programming languages, methodologies, techniques for different problem domains.

Diversity is good. Monoculture will eventually come back to bite a company in the ass. Not every problem can be solved by GM Corn, right?

Re:Scheme rocks, but lost the race (1)

Darinbob (1142669) | about a year and a half ago | (#42959481)

Monoculture is pervasive. Sometimes it shows up just with all the currently popular language following the same old style with just minor variants in syntax. You get a batch of developers all used to Java or C++ or Python and so every new language they create just can't help but resemble that style. There just aren't that many programmers any more who have used languages that are radically different from that style, much less many programmers who are experts in those languages. We need more devs who are very familiar with Lisp, Prolog, Smalltalk, Forth, and so on, languages that fundamentally change how you think about programs.

Some profs back in school used to have an insult they'd use; "he can write a Fortran program in any language."

Re:Scheme rocks, but lost the race (1)

WaywardGeek (1480513) | about a year and a half ago | (#42962601)

I'm just guessing that you and I are of a similar age (I'm 49). Ken McElvain said that Lisp ruined me. Even when coding in C, I program in Lisp. I love Prolog, and wrote a tiny version of it at one point. I never learned Smalltalk, and suspect I missed out on something huge, but I love Forth and of course had to write my own version. As for Fortran, my first programming job was in Fortran IV. Some of the most brilliant people I've ever known are physicists who continue to program in Fortran to this day, even if they're programming in C or some other language.

Re:Scheme rocks, but lost the race (1)

Darinbob (1142669) | about a year and a half ago | (#42959223)

I think TCL really broke things. I was used to ARexx when it came out and it was vastly simpler to embed than TCL, and TCL felt always like it wanted to be in control (the thing you accuse Guile of doing).

Re:Scheme rocks, but lost the race (1)

guacamole (24270) | about a year and a half ago | (#42961393)

Anyway, this is nice, but I don't personally see a significant future for Scheme.

Never say never.. Back in 2000 I thought JavaScript was just an insignificant programming language for adding simple dynamics to a web page, like drop down menus, validating input, etc, a web designer's tool, not a serious coders tool, and see how things have turned out. JS is probably now one of the hottest programming languages, despite all the drawbacks. Next, who could have imagined a Lisp dialect (Scala) running on top of Java virtual machine 10-15 years ago? Even if some form of Scheme does not ever become mainstream, I think there will be a niche for it here and there.

Re:Scheme rocks, but lost the race (1)

WaywardGeek (1480513) | about a year and a half ago | (#42962629)

Scala is on the bubble for being a mainstream language. I'm personally very excited about it. I wouldn't call it a Lisp dialect... just highly lisp influenced. However, I'm totally ignorant of Scala's history. Lisp lives on in many languages.

Re:Scheme rocks, but lost the race (1)

guacamole (24270) | about a year and a half ago | (#42962785)

Duh, I just accidentally wrote Clojure instead of Scala. Those two somehow crossed in my mind, both being JVM languages, as I was writing this.

Rewrite it in Java Script (-1)

Anonymous Coward | about a year and a half ago | (#42955725)

kt.

Re:Rewrite it in Java Script (-1)

Anonymous Coward | about a year and a half ago | (#42955873)

But isn't Java Script the reason why everyone using the JVM plugin got hacked? Stop using insecure shit!

Re:Rewrite it in Java Script (0)

kthreadd (1558445) | about a year and a half ago | (#42956579)

Java, not JavaScript. They are completely different. Netscape just used the Java name since it was trendy back then.

Re:Rewrite it in Java Script (0)

Anonymous Coward | about a year and a half ago | (#42957087)

Good to see that my trollbait still works.

Scheme looks scary and unreadable to me (0)

Anonymous Coward | about a year and a half ago | (#42955835)

...is that just me? I don't consider myself particularly smart or educated but I can program in C as well as numerous scripting languages, and when I look at a strange new language I can usually sort of see what's going on, but when I look at Scheme I am just left completely bewilderd. Then again, I've never seriously attempted to learn the language so maybe this is one of those things that looks hard but simply isn't, once you get used to it.

Re:Scheme looks scary and unreadable to me (1)

ari_j (90255) | about a year and a half ago | (#42956167)

It's not just you, but your conclusion is correct: You just aren't used to it. Once you get used to it, Scheme (or any other modern Lisp) is a very easy language to write clean, effective code in.

Re:Scheme looks scary and unreadable to me (2)

TheLink (130905) | about a year and a half ago | (#42956665)

Once you get used to it, Scheme (or any other modern Lisp) is a very easy language to write clean, effective code in.

Scheme is great but the problem is I'm a crap programmer. So a language that helps with the code I write is not as important as a language that helps because of all the code that I DON'T have to write.

Basically I prefer to pick a language where there are already tons of existing good libraries/modules/code I can _easily_ use to do what I want. Stuff written by better programmers than me. That way the effective quality of my program goes up - since much of the functionality/code is actually written by someone else.

The other great thing is I don't normally have to support, document and fix that 3rd party code that I didn't write. ;)

Languages like scheme are great if most of the stuff you need to get done is stuff that is unlike anything else someone else has written. But for most of us that's not true.

Re:Scheme looks scary and unreadable to me (1)

UnknownSoldier (67820) | about a year and a half ago | (#42957011)

> Scheme is great but the problem is I'm a crap programmer.

Actually the first sign of a great programmer is realizing they are not great ! :-)

THE key point that everyone forgets: We were ALL noobs at one point. You don't really master a language until you've been using it for years.

> prefer to pick a language where there are already tons of existing good libraries/modules/code I can _easily_ use to do what I want.

Yup, that's very pragmatic. However, I would add, EVERY programmer should know how to or have at least once in their lifetime written atoi() and the corresponding dual itoa() aka, printf.

From a business point of view you want to use a 3rd party library that just works.
From a learning point of view you should write everything yourself (once.)

> I don't normally have to support, document and fix that 3rd party code that I didn't write. ;)

Part of the process of becoming a great programmer is to not only WRITE your code but READ other people's code. The sides of the same coin help each other.

I _love_ the consistency and simplicity of LISP but hate its syntax. Thankfully there is a solution! Readable S-expressions is for LISP programmers who love C style braces but hate LISP parenthesis.

http://www.dwheeler.com/readable/ [dwheeler.com]

(Ugly) S-expression

(define (fibfast n)
  (if (< n 2)
    n
    (fibup n 2 1 0)))
define fibfast(n) ; Typical function notation
  if {n < 2} ; Indentation, infix {...}
    n ; Single expr = no new list
    fibup(n 2 1 0) ; Simple function calls
(define (fibup max count n-1 n-2)
  (if (= max count)
    (+ n-1 n-2)
    (fibup max (+ count 1) (+ n-1 n-2) n-1)))

compare with Sweet-expression 0.2

define fibup(max count n-1 n-2)
  if {max = count}
    {n-1 + n-2}
    fibup max {count + 1} {n-1 + n-2} n-1
(define (factorial n)
  (if (<= n 1)
    1
    (* n (factorial (- n 1)))))
define factorial(n)
  if {n <= 1}
    1
    {n * factorial{n - 1}} ; f{...} => f({...})

and

http://www.dwheeler.com/readable/retort-lisp-can-be-readable.html [dwheeler.com]

"Even people like me, who have used Lisp for over 20 years, understand that it's a bug. I wrote my first Lisp program circa 1982, and professionally wrote Lisp code on $120,000 equipment. Lisp has advantages, which is why I used and use it.

But all the whining about it being "superficial" doesn't change the fact that most developers avoid Lisp-like languages, precisely because they're unreadable. There's a reason why Lisp is widely referred to as "Lots of Irritating Silly Parentheses" (and worse)."

--
The progression of a Lisp programmer:
* The newbie realizes that the difference between code and data is trivial.
* The expert realizes that all code is data.
* And the true master realizes that all data is code.
    -- Sriram Krishnan

Re:Scheme looks scary and unreadable to me (1)

UnknownSoldier (67820) | about a year and a half ago | (#42957199)

Addendum: All Lisp and C programmers should watch the video:

Readable Lisp S-expressions: Curly-infix-, Neoteric-, and Sweet-expressions
http://readable.sourceforge.net/ [sourceforge.net]

Re:Scheme looks scary and unreadable to me (1)

dkf (304284) | about a year and a half ago | (#42958277)

However, I would add, EVERY programmer should know how to or have at least once in their lifetime written atoi() and the corresponding dual itoa() aka, printf.

There's also the version for people who think they're smart: do the same for floating point numbers. (Experts only: use only the minimum number of digits when converting to a string.)

Re:Scheme looks scary and unreadable to me (1)

Darinbob (1142669) | about a year and a half ago | (#42959539)

Actually I never liked that style. I can learn a language inside and out and know it's nuances, but that is useless if it turns out the only thing that language is used for is to tie together building blocks that are pre-built by someone else. With a lot of environments it seems it's more useful to know the frameworks and libraries that the project is using than to know the language itself.

Re:Scheme looks scary and unreadable to me (1)

TheLink (130905) | about a year and a half ago | (#42962363)

That's because those frameworks and libraries are millions of lines of code and features you no longer have to write.

Imagine writing your own xml parsers, configuration file handlers, log handlers, high performance ACID databases, web servers, networking libraries, GUI libraries, "OpenGL", etc. Or even operating systems. Even if Scheme is ten times more concise, it'll take a lot of time to write it all yourself.

If learning to use the libraries/frameworks would take longer than to do what you want from scratch, don't use them. But if they are well documented (as good libraries are), then learning to use them would take a lot less time than writing the equivalent functionality from scratch. If you not going to need that functionality then you don't need to learn it - it's not part of the language.

And how many nuances does Scheme have? I thought the main point of stuff like Scheme is it's a simple language. Not like perl or C++. So even with Scheme you're going to be spending a lot more time learning the frameworks and libraries that you can use with Scheme than learning Scheme itself. Unless you're really trying to write most things from scratch. Or writing "Hello World".

You can in theory build a perfect house atom by atom. I prefer to use as much prefab as possible.

If I'm going to write a desktop app I don't want to have to rewrite something like Tk or Qt or OpenGL. Nor figure out how to write interfaces/wrappers to each of them from scratch.

Re:Scheme looks scary and unreadable to me (1)

jbolden (176878) | about a year and a half ago | (#42961693)

Clojure is a LISP that can use Java libraries.

I don't know if that helps but there finally is a LISP with a good modern set of libraries.

Re:Scheme looks scary and unreadable to me (0)

Anonymous Coward | about a year and a half ago | (#42962037)

Just when Oracle has their grimy paws on Java ;).

Should still help. Anyone using Clojure here?

Re:Scheme looks scary and unreadable to me (0)

Anonymous Coward | about a year and a half ago | (#42956873)

That's because Lisp is built around a different programming paradigm (functional programming). It needs a completely different way to think, but that's exactly what makes it worthwhile to learn. Google engineers obviously did, or they would not have come up with map-reduce. BTW, if you consider C++ template metaprogramming hard, you'll reconsider it after having learned Scheme (or Lisp, or Haskell, or any other functional language). Then you'll learn that the only hard thing about C++ template metaprogramming is the complicated syntax.

If I were in the hiring department and were to hire a programmer, I'd definitely prefer anyone who can credibly show knowledge of a functional programming language, even if the actual job doesn't require that. Doesn't matter, which one (even if it was Unlambda).

Re:Scheme looks scary and unreadable to me (1)

tibit (1762298) | about a year and a half ago | (#42958925)

Huh what lisp functional programming whaa...?! LISP is as imperative as it gets. The key feature of LISP is that code is data. That way you can run complex things at compile time -- things that write code for you, generate tables, implement domain specific languages, etc. The functional features are an afterthought and not really in any way key to LISP's power. They are a commonplace in most languages these days. I mean, come on, once you have function pointers in C, you can directly emulate all of LISP's "functional" features save for ones that need to generate code at compilation time (or runtime, too). It's not like qsort(...., int (*cmp)(const void *, const void*)) is not possible in C, you know. Lambda is very nice syntactic sugar, but not impossible to live without. Same goes for continuations: it's possible all right to have continuations in C and C++, just that you have to make to continuation state explicit in a data structure. Heck, it's even possible to have full-fledged coroutines in C -- again, you have to code for it, and it doesn't look pretty, but it's not technically impossible. No stack switching hacks needed. Of course if you want to run arbitrary C, you need stack switching :)

The template metaprogramming in C++ is a completely unnecessary crutch. It's there only because nobody had the balls to have full-featured compile time code execution in C++. Once you have that, you can write things in a much easier to interpret way using simple imperative style. C++ is, at heart, an imperative language. The fact that you need a functional-style language added to it just in order to work around a reasonably simple deficiency is quite telling. C++ basically requires you to learn two languages that have nothing in common, that use completely different idioms, etc.

Just look at how much trouble there is making the C++ metaprograms actually execute decently in the compiler: now a C++ compiler is not merely a compiler, but also a functional programming runtime / virtual machine! Those things are hard to make to run well -- just look at how long it took Haskell people to get something semi-useful. Adding template functionality that allows metaprogramming to C++ suddenly doubled or tripled the effort required to implement a C++ front-end. Whoever thought it a good idea should be shot.

What would have been the problem to simply let C and C++ compilers run code that is declared as a macro, just like LISP does it? This would have solved everything one uses templates for. A C/C++ host-targeting compiler shouldn't have any problems in extracting the macros, compiling them and running them -- and then consuming their output.

Instead of doing the simple thing, and leveraging the skills of imperative mindset already needed to be an effective C/C++ developer, the C++ language designers have implemented a limited, hard to implement and hard to use functional programming crutch that effectively doubles the requirements placed on the end user. Never mind the poor sods who implement the C++ front end and have to take constant flak from folks who actually want to use the damn feature without having to endure hour-long compile times and multi-gigabyte compiler resident sets just to get through a 10-line metaprogram. Give me a fucking break. Most of boost's metaprogramming stuff is there to basically say: hey, if it really worked here's how it'd look. Then you try to actually use it, and you run into the silly compiler-imposed limitations quicker than it takes to read this sentence. Large scale template metaprogramming is, essentially, completely impossible. About the only thing it's good for in practice are eigen-style libraries. Everything else it promises is summarily non-delivered. It's not funny.

Scheme is a functional programming language (1)

dwheeler (321049) | about a year and a half ago | (#42959367)

Scheme is normally considered a functional programming language. The 1989 paper "Conception, Evolution, and Application of Functional Programming Languages" by Paul Hudak defines functional programming languages as languages "in which computation is carried out entirely through the evaluation of expressions" (as opposed to setting mutable states, like variables, or allowing routines with side-effects). That paper specifically identifies Lisps (including Scheme) as languages that can be used as functional programming languages, as well as ML and Haskell. Like ML, Scheme provides mechanisms that let you "escape" outside the functional programming paradigm, but "well-written code" normally doesn't do that.

Re:Scheme is a functional programming language (1)

tibit (1762298) | about a year and a half ago | (#42961395)

It may be well-written code, but given that it's only quite recently that we have garbage collectors that can cope with pure-functional-style memory pressures, nobody in practice writes large LISP projects in functional style -- at least not projects that are not very recent. I can't wait for LuaJIT's new garbage collector to be done -- if it could be then "reshaped" to serve a LISP system like SBCL, it'd be a major win IMHO.

Re:Scheme looks scary and unreadable to me (1)

guacamole (24270) | about a year and a half ago | (#42961289)

Huh what lisp functional programming whaa...?! LISP is as imperative as it gets.

Indeed. I think Scheme is closer to the functional ideal. It was designed to simplify the functional style programming while still giving you access to imperative features. One reason is proper tail recursive calls which are part of Scheme standards, which is not something Lisps always give you.

Lambda is very nice syntactic sugar, but not impossible to live without. Same goes for continuations: it's possible all right to have continuations in C and C++, just that you have to make to continuation state explicit in a data structure. Heck, it's even possible to have full-fledged coroutines in C -- again, you have to code for it, and it doesn't look pretty, but it's not technically impossible.

Everything is pretty much syntactic sugar for this or that. So why don't we all just code in C and be done with it?

Re:Scheme looks scary and unreadable to me (1)

tibit (1762298) | about a year and a half ago | (#42961425)

What I'm merely saying is that functional programming is more a matter of what the developer does, rather than what the language offers. Sure as heck I detest anything where the code is far flung from what is meant, so no, I do not advocate using plain C :)

Re:Scheme looks scary and unreadable to me (1)

guacamole (24270) | about a year and a half ago | (#42961421)

This is because C, C++, Perl, Java, C#, etc, even Python are implementing many of the same paradigms. They all descend from C. Lisp and Scheme are completely different from those. Lisps are the oldest high level programming languages. They have been around since 50-60s. No wonder they look different. Nonetheless, Scheme has one of the simplex syntax rules ever. It's just dead simple and unambiguous. For example, there is no operator precedence. You can write a Scheme interpreter in 100-200 lines of code in a high level language (and this is without using any sort of parser library or external parser program).

Lame joke alert! (1)

Anonymous Coward | about a year and a half ago | (#42955977)

I guess Guile Scheme...
(puts on sunglasses)
does go with everything.

Copyfree alternatives (0)

Anonymous Coward | about a year and a half ago | (#42956369)

Copyleft-only languages have no chance, particularly among languages intended to be embedded in applications. Permissively licensed [copyfree.org] alternatives to Guile among Scheme implementations seem to include: Gauche [wikipedia.org] , Ypsilon [wikipedia.org] , TinyScheme [wikipedia.org] , Scheme 48 [wikipedia.org] , Owl [wikipedia.org] , and the SCheme SHell (scsh) [wikipedia.org] .

And of course Scheme itself is dwarfed, in terms of both popularity [tiobe.com] and performance [debian.org] by other languages. Haskell seems to be the best overall functional language at the moment, and, when choosing a scripting / macro-language without a commitment to functional languages, better alternatives would be Lua (made faster than Scheme by LuaJIT), JavaScript / CoffeeScript (V8), and Ruby (Topaz).

--libman

Re:Copyfree alternatives (0)

Anonymous Coward | about a year and a half ago | (#42957163)

Why consider Ruby (Topaz)? I understand and agree with the Ruby part but why hobble it with Topaz? Ruby running on top of Python on top of PyPy doesn't look all that efficient or fast. Especially when you give up parallelization. I think Ruby (JRuby) would be a better alternative.

Re:Copyfree alternatives (0)

Anonymous Coward | about a year and a half ago | (#42961951)

The intention of Topaz [topazruby.com] is to be the fastest Ruby implementation [infoworld.com] . With Just-In-Time code generation, a high-level language can be quite fast. (V8 uses about 3x as much CPU as C on average, but some operations can be optimized at run-time to be just as fast as C). I was just making a point that some vastly more popular dynamically-types scripting languages can also be faster than Scheme - so why would anyone want to use Scheme?

PS: in my list of copyfree Scheme implementations above, I forgot the most important one - Chicken [wikipedia.org] (and possibly some others).

--libman

Re:Copyfree alternatives (1)

pjabardo (977600) | about a year and a half ago | (#42959793)

Racket is the scheme implementation on the language shootout you linked. Only two dynamically typed languages are faster: javascript and Common Lisp (SBCL) (which is faster than javascript). This makes scheme pretty good and SBCL is lisp after all. I don't know about LuaJIT

Re:Copyfree alternatives (0)

Anonymous Coward | about a year and a half ago | (#42962169)

That benchmark uses non-JIT implementations of all dynamic languages except JavaScript V8. LuaJIT is much faster than regular Lua [luajit.org] , and I've been told that it's even faster than V8. So, thanks to Lua and JS, the performance argument for using Scheme as a scripting language is no longer valid.

Also note that Racket is almost 2x as verbose [debian.org] (and Lisp 3x as verbose) as other scripting languages! That, combined with its relative obscurity and the fact that many (most?) programmers don't have any experience with functional languages, makes it an extremely poor choice for an embedded scripting language.

--libman

"has become a pleasant foundation for its users" (0)

Anonymous Coward | about a year and a half ago | (#42958343)

Guile 2 was a major upgrade to Guile's performance and expressiveness as a language, and has become a pleasant foundation for its users.

Who are its users? The Guile homepage states:

Successful and long-lived examples of Free Software projects that use Guile are TeXmacs, LilyPond, and GnuCash.

How many of those are using Guile 2 yet? Zero as far as I can tell.

TeXmacs lists on its todo page [texmacs.org] : "Internally present Guile as a plug-in, which could later be replaced by another Scheme implementation."

Re:"has become a pleasant foundation for its users (1)

guacamole (24270) | about a year and a half ago | (#42961505)

How many of those are using Guile 2 yet? Zero as far as I can tell.

To be fair, Guile 2 is a huge upgrade from Guile 1. Internal are completely different. Such transitions will take a long time. It's fair to assume that some will never switch from Guile 1. Not every application needs an uber advanced and fast extension language like Guile 2 (and it is very fast IMO, as far as scripting languages go).

Re:"has become a pleasant foundation for its users (1)

Unknown Lamer (78415) | about a year and a half ago | (#42962539)

The main impediment to adoption I think was barely missing the Debian Squeeze and the last set of distro releases... but it made it into Wheezy and I think is in every other major distro's latest/upcoming release.

The perils of distro release cycles...

Re:"has become a pleasant foundation for its users (0)

Anonymous Coward | about a year and a half ago | (#42964987)

> The main impediment to adoption I think was barely missing the Debian Squeeze

Nobody is preventing the Guile people to offer prebuilt packages for the 3-4 most popular distros.

"Want to try out new release? Just download and click this deb, and there you go!"

You dont have to wait for distros to do that work for you. Of course, you can, but then you cannot whine if you are not on top of their priority list.

> The perils of distro release cycles...

Sounds like an whiney excuse to me. "We would have taken over the world by now if only distro X had shipped us more timely."

The problem with Guile is bootstrapping. Nobody uses it because nobody uses it, and since nobody uses it, nobody writes libraries for it, so nobody uses it.

The way to get around the bootstrapping problem is "easy": Write a killer app and make Guile an integral part of it. Inject Guile into one of the already popular apps, Emacs, GDB, Texinfo, etc. It is your responsibility to somehow amass a critical mass. If you try it directly, i.e. just by advertising Guile _itself_, it wont work. Just do what Javascript did, attach yourself onto something important.

Re:"has become a pleasant foundation for its users (0)

Anonymous Coward | about a year and a half ago | (#42963829)

How many of those are using Guile 2 yet? Zero as far as I can tell.

To be fair, Guile 2 is a huge upgrade from Guile 1. Internal are completely different.

Yes, that's the point. It has not become a pleasant foundation for its users. It may or may not have become a pleasant foundation for applications that have not yet used it. But there is no large project using GUILE 2 as an extension language. It is not really useful for that any more.

People are using GUILE 2 as a standalone language. Which is nice, but not what it is being marketed for. They left their niche and their marketed users behind in order to compete with full Scheme implementations instead. But that's not where they were somewhat competitive and successful.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>