In this video, I'll give you 5 reasons why I think you should learn Scheme this year! Regardless if you are a programming beginner or an expert hacker, there is a lot to be gained from learning this language.
If you've got questions about Emacs, Guix, Guile, or other related topics and want a friendly place to ask them, come check out the new System Crafters Forum!
There’s a paid internship offer with the Greens in Brussels that needs #Guix and #Guile skills: https://www.greens-efa.eu/en/get-involved/work-with-us — I thought you may be interested. Deadline for application: 31 May, 23:59 CET — info about needed skills is from an email of a green elected: Internal toolchain development, debugging or maintenance, using Guile Scheme, Guix, PHP (Drupal / CiviCRM), bash, postgres, sqlite and similar technologies #job
One more reason why it's hard to use alists as associative data structure: There is no built-in destructuring capabilities for it. It seems (ice-9 match) is no help here. Situation becomes even worse if we have a nested data structure.
Going to stack a bunch of let+assoc-ref's I guess.
"Oh, cool. the guile-lib package has an asynchronous message queue! I can use that... Hmm, it seems there are a few different efforts on Akku to pull in a bunch of portable code into a single library. I had better bookmark these... oh, wow, Guile 3.0 has SRFI-171 (Transducers) built-in now! Amazing! I need to rewrite that algorithm I wrote last time to use Transducers... Oh wow, so when you parse XML you don't need to parse the whole structure into memory, you can use Oleg Kiselyov's SSAX framework and just supply callbacks that are triggered as each part of the tree is parsed, discarding the parts you don't need... so now how do you... oh, NOW I get it! So the (cond ((VALUE GUARD => LAMBDA))) syntax specified in SRFI-61 lets you test the value then applies it to a function if the test passes! So you can combine that with things like Transducers and SSAX to create super-advanced queries over various data structures... now this is starting to make sense..." (falls asleep at desk)
When @spritelyinst closes in on their work on #Guile's wasm compiler (maybe later this year?!), it'll certainly become the easiest way to target optimized #wasm. Tree-IL has gotta be the simplest intermediate language to compile to, and you get all the optimizations Guile offers for free.
Considering Robin Templeton, the author of Guile's #elisp compiler, is one of the engineers behind it, I can't help but speculate that this will put #emacs in the browser within reach. If I can handle my org-agenda online by 2025, I will cry.
It's called #Scheme because it allows just a few friends to plot a CONSpiracy to build amazing things.
Amicɜ, da qualche mese mi sto interessando alla famiglia di linguaggi Lisp/Scheme e, nel processo di ricerca, mi sono imbattuto e ho tradotto l'handbook di @jeko
È molto interessante, in continuo aggiornamento ed è orientato alla Test Driven Development.
Spero possa esservi utile!
Se trovate qualche errore o avete feedback sulla traduzione scrivetemi pure.
The best way to get all available stuff from textual port I found so far is:
(define (read-all-chars-as-string port)
(let loop ((chars '()))
(if (char-ready? port)
(loop (cons (read-char port) chars))
(reverse-list->string chars))))
The Scheme language's small size isn't necessarily a strength
So I was reading through part of the EmacsWiki and in the article on the Scheme programming language there are references to this ancient online debate from August of the year 2000 at the comp.lang.lisp Usenet group started by the late Erik Naggum, who was apparently a somewhat opinionated and inflammatory individual, who brought up the Scheme/Common Lisp debate on comment thread about someone being confused about how the CASE clause works.
The Scheme language standard at the time was R5RS, Naggum's argument is a common refrain from Scheme fans such as myself, and he was arguing with Kent Pitman ( @kentpitman ) who was one of the sub-committee chairs of the Common Lisp X3J13 standardization process, and is the editor and maintainer of the Common Lisp HyperSpec, an online form of the Common Lisp specification. Kent Pittman's reply I thought was very well-reasoned, and worth re-posting here (quote):
I just absolutely don't believe the Scheme standard is fairly cited as a model of a "better" standard. It is enormously vague on numerous matters of consequence. It omits really essential functionality that would be needed to write any seriously portable programs. It was stagnant for years on quibbles over some of the silliest syntax details. In my opinion, it's a toy language. There are real commercial Scheme implementations, but only by the sheer will of those implementers who've gone beyond the so-called standard and written in the things that the standard ought to have said in order to make the language finally useful. It achieves its "prettiness" and its "smallness" on the back of just plain leaving stuff out where it would appear to "clutter", and whatever you think of CL, I personally reject any claim that the Scheme is a model of improvement.
(end quote)
I wouldn't go so far as to call Scheme a "toy language" because the parts of the standard that are well-defined are solid and very useful. But yes, it seems the only useful implementations do solve these problems not addressed by the standard in completely different ways that makes it very difficult to write a Scheme program on one implementation that runs on another. Try to write one program that runs on MIT Scheme, Guile, Chez, Racket, Bigloo, Cyclone, Stklos, and Gambit. Try to even compute what set of SRFI (language extensions) are common to all of them. Most Scheme programmers have to pick just one implementation and stick to it without much hope of ever porting their programs to other implementations. It is possible to do it, easier than porting a program from Python to C++, but still not at all as easy as running the same Common Lisp program on SBCL, ECL, ABCL, or Franz.
So I do agree with @kentpitman that there are some pretty important details left up to the implementers simply because none of them could agree on what to do and punted the issue rather than resolve it. Later (after the aforementioned Usenet debate) R6RS would try to solve these issues, but that standard was mostly rejected by the larger part of the Scheme community due to a lack of consensus. Much of that work lives on in the SRFIs, while Chez Scheme (R. Kent Dybvig) seems to be sticking to R6RS and is one of the most well-respected Scheme implementations, and a kind of flagship of that standard.
I still have hope for R7RS-large though, which might end up being even larger than X3J13 when all is said and done. Unfortunately, recently John Cowan, chair of the R7RS-large standardization committee threw his hands up in resignation a few months ago after almost 10 years of trying to hammer-out consensus over details of the new R7RS-large standard. Daphne Preston Kendal ( @dpk ) has taken over and is fully capable of continuing the work.
It might be interesting if some Schemers could get together and write a new fully R7RS-compliant Scheme-to-Scheme compiler in R7RS-small Scheme, with all of the COND-EXPAND expressions in place to run on all of the major R7RS-compatible Scheme implementations. This compiler would simply translate its input into code that the host Scheme compiler can compile, deferring low-level implementation details to the host. The compiler should be one massive file that you could just load into any Scheme compiler and it just works. Then this compiler maybe, just maybe could become The Scheme Standard. A good starting point would be the work of Marc Nieper-Wißkirchen who has written Rapid Scheme which compiles R7RS Scheme to another host Scheme, but it only supports Chibi and Larceny as the hosts.
#guix tip of the day:
upstream server issues got you retriggering a command until the download succeeds? fire up a #guile repl and have it automate the process for you with just a few lines of #scheme.
Plan to stream about management of elixir projects with Guix in one hour and a half.
Will talk about transitive package management in general and why it's better not to package language-specific packages with Guix, will learn by example and clean up some tools we've made during the last month for Elixir in particular.
We have enough funds on RDE's opencollective, so we can setup a CI and substitute server and maybe some other infrastructure/project-related services in foreseable future.
Thank you very much everyone for help and support! <3