Two Years of GNU Guile Scheme 2.0

Dumb by Anonymous Coward · 2013-02-20 03:21 · Score: 0, Interesting

Sounds stupid and pointless. *golf clap*

Guile supports curly-infix, too! by dwheeler · 2013-02-20 03:27 · Score: 4, Interesting

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

--
- David A. Wheeler (see my Secure Programming HOWTO)

Re:Guile supports curly-infix, too! by Anonymous Coward · 2013-02-20 03:38 · Score: 2, Insightful

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! by Anonymous Coward · 2013-02-20 03:48 · Score: 0

How is reverse polish notation hard to read unless you have a sub-average intelligence?
Re:Guile supports curly-infix, too! by cduffy · 2013-02-20 03:52 · Score: 3, Insightful

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! by Anonymous Coward · 2013-02-20 03:59 · Score: 0

This SRFI is in ``final'' status.
What kind of clown types quotation marks like that?
Re:Guile supports curly-infix, too! by Anonymous Coward · 2013-02-20 04:00 · Score: 1

(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! by Anonymous Coward · 2013-02-20 04:15 · Score: 0

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).
Re:Guile supports curly-infix, too! by TaylanUB · 2013-02-20 04:44 · Score: 1

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! by Anonymous Coward · 2013-02-20 05:12 · Score: 0

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! by semios · 2013-02-20 05:13 · Score: 1

