Automatic circular layout! Just 11 lines of scheme with riverguile. It's so nice being able to just play around with fun ideas. In my other layout generator, stacktile, this would have taken me at least an hour of wrangling boilerplate. With riverguile in scheme just a few minutes.
Working on riverguile and playing around with my layout and it just hit me that I can just (map (lambda ...) (iota view-count)) instead of using a recursive iterator. How has this not occurred to me before?
I've fallen in love with #lisp and #scheme after going through The Little Schemer. I love the simplicity of the language. It feels like I finally understand programming.
My big question is: where do I go from here?
As someone from a non-computery background (design) I want to kinda re-skill or switch to programming specifically in lisps. How does one do this and get to the level where they can become useful in an academic or commercial or open source context?
🔴 Today on #SystemCrafters Live, we'll try out Arei, a new IDE and REPL for Guile Scheme in Emacs written by @abcdw. This project aims to provide a more modern and robust development experience for Scheme compared to Geiser.
Let's see if we can hack on Guile projects more comfortably with Arei!
1 - Learn the emacs dialect of lisp called #elisp, to get you started there are docs & a simple tutorial via C-h-i [just scroll down & look for Elisp & Elisp intro]
2 - Learn a dialect of Common Lisp [#CL] such as #clisp, #sbcl or there is the famous MIT #SICP course based on #Scheme
We are organizing the FP Dag aka Dutch Functional Programming Day on Friday the 5th of January in Delft. People from neighboring countries are also very welcome to join!
The (soft) registration deadline is on the 22th of December (next Friday), so get your tickets soon!
Alpine Linux 3.19 is fresh off the press and, among other things, ships a new package for the Guix package manager that allows using Alpine as a foreign Guix distro. Was a bit laborious to package all of Guix's Scheme dependencies and also required some (now upstreamed) patches for musl compatibility, but it works quite well now.
I hate it when someone tells me, "well Python and JavaScript can be programmed in functional programming style, so they are just as good as any other functional programming language," and "something something objects are the same thing as closures."
Then my program crashes and I spend 20 minutes debugging only to find that for the 100th time I wrote a method like this:
def getThing(self): self.thing
instead of like this:
def getThing(self): return self.thing
...where basically the problem is most of my program is written in functional programming style, except you STILL have to write the fucking "return" statement as the last line of the function.
If your language has "return" as a built-in control flow, it is hopelessly imperative not functional, and there is not a single monad framework or higher-order-function library anywhere that will make your language functional.
Stop telling me imperative languages like Python and JavaScript are just as good as functional languages, they are objectively worse than functional languages.
> "One of the reasons I like Python is that it can be used for so many different tasks, and without having to learn a new language.
@steriana@Pitosalas here is the thing though, Python is one of the worst languages for trying to adapt it to many different tasks.
If you want a truly general purpose high-level language that can be adapted to many different tasks, Common Lisp or Scheme is considerably better. The interpreters and compilers for these languages actually provide carefully designed mechanisms, like macro expansion and pattern matching, specifically for adapting the language to different tasks. This is possible because the syntax of the language is so simple and minimal that it is very easy to devise embedded domain specific languages (EDSLs) with very little effort, and without requiring people to expend the effort of learning whole new languages.
Python's syntax is relatively complex compared to Lisp, and its APIs for modifying the compiler and interpreter are not at all well-designed for adapting the language to various tasks compared to those of Common Lisp or Scheme. Creating EDSLs is for Python is not idiomatic coding style and discouraged, but people try to adapt it to every possible task anyways, and it becomes a horrible mess.
So you or anyone else, adressing the software industry as a whole, wanted to learn just one high-level language to solve every problem for you, it ought to have been #Scheme or #CommonLisp. Relatively speaking, #Python is so incredibly limited in what it can do compared to those languages, Python was objectively the wrong choice for this "lets adapt it to all purposes" way of thinking. The software industry is truly in a horrible mess as a result.
By the way, languages like Racket and Gerbil which are both built on top of Scheme are very easy to learn for beginners.
long-term #conartist extraordinaire, living in #Bali due to #ASIC problems we believe.
He's been ripping off the #vulnerable for years. Prior to that, #anyone who would listen to him.
Is anyone writing #Guile#Scheme with #Neovim? I've tried #Conjure but printing of results to the repl doesn't work which doesn't make it a workable solution
"The thing is that maximal tree-shaking for languages with a thicker run-time has not been a huge priority. Consider Go: according to the #golang wiki, the most trivial program compiled to #WebAssembly from Go is 2 megabytes, and adding imports can make this go to 10 megabytes or more. Or look at Pyodide, the Python WebAssembly port: the REPL example downloads about 20 megabytes of data. These are fine sizes for technology demos or, in the limit, very rich applications, but they aren't winners for web development.
[...]
I work on the #Hoot#Scheme compiler, which targets #Wasm with GC. We manage to get down to 70 kB or so right now, in the minimal "main" compilation unit, and are aiming for lower; auxiliary compilation units that import run-time facilities (the current exception handler and so on) from the main module can be sub-kilobyte. Getting here has been tricky though, and I think it would be even trickier for #Python."
Possibly unpopular opinion: #wisp is much harder to read than regular #scheme with parenthesis because of all the extra syntax. I think it might be strictly better if the basic whitespace rule was used but parens were simply inserted instead of colon expressions.
Recent discussions with Ricardo Wurmus about the picture language got me willing to give it another try.
7yo and I made this “bonhomme”; it was me doing most things at the keyboard (especially for the hair!), but little by little they started to get a feel of what to modify to achieve their goals and how to create more shapes. Fun!
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.
While I agree that portability was awful before r6rs defined a standard module system, I dont think its fair to compare the portability of r4, r5, r6, and r7rs implementations like you're doing above (even if they offer a compatibility library/cond-expand that claims to be complete, which guile explicitly does not), nor to compare them with languages tha diverge with #scheme to the extent their authors consider them new languages (like racket and bigoloo).
But besides C, CL and Java, what general purpose languages also have a diversity of implementations along with easy portability? When I've tried compiling python programs across implementations its never been as easy as 1, 2, 3; if the program is sizeable it generally feels hopeless. Clojure implementations are mostly backend specific and their programs are almost entirely non-portable. I know from watching a talk from a Lua maintainer that their ecosystem sounds only marginally better than our story in scheme. And what's out there otherwise, especially in the production space, seems to be implementation-defined languages, which I think being iimplementations monocultures, dont really get a say here; they have to be considered non-portable given that you're stuck in one place.
Programs that run on Loko (r6rs) run on Chez (r6rs) without a problem in my experience so far; I can even get most modules from Chibi (r7rs) to load with little hassel. But I often hear this argument about how terribly unportable scheme is, while never being shown the light of languages where programs are highly portable across even just a few strong implementations.