My funny Scheme story. My work place was using it in production, 1999. A ton of code was written by a VERY SMART (and famous) person and of course it worked. He delivered it under pressure, ahead of schedule and it just worked. Ok, but my frustration was that we could not find anyone to support the decoders. So, I could have 300 resumes, and zero would reference scheme.
So, there I was one Sunday, a church greeter, greeting people before church on a Sunday. And a fellow greeter brought up software, and I somewhat went off on Scheme as to how difficult it was to find interview candidates for the system.
Then, I turn around to greet the next person, and he had a Fricken Scheme Polo Shirt with a prominent Lambda. I am not sure if he heard me.
Scheme was a lot of places in 1999, so I started guessing about concentrations where someone might have had polo shirt schwag made up (e.g., Felleisen's PLT group at Rice, https://users.cs.northwestern.edu/~robby/logos/ ) and a lot of churchgoing people (Texas, Indiana, and maybe later BYU/Utah).
I was at MIT in 1999, and class T-shirts occasionally happened, and there were tens of churches within walking distance, for historic reasons, but not a lot of churchgoing people from the universities themselves, that I'm aware of.
But who knows: toplevel works in strange and mysterious ways.
> My work place was using it in production, 1999. A ton of code was written by a VERY SMART (and famous) person and of course it worked. He delivered it under pressure, ahead of schedule and it just worked. Ok, but my frustration was that we could not find anyone to support the decoders.
Actually, except for the "famous" part, that sounds a bit like a major system in Scheme for which I was hired by a very smart person who'd done 10x or 100x development on it. And it just worked, and we could evolve it rapidly, and keep it just working. In 1999, it probably would have been based in New Jersey.
Where's the "practical" one that site really reflected?
I liked scheme as a learning tool and got highest grades. That doesn't change my impression that most of the sites covering it are mental masturbation. Puzzles, or programs for the sake of scheme itself.
Where's the stuff to solve real world problems? (OK, mostly solved by other languages anyway... Still: where is the content that really wants a junior to try it out for routine problems and the senior tonstay with it?)
Today, that site gives an odd impression, and people will think like you did.
The nice thing about the Scheme community's aggressive inability to do practice advocacy is that there's very little noise like you get in employable languages.
For example, if you Google something about Scheme, there won't be a thousand redundant SEO 'tutorials' that were written in bad faith to attract eyeballs, rather than to fill a need and inform. (The closest Scheme comes to noise is when bloggers get a blog post out of trying Scheme, but most of the rest of it tends to be high quality relative to popular languages.)
It is hard to find people that can support it in production.
But for building makets of production systems to see where they are likely to fall over I've never found a better language.
The fact that you have to build everything from scratch is a plus when dealing with the eldrich horrors that lurk in business logic - you think you can use a standard queue? Hahaha let me tell you about a 6pm spike in latency that no one could explain and was driving the cellular network of a tier two city towards failure.
It's easy to teach any programmer Scheme sufficient for maintenance. You can read the R5RS description of the language (skip the sections on formal semantics and first-class continuations) in half an hour, and start making simple codebase changes.
Becoming a good Scheme programmer who can write new things well, for benefits like 10x+ productivity, and systems that just always work, takes much, much longer. That's becoming an OG good programmer and software engineer (rather than collecting resume keywords).
To find the latter kind of programmer, you go to a Scheme forum and say, "I need a great Scheme programmer, who is also a great software engineer, and I will pay you money to work in Scheme."
Model is so overused in software and computer science that it has a dozen meanings that would come to mind before the meaning of maket does. By comparison maket is a word with an obvious and single meaning you can find in most dictionaries, or a Google search.
I should probably spell it maquette since a plethora of useless letters is the sine qua non of intellectual sophistication.
Yes, most Turkish and Indonesian dictionaries, because Turkish and Indonesian have sane spelling. But English doesn't. Other alternatives in this context include "miniature", "spike", "diorama", and "prototype", which have the potential advantage that native English speakers might understand you. Or disadvantage, I suppose.
Hwail ai kenker wiq yer kr1tes1zm ev i6g1c orxogrefi, w1tc servz lardjli ez e wei te s1gnel socel kl4s bai wei ev i1rz weisted m3meraizi6 iuslesli 1r3giuler sp3li6z, iu k4nt boil q4t ocen 1n 3vri kament. Bet iu mei bi 1nter3sted 1n http://canonical.org/~kragen/alphanumerenglish. 1t simz laik qe kaind ev xi6 m3ni skimerz w5d laik, r1li.
They spoke Old French, which had a decent phonetic orthography. Due to a series of successful spelling reforms, even modern French orthography is almost phonetic, with a few exceptions like Duras and fils, but the rules are complicated. English, by contrast, is halfway to hanxi — it's full of etymological spellings for most words, false-etymological spellings for a few, and a general spelling system that primarily reflects the pronunciations before the Great Vowel Shift. We can't blame this on the Franks.
Typically "mock-up", like "wireframe", refers to a model of the user interface appearance, perhaps made with Figma or Photoshop, but I think noosphr is talking about a prototype of the functionality.
What you consider practical enough? The page links to a wiki software, a chat server, and a text preprocessor. Not popular sure but all are useful, practical programs you can use.
Due to the R-series of standards there are actually quite a lot of libraries you can use.
I'm not sure what you mean by "real world problems" but I think most would consider Cisco router firmware to be in that domain. In some sense, due to Cisco the Internet runs on two Lisp-like programming languages: Erlang and Chez.
If you look at TFA you'll find that it links over to a few articles that describe inventing a Scheme to solve things like high paced computer graphics production and large scale inventories.
Erlang is really not lisp-like beyond being functional. It's not especially homoiconic, much stricter about mutation than most lisps, and overall has a different focus. IIRC it started as a Prolog dialect, and I think it's still closer to that legacy than anything particularly lispy.
What I meant was: where are the resources that teach how to tackle everyday chores?
O'Reilly has a lot of "Real world <niche lang.>".
Not finished "practical" software -- albeit it's utterly cool to see that there are working projects in numbers / good showcases.
It's fine to have a collection for scheme (like the endless and sometimes helpful "awesome x" collections).
I'm missing the "Automate the boring stuff" and the like.
Maybe I'm more irritated about the lack of adoption (and grumpy about that -- not really the OP). E.g. I don't get it that Nix has more outreach than Guix, despite even Nix-users sometimes agree that the language isn't a strong selling point (I don't know about the idiosyncrasies of Guile, seemed preferable at first glance).
I might try this next, will check out and try to build it tomorrow
Shame that there’s no way to run ./configure on native windows though, I’ll have to use MSYS2
Imho maintainers should just keep a set of pre-made header-files for a Windows compiler, a huge portion the work configure does is because we historically had:
- Bad compilers (that lacked stdlib features)
- Lacked package managers (so we need to detect versions instead of just specifying used libraries for the program)
- The mess of various nix/linux distros having differing paths (/bin or /local/bin or /usr/local/bin or whatever?) and nix binaries lacked a standardized way to just locate "themselves"
In contrast, Windows programs mostly just make an API call to detect where they live and then just load files from relative paths, this also allows for side-by-side installations of varying versions instead of multiple builds (Yes, some programs sadly needed installers but that's just bad engineering, whilst many programs have portable variants).
Considering Mac programs also are self contained I guess those also have some sane API's for program self-location.
Yes, I do realize that much of the centralization of programs harkens back to Unix multi-user paradigms with centralized management but personal computers has been the norm for some almost 40 years at this point (Even if we've moved to web mainframes instead).
I've always liked bigloo. It's probably the most pragmatic of the schemes in my opinion. It never gets the attention that chicken and gambit get, though, and I've always wondered why.
Oh, right, I forgot about that one. As I remember, it's a good recommendation.
I'm guessing it doesn't get much chatter due to INRIA being not very good at promotion of the stuff they do, and Bigloo doesn't have the academia-industry-matrimonial push that e.g. Pharo has received.
Gauche that is hosted on this site can do it. It does by statically linking the entire Gauche system so may not be the best option. Besides Chez (compiling to native code) that sibling comments mentioned, other options are CHICKEN and Gambit compiling to C (CHICKEN docs provide instructions to even cross-compile[0]).
I've found Chicken reasonably good at compiling to a standalone executable on Linux. Because of how it works I imagine you can get it to work with msys too.
i am fairly sure chicken can do this (never used it on windows myself but the homepage lists all three major platforms). it worked great for building executables on linux and it had a good ecosystem of packages.
The best way I've found to make a standalone executable is to compile my scheme program into a .boot file and embed it, along with Chez's .boot files, into a small C program that then calls the scheme program.
Page doesn't seem to be all-inclusive in vein of awesome lists (such as github:schemedoc/awesome-scheme) but concentrated to author's own projects (Gauche and apps/libs). And maybe doesn't get updated beyond those (e.g. Bigloo homepage has been moved to https://www-sop.inria.fr/indes/fp/Bigloo/ years ago; probably before Chez became open which may be another reason it didn't made it to the list).
Atheists in 1999 might have to go Usenet comp.lang.scheme to find Scheme experts.
(Scheme polo shirt at church in 1999? My first guess is around Rice University. Second guess is Indiana.)
And of course MIT. https://archivesspace.mit.edu/repositories/2/archival_object...
I was at MIT in 1999, and class T-shirts occasionally happened, and there were tens of churches within walking distance, for historic reasons, but not a lot of churchgoing people from the universities themselves, that I'm aware of.
But who knows: toplevel works in strange and mysterious ways.
> My work place was using it in production, 1999. A ton of code was written by a VERY SMART (and famous) person and of course it worked. He delivered it under pressure, ahead of schedule and it just worked. Ok, but my frustration was that we could not find anyone to support the decoders.
Actually, except for the "famous" part, that sounds a bit like a major system in Scheme for which I was hired by a very smart person who'd done 10x or 100x development on it. And it just worked, and we could evolve it rapidly, and keep it just working. In 1999, it probably would have been based in New Jersey.
I liked scheme as a learning tool and got highest grades. That doesn't change my impression that most of the sites covering it are mental masturbation. Puzzles, or programs for the sake of scheme itself. Where's the stuff to solve real world problems? (OK, mostly solved by other languages anyway... Still: where is the content that really wants a junior to try it out for routine problems and the senior tonstay with it?)
The nice thing about the Scheme community's aggressive inability to do practice advocacy is that there's very little noise like you get in employable languages.
For example, if you Google something about Scheme, there won't be a thousand redundant SEO 'tutorials' that were written in bad faith to attract eyeballs, rather than to fill a need and inform. (The closest Scheme comes to noise is when bloggers get a blog post out of trying Scheme, but most of the rest of it tends to be high quality relative to popular languages.)
But for building makets of production systems to see where they are likely to fall over I've never found a better language.
The fact that you have to build everything from scratch is a plus when dealing with the eldrich horrors that lurk in business logic - you think you can use a standard queue? Hahaha let me tell you about a 6pm spike in latency that no one could explain and was driving the cellular network of a tier two city towards failure.
It's easy to teach any programmer Scheme sufficient for maintenance. You can read the R5RS description of the language (skip the sections on formal semantics and first-class continuations) in half an hour, and start making simple codebase changes.
Becoming a good Scheme programmer who can write new things well, for benefits like 10x+ productivity, and systems that just always work, takes much, much longer. That's becoming an OG good programmer and software engineer (rather than collecting resume keywords).
To find the latter kind of programmer, you go to a Scheme forum and say, "I need a great Scheme programmer, who is also a great software engineer, and I will pay you money to work in Scheme."
I should probably spell it maquette since a plethora of useless letters is the sine qua non of intellectual sophistication.
Hwail ai kenker wiq yer kr1tes1zm ev i6g1c orxogrefi, w1tc servz lardjli ez e wei te s1gnel socel kl4s bai wei ev i1rz weisted m3meraizi6 iuslesli 1r3giuler sp3li6z, iu k4nt boil q4t ocen 1n 3vri kament. Bet iu mei bi 1nter3sted 1n http://canonical.org/~kragen/alphanumerenglish. 1t simz laik qe kaind ev xi6 m3ni skimerz w5d laik, r1li.
This is specifically French linguistic heritage. For a long time the upper classes of England spoke French, and now we're stuck with it. :)
> One day, however, I will point this page, when the friend asks me if Scheme is feasible for daily chores and a practical choice.
I'm not sure what you mean by "real world problems" but I think most would consider Cisco router firmware to be in that domain. In some sense, due to Cisco the Internet runs on two Lisp-like programming languages: Erlang and Chez.
If you look at TFA you'll find that it links over to a few articles that describe inventing a Scheme to solve things like high paced computer graphics production and large scale inventories.
What I meant was: where are the resources that teach how to tackle everyday chores? O'Reilly has a lot of "Real world <niche lang.>".
Not finished "practical" software -- albeit it's utterly cool to see that there are working projects in numbers / good showcases.
It's fine to have a collection for scheme (like the endless and sometimes helpful "awesome x" collections).
I'm missing the "Automate the boring stuff" and the like.
Maybe I'm more irritated about the lack of adoption (and grumpy about that -- not really the OP). E.g. I don't get it that Nix has more outreach than Guix, despite even Nix-users sometimes agree that the language isn't a strong selling point (I don't know about the idiosyncrasies of Guile, seemed preferable at first glance).
- Bad compilers (that lacked stdlib features)
- Lacked package managers (so we need to detect versions instead of just specifying used libraries for the program)
- The mess of various nix/linux distros having differing paths (/bin or /local/bin or /usr/local/bin or whatever?) and nix binaries lacked a standardized way to just locate "themselves"
In contrast, Windows programs mostly just make an API call to detect where they live and then just load files from relative paths, this also allows for side-by-side installations of varying versions instead of multiple builds (Yes, some programs sadly needed installers but that's just bad engineering, whilst many programs have portable variants).
Considering Mac programs also are self contained I guess those also have some sane API's for program self-location.
Yes, I do realize that much of the centralization of programs harkens back to Unix multi-user paradigms with centralized management but personal computers has been the norm for some almost 40 years at this point (Even if we've moved to web mainframes instead).
I'm guessing it doesn't get much chatter due to INRIA being not very good at promotion of the stuff they do, and Bigloo doesn't have the academia-industry-matrimonial push that e.g. Pharo has received.
[0]: http://wiki.call-cc.org/man/5/Cross%20development#cross-deve...
All of the necessary functions to create such a C program documented here: https://cisco.github.io/ChezScheme/csug10.0/foreign.html#./f...
The relevant functions for this applictation are:
Sscheme_init
Sregister_boot_file_bytes
Sbuild_heap
Senable_expeditor (if you want to use Chez's builtin REPL)
Sscheme_start
Sscheme_deinit
I'd post an example program, but I've not got access to my development machine at the moment.
I think there's been some work lately to improve Chicken's Windows support.
0 results
why? it's so good
https://practical-scheme.net/wiliki/schemexref.cgi?ChezSchem...