{{(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! by Anonymous Coward · 2013-02-20 05:15 · Score: 0

Notation polish reverse read to hard is Yoda I am not because.
Re:Guile supports curly-infix, too! by Hentes · 2013-02-20 05:21 · Score: 1

As long as the braces are implemented with a macro, that's not a problem.
Re:Guile supports curly-infix, too! by larry+bagina · 2013-02-20 05:58 · Score: 2

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.

--
Do you even lift?
These aren't the 'roids you're looking for.
Re:Guile supports curly-infix, too! by rmstar · 2013-02-20 06:11 · Score: 2

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! by Anonymous Coward · 2013-02-20 06:30 · Score: 0

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! by Anonymous Coward · 2013-02-20 06:33 · Score: 0

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! by Anonymous Coward · 2013-02-20 07:30 · Score: 0

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! by Anonymous Coward · 2013-02-20 07:37 · Score: 0

(or (* . (2 . ((+ . (a . (b . ())) . ()))))
fixed that for ya...
Re:Guile supports curly-infix, too! by tibit · 2013-02-20 08:19 · Score: 1

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

--
A successful API design takes a mixture of software design and pedagogy.
Re:Guile supports curly-infix, too! by Darinbob · 2013-02-20 08:59 · Score: 1

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.
Re:Guile supports curly-infix, too! by dwheeler · 2013-02-20 09:16 · Score: 1

"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.

--
- David A. Wheeler (see my Secure Programming HOWTO)
Re:Guile supports curly-infix, too! by jbolden · 2013-02-20 13:40 · Score: 1

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.

Emacs and Guile need each other by Anonymous Coward · 2013-02-20 03:28 · Score: 3, Interesting

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 by Unknown+Lamer · 2013-02-20 03:36 · Score: 4, Informative

It's close to being reality. 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%!

--

HAL 7000, fewer features than the HAL 9000, but just as homicidal!
Re:Emacs and Guile need each other by Darinbob · 2013-02-20 09:29 · Score: 1

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 by guacamole · 2013-02-20 12:42 · Score: 1

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)It's also worth learning simply because one of the best CS books, the SICP, 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 by jbolden · 2013-02-20 13:45 · Score: 1

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 by Unknown+Lamer · 2013-02-20 15:47 · Score: 1

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).

--

HAL 7000, fewer features than the HAL 9000, but just as homicidal!
Re:Emacs and Guile need each other by jbolden · 2013-02-20 16:19 · Score: 1

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/ for Haskell an hope.
Re:Emacs and Guile need each other by muuh-gnu · 2013-02-20 19:11 · Score: 1

> 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.
Re:Emacs and Guile need each other by Unknown+Lamer · 2013-02-21 07:13 · Score: 1

Guile has fluids, which give you similar behavior as dynamic scoping without forcing the costs of dynamic scoping on all code. Emacs Lisp actually has optional lexical scope now, and a lot of stuff is converting to use it because it's proven to reduce code errors and runtime overhead. That, and you can't use dynamically scoped bindings to pass information between threads (a serious limitation in Emacs's implementation).
Obviously, fluids have their place in something like Emacs where the cost of breaking abstraction is lower than the incredible pain in the ass it'd be to not have them for customizing things.

--

HAL 7000, fewer features than the HAL 9000, but just as homicidal!
Re:Emacs and Guile need each other by Darinbob · 2013-02-21 07:32 · Score: 1

So Guile isn't as tiny a scheme as the stereotype. There used to be two ends of the spectrum; pure simple scheme that's trimmed down versus all-the-features Common Lisp (which has special variables).

Scheme rocks, but lost the race by WaywardGeek · 2013-02-20 03:31 · Score: 2

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.

--
Celebrate failure, and then learn from it - Nolan Bushnell

Re:Scheme rocks, but lost the race by Anonymous Coward · 2013-02-20 04:53 · Score: 0

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 by Anonymous Coward · 2013-02-20 05:06 · Score: 1

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 by dkf · 2013-02-20 07:57 · Score: 1

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?

--
"Little does he know, but there is no 'I' in 'Idiot'!"
Re:Scheme rocks, but lost the race by Darinbob · 2013-02-20 09:34 · Score: 1

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 by Darinbob · 2013-02-20 09:43 · Score: 1

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 by Darinbob · 2013-02-20 09:51 · Score: 1

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 by guacamole · 2013-02-20 13:06 · Score: 1

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 by jbolden · 2013-02-20 13:46 · Score: 1

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 by WaywardGeek · 2013-02-20 15:52 · Score: 2

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

--
Celebrate failure, and then learn from it - Nolan Bushnell
Re:Scheme rocks, but lost the race by WaywardGeek · 2013-02-20 16:00 · Score: 1

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.

--
Celebrate failure, and then learn from it - Nolan Bushnell
Re:Scheme rocks, but lost the race by WaywardGeek · 2013-02-20 16:05 · Score: 1

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.

--
Celebrate failure, and then learn from it - Nolan Bushnell
Re:Scheme rocks, but lost the race by guacamole · 2013-02-20 16:31 · Score: 1

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.
Re:Scheme rocks, but lost the race by jbolden · 2013-02-20 16:33 · Score: 1

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.

Scheme looks scary and unreadable to me by Anonymous Coward · 2013-02-20 03:42 · Score: 0

...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 by elfprince13 · 2013-02-20 04:04 · Score: 1

So what you're saying is, you're in the "Hokey recursion-relations and ancient parentheses are no match for a good regex at your side" crowd?
Re:Scheme looks scary and unreadable to me by ari_j · 2013-02-20 04:22 · Score: 1

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 by TheLink · 2013-02-20 05:17 · Score: 2

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.
--
- Too many replies beneath your current threshold
Re:Scheme looks scary and unreadable to me by Anonymous Coward · 2013-02-20 05:38 · Score: 0

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 by UnknownSoldier · 2013-02-20 05:53 · Score: 1

> 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/
(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

"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 by UnknownSoldier · 2013-02-20 06:23 · Score: 1

Addendum: All Lisp and C programmers should watch the video:
Readable Lisp S-expressions: Curly-infix-, Neoteric-, and Sweet-expressions
http://readable.sourceforge.net/
Re:Scheme looks scary and unreadable to me by dkf · 2013-02-20 08:04 · Score: 1

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.)

--
"Little does he know, but there is no 'I' in 'Idiot'!"
Re:Scheme looks scary and unreadable to me by tibit · 2013-02-20 09:12 · Score: 1

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.

--
A successful API design takes a mixture of software design and pedagogy.
Re:Scheme looks scary and unreadable to me by Darinbob · 2013-02-20 09:55 · Score: 1

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 by guacamole · 2013-02-20 12:52 · Score: 1

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 by guacamole · 2013-02-20 13:10 · Score: 1

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).
Re:Scheme looks scary and unreadable to me by tibit · 2013-02-20 13:10 · Score: 1

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 :)

--
A successful API design takes a mixture of software design and pedagogy.
Re:Scheme looks scary and unreadable to me by jbolden · 2013-02-20 13:49 · Score: 1

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 by Anonymous Coward · 2013-02-20 14:41 · Score: 0

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

Should still help. Anyone using Clojure here?
Re:Scheme looks scary and unreadable to me by jbolden · 2013-02-20 14:50 · Score: 1

It is popular. You can find stuff all over the web.
And there are books: http://www.amazon.com/s/ref=nb_sb_noss_1?url=search-alias%3Daps&field-keywords=clojure
Re:Scheme looks scary and unreadable to me by TheLink · 2013-02-20 15:26 · Score: 1

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.
--
- Too many replies beneath your current threshold

RPN is scarey! by Anonymous Coward · 2013-02-20 03:44 · Score: 1

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

Re:RPN is scarey! by usmcpanzer · 2013-02-20 04:40 · Score: 1

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! by Anonymous Coward · 2013-02-20 06:12 · Score: 0

not sure whether your comment is sarcasm (HP dominates the market), off topic (RPN?) or trolling (well done?).
Re:RPN is scarey! by Anonymous Coward · 2013-02-20 08:11 · Score: 0

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

Lame joke alert! by Anonymous Coward · 2013-02-20 03:57 · Score: 1

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

Re:scheme, bitches! by Anonymous Coward · 2013-02-20 04:03 · Score: 3, Informative

Perl is dead

Only in my happiest, wildest, wettest dreams.

Copyfree alternatives by Anonymous Coward · 2013-02-20 04:49 · Score: 0

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

And of course Scheme itself is dwarfed, in terms of both popularity and performance 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 by Anonymous Coward · 2013-02-20 06:18 · Score: 0

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 by pjabardo · 2013-02-20 10:15 · Score: 1

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 by Anonymous Coward · 2013-02-20 14:26 · Score: 0

The intention of Topaz is to be the fastest Ruby implementation. 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 (and possibly some others).
--libman
Re:Copyfree alternatives by Anonymous Coward · 2013-02-20 14:59 · Score: 0

That benchmark uses non-JIT implementations of all dynamic languages except JavaScript V8. LuaJIT is much faster than regular Lua, 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 (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

Curly-infix-expressions are just abbreviations by dwheeler · 2013-02-20 04:59 · Score: 2

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/ for more info, and in particular, please join the mailing list!!

--
- David A. Wheeler (see my Secure Programming HOWTO)

Re:Curly-infix-expressions are just abbreviations by Anonymous Coward · 2013-02-20 06:09 · Score: 1

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).

Re:Rewrite it in Java Script by kthreadd · 2013-02-20 05:09 · Score: 0

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 by Anonymous Coward · 2013-02-20 06:10 · Score: 0

Good to see that my trollbait still works.

Re:scheme, bitches! by ryanisinallofus · 2013-02-20 06:14 · Score: 0

You need to dream wilder, wetter.

Spaces vs. tabs by dwheeler · 2013-02-20 06:14 · Score: 2

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.

--
- David A. Wheeler (see my Secure Programming HOWTO)

Re:Spaces vs. tabs by Anonymous Coward · 2013-02-20 07:23 · Score: 0

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 by Urkki · 2013-02-20 07:37 · Score: 1

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 by Anonymous Coward · 2013-02-20 07:51 · Score: 0

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 by maxwell+demon · 2013-02-20 08:58 · Score: 1

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?

--
The Tao of math: The numbers you can count are not the real numbers.
Re:Spaces vs. tabs by dwheeler · 2013-02-20 09:01 · Score: 1

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.

--
- David A. Wheeler (see my Secure Programming HOWTO)
Re:Spaces vs. tabs by Darinbob · 2013-02-20 09:08 · Score: 1

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 by Darinbob · 2013-02-20 09:11 · Score: 1

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 by dwheeler · 2013-02-20 09:49 · Score: 1

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.

--
- David A. Wheeler (see my Secure Programming HOWTO)
Re:Spaces vs. tabs by goose-incarnated · 2013-02-20 20:11 · Score: 1

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.

--
I'm a minority race. Save your vitriol for white people.
Re:Spaces vs. tabs by Urkki · 2013-02-21 01:47 · Score: 1

.
Python accepts either spaces or tabs, specifically because you can't get agreement on one or the other. The same argument applies here, too.
Indeed, but doing something which is basically "worst of both worlds" is neither simple nor all that sensible, no matter the reason. Fortunately practical impact is quite minor, at worst it costs a bit more work from people who have plenty of free time for such fun things anyway, when submitting or merging patches with different indentation conventions, and when tweaking editor settings back and forth.
Re:Spaces vs. tabs by Anonymous Coward · 2013-02-21 03:10 · Score: 0

How is that a big problem? If the second, third, etc., person to touch the file tries switching it from tabs to spaces or visa versa, they will get an error when they try to run the code in the file. Yeah, that means they would have to work with whatever style guidelines the file was originally in (or convert it if desperate, which is easy enough). If the complaint is it forces coders to go a specific way, how is that any different from the language forcing coders to go one way or the other? If the complaint is they can submit broken code... how is that different than any other language feature?
Re:Spaces vs. tabs by Raenex · 2013-02-22 04:22 · Score: 1

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.
Speaking from experience on development teams, this still leads to problems when you have to look at the code and your editor treats the tabs differently. Allowing mixing of tabs and spaces is a really horrible idea.

"has become a pleasant foundation for its users" by Anonymous Coward · 2013-02-20 08:11 · Score: 0

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: "Internally present Guile as a plug-in, which could later be replaced by another Scheme implementation."

Scheme is a functional programming language by dwheeler · 2013-02-20 09:44 · Score: 1

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.

--
- David A. Wheeler (see my Secure Programming HOWTO)

Re:Scheme is a functional programming language by tibit · 2013-02-20 13:07 · Score: 1

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.

--
A successful API design takes a mixture of software design and pedagogy.

Braces are implemented in the reader by dwheeler · 2013-02-20 09:54 · Score: 1

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.

--
- David A. Wheeler (see my Secure Programming HOWTO)

Re:"has become a pleasant foundation for its users by guacamole · 2013-02-20 13:22 · Score: 1

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 by Unknown+Lamer · 2013-02-20 15:51 · Score: 1

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...

--

HAL 7000, fewer features than the HAL 9000, but just as homicidal!

Re:"has become a pleasant foundation for its users by Anonymous Coward · 2013-02-20 19:08 · Score: 0

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.

Wet? by Anonymous Coward · 2013-02-20 22:49 · Score: 0

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

Sheesh.

Re:"has become a pleasant foundation for its users by Anonymous Coward · 2013-02-20 22:51 · Score: 0

> 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.

Scheme != Common Lisp by dwheeler · 2013-02-21 10:11 · Score: 1

Careful, I emphasized *Scheme* and not *Common Lisp*. All Schemes are *required* to be properly tail recursive, per spec, which combined with garbage collection completely deals with the pure-functional-style memory pressures properly. It's true that nobody in practice writes large (Common) Lisp projects in functional style, but Common Lisp doesn't guarantee proper tail recursion (and implementations don't typically provide it), so that should be unsurprising that you can't really scale that up in Common Lisp.

--
- David A. Wheeler (see my Secure Programming HOWTO)

Re:Scheme != Common Lisp by tibit · 2013-02-22 03:09 · Score: 1

Tail recursion is not the problem I refer to. Merely the amount of garbage generated just making copies of stuff is what's killing it. Even Oracle's Java deals with it relatively poorly -- thus the presence of hardware-assisted garbage collection (at a price tag that'll make you weep). Open source implementations generally don't really have garbage collectors that address the architectures of today's CPUs. They are definitely not optimized for cache pressure, and are simply wasteful in their resource use. Even garbage collectors from Frantz and Chez Scheme seem to be relatively unimpressive when you cachegrind them. Mike Pall rather detailed plans for new garbage collector for LuaJit are one of the first designs that I've seen where all those pesky architectural requirements are addressed face on.

--
A successful API design takes a mixture of software design and pedagogy.

Slashdot Mirror

Two Years of GNU Guile Scheme 2.0

107 comments