6 ms·

GNU Guile beta 2.1.3 released

102 points by weeber 10y ago

zvrba 10y ago
Is it just me who has the impression that Python "won" as a glue and application extension language?
- electroly 10y ago
  Lua did. Python isn't commonly used in situations where you'd consider embedding Guile.
  - zvrba 10y ago
    > Python isn't commonly used in situations where you'd consider embedding Guile. Which situations would that be?
    - nobody16 10y ago
      Application configuration. Code is data, data is code.
    - dman 10y ago
      Multiple interpreters in the same process.
    - electroly 10y ago
      Shipping it inside a larger application, like in games, as a lightweight script language. Guile and Lua are both purpose-built to be embeddable libraries rather than intended for standalone execution. It's certainly possible to embed Python (anything is possible!) but it's a minority use case and not as well-supported by the tooling.
    - snaky 10y ago
      When you need script language to embed it inside NetBSD kernel http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current
- PeCaN 10y ago
  Yes, I think it is. Lua "won" in games, Tcl won in electrical engineering software, Lisp won in various niche places, JavaScript won basically everywhere else. Python does not seem a very popular glue language outside of Sublime Text.
  - coldtea 10y ago
    Errr, what? Python is the clear winner in the scientific computing space.
    - nalaginrut 10y ago
      That seems not as glue code, although I agree Python win in preliminary scientific computing.
    - PeCaN 10y ago
      That… isn't an "application extension language" use case. I guess if you count wrapping various C and Fortran libraries it's a "glue" language, but that's not exactly what I was getting at.
      - dalke 10y ago
        It's a popular extension language for molecular visualization applications.
      - coldtea 10y ago
        "Glue code" is not just (or particularly) about "application extension" (e.g. as embedded Lua in game engines). Traditional "glue" has been called any language that connects between different programs and systems (e.g. take data out of system X as CSV, preprocess them, input them it program Y, do something with the results etc. Which Python is used for a lot, in the scientific (physics and biology at least) communities. And yes, wrapping C, fortran etc libs too.
    - 59nadir 10y ago
      The thread was specifically about usage as a glue and extension language.
- davexunit 10y ago
  Sure, but keep in mind that Guile is also a general-purpose programming language and a virtual machine for running languages beyond Scheme, such as Emacs Lisp. I do web, game, and systems programming with Guile and it does a good job at all of them.
- deleted 10y ago
  [deleted]
ianleeclark 10y ago
"The new internals will eventually allow for user-space tasklets or green threads that suspend to a scheduler when they would cause blocking I/O, allowing users to write straightforward network services that parse their input and send their output as if it were blocking, while under the hood Guile can multiplex many active connections at once." Green threads in the future sounds really interesting. I've never touched scheme (only dabbled in Clojure), but I've always wanted to get a Lisp under my belt. Maybe Guile will be the one, but the biggest issue for me in choosing a Lisp is the sheer amount. It's hard to know the true tradeoffs between different implementations, so maybe I should just go with Common Lisp
- PeCaN 10y ago
  If you actually want to develop applications you should probably stick to Common Lisp. SBCL and ClozureCL are extremely high-quality implementations and Common Lisp generally has the most libraries. It's probably the worst Lisp from a design standpoint, but the best from a practical one. Racket seems interesting in that regard however. If you want to embed a Lisp in a larger application, Guile is definitely good with an easy API and high-quality implementation.
  - ianleeclark 10y ago
    Embedding Guile does sound interesting, but the problem is I don't have any use-cases. I have looked into SBCL before, so I may check it out. Chicken Lisp seems nice with its packaging system, but at the same time, that's the only experience I've had with it. I'll probably end up going with SBCL; I have seen it recommended many, many times for beginners wanting to use lisp.
    - davexunit 10y ago
      Guile programmer here. I highly recommend extending Guile rather than embedding it within another program. For example, the GNU Guix package manager provides a suite of tools, but it's also a collection of Guile modules so that other programs can use it as a library. I know quite a few SBCL users now from the Lisp games community, so if you are enticed by CLOS and such then that also seems like a fine road to travel down. Good luck on your Lisp journey!
rsfinn 10y ago
TIL: In the year 2016, twenty-two years after the publication of "The UNIX-HATERS Handbook"[1], sendmail still finds it necessary, upon discovering the word "from" at the beginning of a line in the body of a mail message, to replace it with the string ">From". [1] http://web.mit.edu/~simsong/www/ugh.pdf http://web.mit.edu/~simsong/www/ugh.pdf
- davexunit 10y ago
  I was wondering what was up with that. Thanks for the history lesson.
- jjnoakes 10y ago
  The real bug is not the replacement (the quoting), but the failure to reverse it (unquote) at the proper times. (The From to >From quoting design itself can be argued to be a poor decision, but that is orthogonal to the issue of why >From appears in random places. If the unquoting was done properly by all systems involved, there would be no >From in the wild).
  - mwcampbell 10y ago
    The global complexity would be lower if the mbox format, which IIUC is what makes that quoting necessary, would just die already. We've only had Maildir for about 20 years now.
    - jjnoakes 10y ago
      Maybe, maybe not. There's quoting everywhere. EVERYWHERE. Doing it wrong is the source of some extremely damaging exploits (SQL injection, shell command injection, XSS, ...). Fixing From and >From is but a drop in the bucket.
samwestdev 10y ago
SONIC BOOM

102 points by weeber 10y ago

zvrba 10y ago

Is it just me who has the impression that Python "won" as a glue and application extension language?

electroly 10y ago
Lua did. Python isn't commonly used in situations where you'd consider embedding Guile.
- zvrba 10y ago
  > Python isn't commonly used in situations where you'd consider embedding Guile. Which situations would that be?
  - nobody16 10y ago
    Application configuration. Code is data, data is code.
  - dman 10y ago
    Multiple interpreters in the same process.
  - electroly 10y ago
    Shipping it inside a larger application, like in games, as a lightweight script language. Guile and Lua are both purpose-built to be embeddable libraries rather than intended for standalone execution. It's certainly possible to embed Python (anything is possible!) but it's a minority use case and not as well-supported by the tooling.
  - snaky 10y ago
    When you need script language to embed it inside NetBSD kernel http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current
PeCaN 10y ago
Yes, I think it is. Lua "won" in games, Tcl won in electrical engineering software, Lisp won in various niche places, JavaScript won basically everywhere else. Python does not seem a very popular glue language outside of Sublime Text.
- coldtea 10y ago
  Errr, what? Python is the clear winner in the scientific computing space.
  - nalaginrut 10y ago
    That seems not as glue code, although I agree Python win in preliminary scientific computing.
  - PeCaN 10y ago
    That… isn't an "application extension language" use case. I guess if you count wrapping various C and Fortran libraries it's a "glue" language, but that's not exactly what I was getting at.
    - dalke 10y ago
      It's a popular extension language for molecular visualization applications.
    - coldtea 10y ago
      "Glue code" is not just (or particularly) about "application extension" (e.g. as embedded Lua in game engines). Traditional "glue" has been called any language that connects between different programs and systems (e.g. take data out of system X as CSV, preprocess them, input them it program Y, do something with the results etc. Which Python is used for a lot, in the scientific (physics and biology at least) communities. And yes, wrapping C, fortran etc libs too.
  - 59nadir 10y ago
    The thread was specifically about usage as a glue and extension language.
davexunit 10y ago
Sure, but keep in mind that Guile is also a general-purpose programming language and a virtual machine for running languages beyond Scheme, such as Emacs Lisp. I do web, game, and systems programming with Guile and it does a good job at all of them.
deleted 10y ago
[deleted]

ianleeclark 10y ago

"The new internals will eventually allow for user-space tasklets or green threads that suspend to a scheduler when they would cause blocking I/O, allowing users to write straightforward network services that parse their input and send their output as if it were blocking, while under the hood Guile can multiplex many active connections at once." Green threads in the future sounds really interesting. I've never touched scheme (only dabbled in Clojure), but I've always wanted to get a Lisp under my belt. Maybe Guile will be the one, but the biggest issue for me in choosing a Lisp is the sheer amount. It's hard to know the true tradeoffs between different implementations, so maybe I should just go with Common Lisp

PeCaN 10y ago
If you actually want to develop applications you should probably stick to Common Lisp. SBCL and ClozureCL are extremely high-quality implementations and Common Lisp generally has the most libraries. It's probably the worst Lisp from a design standpoint, but the best from a practical one. Racket seems interesting in that regard however. If you want to embed a Lisp in a larger application, Guile is definitely good with an easy API and high-quality implementation.
- ianleeclark 10y ago
  Embedding Guile does sound interesting, but the problem is I don't have any use-cases. I have looked into SBCL before, so I may check it out. Chicken Lisp seems nice with its packaging system, but at the same time, that's the only experience I've had with it. I'll probably end up going with SBCL; I have seen it recommended many, many times for beginners wanting to use lisp.
  - davexunit 10y ago
    Guile programmer here. I highly recommend extending Guile rather than embedding it within another program. For example, the GNU Guix package manager provides a suite of tools, but it's also a collection of Guile modules so that other programs can use it as a library. I know quite a few SBCL users now from the Lisp games community, so if you are enticed by CLOS and such then that also seems like a fine road to travel down. Good luck on your Lisp journey!

rsfinn 10y ago

TIL: In the year 2016, twenty-two years after the publication of "The UNIX-HATERS Handbook"[1], sendmail still finds it necessary, upon discovering the word "from" at the beginning of a line in the body of a mail message, to replace it with the string ">From". [1] http://web.mit.edu/~simsong/www/ugh.pdf http://web.mit.edu/~simsong/www/ugh.pdf

davexunit 10y ago
I was wondering what was up with that. Thanks for the history lesson.
jjnoakes 10y ago
The real bug is not the replacement (the quoting), but the failure to reverse it (unquote) at the proper times. (The From to >From quoting design itself can be argued to be a poor decision, but that is orthogonal to the issue of why >From appears in random places. If the unquoting was done properly by all systems involved, there would be no >From in the wild).
- mwcampbell 10y ago
  The global complexity would be lower if the mbox format, which IIUC is what makes that quoting necessary, would just die already. We've only had Maildir for about 20 years now.
  - jjnoakes 10y ago
    Maybe, maybe not. There's quoting everywhere. EVERYWHERE. Doing it wrong is the source of some extremely damaging exploits (SQL injection, shell command injection, XSS, ...). Fixing From and >From is but a drop in the bucket.

samwestdev 10y ago

SONIC BOOM