Scheme fatigue has two sides. In the following I try the describe my views about Scheme programming language and also poke at a few other topics.
It might not be very well structured.
As far as I can tell, Scheme as a programming language is easy to the mind, there is a limited set of features (albeit sometime powerful ones) to grasp before being productive. Scheme is easy to maintain in the sense that when you come back to a piece of code (that is tested) months after you last checked it, it is possible to make sense of it, but also easy to rework or improve it. At least, Chez Scheme has profiling, a step debugger, with correct source file information and is efficient. Did I mention it was fast?
Scheme has a healthy ecosystem of computer scientist, coders, standards and implementations.
Many say, there is too many implementations, and that it is bad luck for the programming language as a whole. I would add that there is many maintained implementations. I disagree with the fact that it is bad luck. Scheme programming language describes a Turing-complete programming language that is easy, fun, documented, and grateful to implement in an interpreter or a compiler. That offers a clear and well documented path from apprentice to master champion.
Too much choice, kills choice you might say; one side of the coin of the Scheme world: which Scheme implementation should I choose?
Maybe they were about wording, philosophy and how big or small it ought to be. That is somewhat political. At the end of the day, each Scheme implementation retains its defining characteristics. That is helpful because it allows the split and share the work to explore new ideas and re-explore old ideas. It is also in the interest of commercial efforts because it avoids vendor lock-in.
Fragmentation is good.
Do It Yourself
The other side of the Scheme coin is the "Do It Yourself" philosophy.
There is the idea that minimalism equals small. On this topic I like to quote:
One might say that R5RS and R7RS-small are good enough and that schemes' efforts should be focused on improving and refining the ideas of small but powerful minimalism. The above quote goes to the point, minimalism is defined as the result of the work of taking away spurious features. If, to get started you have an empty set, there is nothing to remove, then there can be no notion of minimalism. I entertain the idea that, in this regard, R6RS and the larger R7RS will allow to create a set of common idioms upon which Scheme will continue its true minimalism seeking adventure. Prolly, R7RS will not be the end of minimalism, an ideal. Maybe there will be things to take away from it, but as of yet, since it is not finished and because there is still room for experiments one can not definitely rule that R7RS-large is not Scheme spirit. For instance, I think, Scheme object type calledare misleading, do not promote good programming practices, clutter the specification and the implementations. I made recently the discovery that one can rely on procedures to mimic the behavior of ports in backward compatible way while re-using existing code and idioms. That is, even in R5RS, there is according to me, things to take away. Without R7RS generators and accumulators, I would not be able to think that ports are a spurious abstraction coming from the past, haunting new students and seasoned engineers alike. The idea behind generators is well understood and self-contained to the extent that it does not break the small language kind-of idea and keeps around the DIY philosophy that is strong within the Scheme community.
In particular, I quote the following:
The Lisp Curse essay, try to explain that it is way too easy to do a fork. I argue that we should let it be so. I argue we should make it easier to fork. Meanwhile we should individually strive for better software. Better software should include rationales, tests, documentations, and credits to be able to understand the lineage of the idea, and question whether the premise that lead to a given solution do still make sense. Only later, maybe at some point, some guarantees like backward compatibility, deprecation policy, upgrade path and long time-support story. To put emulation, innovation and ideas melting at the forefront of humans goals.
I put long-time support at the end because the Good Thing is to be able to handle things on your own. Do it yourself. That is the most important idea that underlies the free and open source movement. That is what made the hop from pre-millenium based on scissor, paper and fossil fuel to current century possible.
"Lisp Curse" inflict upon the idea that lisp will never bring back the good old days that are before the AI-winter. Time traveling is not possible, but that does not matter. The thing that matters is lisps have overcome their past daemons related to performance and efficiency. Actually, people (like me) have reported that their Scheme code to be faster than the C or C++ equivalent. Also, Scheme has improved the maintainability e.g. the advent of , make the code much more readable, and more future proof. It is a complex, maybe complicated idiom, but a powerful one.
A consequence of the AI-winter is that LISP has, to some extent, lost mainstream momentum.
People cooperate toward a common goal, in distributed, non-coordinated way, even in evil environments with non-trusted peers most of the time, if not, all the time e.g. human race survival. That is, the is the Real Thing. Tho, I don't want to down play the role of the cathedral: the bazaar is made of many cathedrals, some times one-man lone-wolf hacker endeavors, some times the craft feat of many dedicated engineers.
At this point, I think we agree that the lisp curse is not that bad, being able to fork is healthy! In many ways, Scheme and Common Lisp projects by themself contradict the idea that it is not possible to build and sustain long and multi party efforts toward the goal of building Earth scale software systems. I will not cite more specific details or particular commercial or wanna-be whole world changing distribution because what Scheme programming language implementations have achieved, are, in my opinion, valuable enough in a scope that is larger than the programming community itself.
Do-It-Yourself is good.
I need to decide what to do of my free time.
My hearth is happy with the idea of a peer-to-peer collaboration system that would make it possible to fork at the function level. Taking inspiration from and and why not ethereum. It would also make it possible to translate definitions into your favorite natural language. No more English-only programmable programming systems.
It looks like a gigantic hop, but awesome one.