[Openmcl-devel] type specifier '(simple-vector n) in defmethod

Tim McNerney mc at media.mit.edu
Fri Jan 5 11:46:34 PST 2024


One more thing... [besides noting that auto-correct turned "what" into 
"when" on the first line]...

In addition to maintainers, CCL needs what Apple would call "evangelists."
By this I mean kinda "influencers" / promoters who, for example, get 
college professors interested in CCL
so more students might "cut their teeth" on CCL instead of on another 
Common Lisp (or Racket or Scheme).

Ron noted to me how easy CCL made it to evaluate expression in the 
built-in editor.
If we focus and improve on the /usability/ of CCL's IDE we might pick up 
some new users.
No professor or TA wants to keep answering FAQs on how to use an IDE.
Students don't need extra hassles; they just want to finish their 
problem set.
I personally like SLIME, but there are many people for whom emacs has 
too tall a learning curve.
Let's respect this preference.

On 1/5/24 2:34 PM, Tim McNerney wrote:
> There is value in when you are saying, Nicolas.
>
> Since Clozure Associates dissolved its LLC and its founders retired,
> it is now up to _us as a community_ to carry the torch and maintain CCL.
> There is no "somebody else" to do it for us.
> We all have to answer questions.
> We all have to fix bugs.
> We all have to make sure bug fixes are tested, checked in, and patches 
> created.
> There is an argument that a smaller "core" of maintainers oversee 
> releases,
> but if we keep adding to a regression suite and are diligent about 
> running it,
> anyone should be able to make a release, as long as they keep in 
> communication.
> Where "release" means a carefully curated and extensively tested build.
>
> As for CCL's "demise being greatly exaggerated," I've been seeing 
> clear evidence that
> there is decreasing opportunity to run a viable business licensing 
> proprietary CLs.
> Open source Common Lisps are the way to go.
> My apologies to the maintainers of SBCL, but it is weighed down by 
> lots of pet projects.
> CCL is a highly optimized, complex-but-lean, "diamond."
> I back the "diamond" approach.
>
> On 1/5/24 2:13 PM, Nicolas Martyanoff wrote:
>> Ron Garret<ron at flownet.com>  writes:
>>
>>>> On Jan 5, 2024, at 5:41 AM, Tim McNerney<mc at media.mit.edu>  wrote:
>>>>
>>>> It's not too late to fix this flaw. What's the harm?
>>> Bikeshedding.  If we don't get the M1 port done, CCL is dead.  We need to focus.
>> While I have no doubt that not having a M1 port is a deal breaker for
>> developers working on MacOS, I would argue that the lack of regular
>> releases and the multitude of open issues and pull requests (i.e. the
>> lack of maintenance) is what is killing CCL.
>>
>> Running on Apple Silicon is not going to fix the multitude of issues you
>> might encounter on any platform. As an example, a couple months ago I
>> try starting to write a patch for CCL, spent way too much time trying to
>> decipher code with no comment or type declaration, then realized that
>> CCL would randomly segfault when rebuilding itself (Linux/x86_64).
>> Google showed me at least one person having encountered the exact same
>> problem before, and zero answers. I went back to SBCL and will probably
>> drop CCL support from my projects because what is the point?
>>
>> I fully understand that no one at Clozure has the time or money to
>> invest on CCL and I'm not blaming anyone; it is already admirable of
>> them to have built CCL and released it under a free license. But
>> This is just what happens in the Open Source world when no one forks an
>> unmaintained project, especially for a language which while not dead is
>> starting to smell really funny.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20240105/f2a2c575/attachment-0001.htm>


More information about the Openmcl-devel mailing list