https://github.com/byulparan/cl-collider "A SuperCollider <http://supercollider.github.io/> client for CommonLisp <https://www.common-lisp.net/>" Never tried this but I've been following it for a few years and it is actively under development. Andy On Mon, 6 Jul 2020 at 13:57, Ken Tilton <kentilton@gmail.com> wrote:

Thanks for the seconding motion! But part of the plan is high accessibility, and low cost. I just noticed the pricing on OpusModus, bit of a showstopper there.

We would use Clojure Overtone https://overtone.github.io/ but that sits atop Supercollider, not sure if that would make installation a PITA. Ideally we would have sth built atop Web Audio, but then we really are super low-level. I think! Have to look into that.

We *would* want to hook the students with solid music before taking them down to the basics, so existing effects etc would be great to have, but again, this is about coding in general, not music generation. That is just the hook.

Thx again! If some campers get more turned on by music than coding that will be a great next step.

On Mon, Jul 6, 2020 at 1:43 PM dbm@refined-audiometrics.com < dbm@refined-audiometrics.com> wrote:

...

Yes, I was also going to suggest OpusModus. I see little purpose in reinventing any portion of what they have done.

I have been a user for about 2 years now. It seems to be the defacto replacement for an earlier product done in Lispworks, from Italy, called Symbolic Composer. OpusModus is very good, and getting better every day. They just implemented live MIDI recording in the latest version.

- David McClain Refined Audiometrics Laboratory, LLC Tucson, AZ, USA refined-audiometrics.com

On Jul 6, 2020, at 8:11 AM, Ken Tilton <kentilton@gmail.com> wrote:

Sounds great, I will keep it in mind if we loosen the web/mobile-native constraint. Or maybe as a direction for campers who take off -- no need then to fret over platform, power will matter.

Thx!

On Mon, Jul 6, 2020 at 10:54 AM Stonewall Ballard <stoney@sb.org> wrote:

...

Ken,

Are you familiar with Opusmodus? <http://opusmodus.com>

It’s written in Clozure ccl, and besides providing an incredible array of music manipulation functions and structures, it’s got a beautiful window system. Mac only.

Your idea of using music as a hook to learn Lisp sounds plausible. Good Luck!

- Stoney ———— Stonewall Ballard stoney@sb.org http://stoney.sb.org

On Monday, July 6 at 8:15:31 AM, Ken Tilton (kentilton@gmail.com) wrote:

So I got to thinking about creating an approachable pathway to IT careers for anyone really, but in the spirit of today one focused on creating career opportunities for African Americans.

The idea would be a code camp developed around algorithmic generation of music. I know nothing about music theory, except that there is prolly enough there to introduce most if not all fundamental programming concepts.

For those campers that accidentally get hooked on programming itself, which is how many of us ended up in IT careers, away they go!

The idea is to:

- use music as the hook; - defer as long as possible the annoying things about programming (I am looking at you, node.js); - part of that ^^^ will be using a powerful language with the parentheses in the right place, prolly ClojureScript since that could run where JS runs; - keep programming as the focus, as tempting as the music will be. Sonic Pi comes with all sorts of built-in sound capabilities, but we want to *develop* those in the code camp; - tailor the program to specific musical genres, to maximize the musical hook.

I am dropping this here since I know many Common Lispers have a strong musical bent. My questions are:

- Could we use CL instead? I do think this almost has to be a web app, perhaps even mobile. Hmmm, we *could* CL-ify CLJS with sufficent clever macrology. - What do you think? Can a solid programming fundamentals course be expressed in music theory? Hint: HTTP is not a programming fundamental. - If there is any interest, what would be a good place for an ongoing discussion? Google groups?

Ideas, comments, suggestions all welcome.

-hk

-- Kenneth Tilton http://tiltontec.com/

-- Kenneth Tilton http://tiltontec.com/

Hi Ken, I think music is a great way to engage a wider audience of potential developers. It has a wider appeal and lower barrier to entry than many other programming activities. Having seen kids fire up a web browser to do "Scratch programming", I'm convinced that a web-based platform is the most accessible. People can use almost any computer to create accounts, create projects, and share/publish projects. Only seasoned developers are comfortable with the concept of "install this editor, compiler, and Git". :) Here's an interesting language, though it may not have a audio library yet. https://www.pyret.org/ - Daniel On Mon, 6 Jul 2020, Ken Tilton wrote:

"actively under development"! Music (sorry) to my ears! The Lisp and ADD genes must overlap seriously. I started one of the videos. Really nice live coding.

I'll make sure our code camp grad school uses CL.

Thx!

-hk

On Mon, Jul 6, 2020 at 8:11 PM Andy Peterson <andy.arvid@gmail.com> wrote: https://github.com/byulparan/cl-collider "A SuperCollider client for CommonLisp"

Never tried this but I've been following it for a few years and it is actively under development.

Andy 

On Mon, 6 Jul 2020 at 13:57, Ken Tilton <kentilton@gmail.com> wrote: Thanks for the seconding motion! But part of the plan is high accessibility, and low cost. I just noticed the pricing on OpusModus, bit of a showstopper there. 

We would use Clojure Overtone https://overtone.github.io/ but that sits atop Supercollider, not sure if that would make installation a PITA. Ideally we would have sth built atop Web Audio, but then we really are super low-level. I think! Have to look into that. 

We would want to hook the students with solid music before taking them down to the basics, so existing effects etc would be great to have, but again, this is about coding in general, not music generation. That is just the hook.

Thx again! If some campers get more turned on by music than coding that will be a great next step.

On Mon, Jul 6, 2020 at 1:43 PM dbm@refined-audiometrics.com <dbm@refined-audiometrics.com> wrote:

Yes, I was also going to suggest OpusModus. I see little purpose in reinventing any portion of what they have done.

I have been a user for about 2 years now. It seems to be the defacto replacement for an earlier product done in Lispworks, from Italy, called Symbolic Composer. OpusModus is very good, and getting better every day. They just implemented live MIDI recording in the latest version.

- David McClain Refined Audiometrics Laboratory, LLC Tucson, AZ, USA refined-audiometrics.com

On Jul 6, 2020, at 8:11 AM, Ken Tilton <kentilton@gmail.com> wrote:

Sounds great, I will keep it in mind if we loosen the web/mobile-native constraint. Or maybe as a direction for campers who take off -- no need then to fret over platform, power will matter.

Thx!

On Mon, Jul 6, 2020 at 10:54 AM Stonewall Ballard <stoney@sb.org> wrote: Ken,

Are you familiar with Opusmodus? <http://opusmodus.com>

It’s written in Clozure ccl, and besides providing an incredible array of music manipulation functions and structures, it’s got a beautiful window system. Mac only.

Your idea of using music as a hook to learn Lisp sounds plausible. Good Luck!

 - Stoney ————Stonewall Ballard    stoney@sb.org   http://stoney.sb.org

On Monday, July 6 at 8:15:31 AM, Ken Tilton (kentilton@gmail.com) wrote:

So I got to thinking about creating an approachable pathway to IT careers for anyone really, but in the spirit of today one focused on creating career opportunities for African Americans.

The idea would be a code camp developed around algorithmic generation of music. I know nothing about music theory, except that there is prolly enough there to introduce most if not all fundamental programming concepts.

For those campers that accidentally get hooked on programming itself, which is how many of us ended up in IT careers, away they go!

The idea is to: * use music as the hook; * defer as long as possible the annoying things about programming (I am looking at you, node.js); * part of that ^^^ will be using a powerful language with the parentheses in the right place, prolly ClojureScript since that could run where JS runs; * keep programming as the focus, as tempting as the music will be. Sonic Pi comes with all sorts of built-in sound capabilities, but we want to develop those in the code camp; * tailor the program to specific musical genres, to maximize the musical hook. I am dropping this here since I know many Common Lispers have a strong musical bent. My questions are: * Could we use CL instead? I do think this almost has to be a web app, perhaps even mobile. Hmmm, we could CL-ify CLJS with sufficent clever macrology. * What do you think? Can a solid programming fundamentals course be expressed in music theory? Hint: HTTP is not a programming fundamental. * If there is any interest, what would be a good place for an ongoing discussion? Google groups? Ideas, comments, suggestions all welcome.

-hk

-- Kenneth Tilton http://tiltontec.com/

-- Kenneth Tilton http://tiltontec.com/

-- Kenneth Tilton http://tiltontec.com/

I cannot hold my tongue on Pyret – why not Dylan? Pyret breaks no new ground, and does not have as good a language designer as Dave Moon. It's macro system can be trivially used to add the test-ish stuff that Pyret puts in its core language. Dylan remains the best language I've seen that never got traction. —S On Tue, Jul 7, 2020 at 4:41 AM Ken Tilton <kentilton@gmail.com> wrote:

Hey, Daniel.

Thanks for the +1, as the kids today say!

Yeah, what we developers deal with must somehow be avoided until the students have felt the thrill of programming, if they will. This programme will not be for everyone. But for those who light up as much over algorithms as they do the music, *then* we can let them see a two thousand line Clojure backtrace on every error. Grrrr. :)

I like the section contrasting Pyret with other languages that are considered clean syntactically. Pyret makes them look like Java. :) We devs put up with such garbage. One reason I want Clojure or CL for this is because the macros will make it easy to deliver a super friendly yet powerful new music DSL.

Looking at Pyret also reminded me of Logo, another super clean yet powerful language aimed at noobs of any age.

Thx for the Pyret pointer!

-hk

On Mon, Jul 6, 2020 at 11:23 PM Daniel Herring <dherring@tentpost.com> wrote:

...

Hi Ken,

I think music is a great way to engage a wider audience of potential developers. It has a wider appeal and lower barrier to entry than many other programming activities.

Having seen kids fire up a web browser to do "Scratch programming", I'm convinced that a web-based platform is the most accessible. People can use almost any computer to create accounts, create projects, and share/publish projects. Only seasoned developers are comfortable with the concept of "install this editor, compiler, and Git". :)

Here's an interesting language, though it may not have a audio library yet.

https://www.pyret.org/

- Daniel

On Mon, 6 Jul 2020, Ken Tilton wrote:

...

"actively under development"! Music (sorry) to my ears! The Lisp and ADD genes must overlap seriously. I started one of the videos. Really nice live coding.

I'll make sure our code camp grad school uses CL.

Thx!

-hk

On Mon, Jul 6, 2020 at 8:11 PM Andy Peterson <andy.arvid@gmail.com> wrote: https://github.com/byulparan/cl-collider "A SuperCollider client for CommonLisp"

Never tried this but I've been following it for a few years and it is actively under development.

Andy

On Mon, 6 Jul 2020 at 13:57, Ken Tilton <kentilton@gmail.com> wrote: Thanks for the seconding motion! But part of the plan is high accessibility, and low cost. I just noticed the pricing on OpusModus, bit of a showstopper there.

We would use Clojure Overtone https://overtone.github.io/ but that sits atop Supercollider, not sure if that would make installation a PITA. Ideally we would have sth built atop Web Audio, but then we really are super low-level. I think! Have to look into that.

We would want to hook the students with solid music before taking them down to the basics, so existing effects etc would be great to have, but again, this is about coding in general, not music generation. That is just the hook.

Thx again! If some campers get more turned on by music than coding that will be a great next step.

On Mon, Jul 6, 2020 at 1:43 PM dbm@refined-audiometrics.com < dbm@refined-audiometrics.com> wrote:

Yes, I was also going to suggest OpusModus. I see little purpose in reinventing any portion of what they have done.

I have been a user for about 2 years now. It seems to be the defacto replacement for an earlier product done in Lispworks, from Italy, called Symbolic Composer. OpusModus is very good, and getting better every day. They just implemented live MIDI recording in the latest version.

- David McClain Refined Audiometrics Laboratory, LLC Tucson, AZ, USA refined-audiometrics.com

On Jul 6, 2020, at 8:11 AM, Ken Tilton <kentilton@gmail.com> wrote:

Sounds great, I will keep it in mind if we loosen the web/mobile-native constraint. Or maybe as a direction for campers who take off -- no need then to fret over platform, power will matter.

Thx!

On Mon, Jul 6, 2020 at 10:54 AM Stonewall Ballard <stoney@sb.org> wrote: Ken,

Are you familiar with Opusmodus? <http://opusmodus.com>

It’s written in Clozure ccl, and besides providing an incredible array of music manipulation functions and structures, it’s got a beautiful window system. Mac only.

Your idea of using music as a hook to learn Lisp sounds plausible. Good Luck!

- Stoney ————Stonewall Ballard stoney@sb.org http://stoney.sb.org

On Monday, July 6 at 8:15:31 AM, Ken Tilton (kentilton@gmail.com) wrote:

So I got to thinking about creating an approachable pathway to IT careers for anyone really, but in the spirit of today one focused on creating career opportunities for African Americans.

The idea would be a code camp developed around algorithmic generation of music. I know nothing about music theory, except that there is prolly enough there to introduce most if not all fundamental programming concepts.

For those campers that accidentally get hooked on programming itself, which is how many of us ended up in IT careers, away they go!

The idea is to: * use music as the hook; * defer as long as possible the annoying things about programming (I am looking at you, node.js); * part of that ^^^ will be using a powerful language with the parentheses in the right place, prolly ClojureScript since that could run where JS runs; * keep programming as the focus, as tempting as the music will be. Sonic Pi comes with all sorts of built-in sound capabilities, but we want to develop those in the code camp; * tailor the program to specific musical genres, to maximize the musical hook. I am dropping this here since I know many Common Lispers have a strong musical bent. My questions are: * Could we use CL instead? I do think this almost has to be a web app, perhaps even mobile. Hmmm, we could CL-ify CLJS with sufficent clever macrology. * What do you think? Can a solid programming fundamentals course be expressed in music theory? Hint: HTTP is not a programming fundamental. * If there is any interest, what would be a good place for an ongoing discussion? Google groups? Ideas, comments, suggestions all welcome.

-hk

-- Kenneth Tilton http://tiltontec.com/

-- Kenneth Tilton http://tiltontec.com/

-- Kenneth Tilton http://tiltontec.com/

-- Kenneth Tilton http://tiltontec.com/

Jonathan Bachrach, one of the early Dylan implementors, worked on this while he was at IRCAM, I believe. On Thu, Jul 9, 2020 at 10:07 AM dbm@refined-audiometrics.com < dbm@refined-audiometrics.com> wrote:

I just spotted this during some perusing… IRCAM, in Paris, France, develops lots of different tools for avant garde music creation. They have this thing called OpenMusic, very simiilar to Max. But in the lower right of the page they have our mascot…

http://repmus.ircam.fr/openmusic/home

- DM

I can't argue with that. My point was, if you're gonna use a fringe language (*), use a *good* fringe language. (*) I don't think Julia is "fringe" any more. On Wed, Dec 2, 2020 at 5:45 AM Bob Cassels <bobcassels@netscape.net> wrote:

Hey Scott,

Go with Julia. It’s enough like Dylan (multi-argument generic function dispatch, expression-oriented, macros), but better in important ways (better type system, package system, better compilation model, cross-language integration).

It has warts (kludgy, messy syntax), but mostly it has traction (active, growing user community, increasing library support, libraries are cutting edge).

If you long for Dylan, Julia is where you want to be. It’s where the smart cool kids are.

Bob

On Jul 7, 2020, at 8:24 AM, Scott McKay <swmckay@gmail.com> wrote:

I cannot hold my tongue on Pyret – why not Dylan? Pyret breaks no new ground, and does not have as good a language designer as Dave Moon. It's macro system can be trivially used to add the test-ish stuff that Pyret puts in its core language.

Dylan remains the best language I've seen that never got traction.

—S

On Tue, Jul 7, 2020 at 4:41 AM Ken Tilton <kentilton@gmail.com> wrote:

...

Hey, Daniel.

Thanks for the +1, as the kids today say!

Yeah, what we developers deal with must somehow be avoided until the students have felt the thrill of programming, if they will. This programme will not be for everyone. But for those who light up as much over algorithms as they do the music, *then* we can let them see a two thousand line Clojure backtrace on every error. Grrrr. :)

I like the section contrasting Pyret with other languages that are considered clean syntactically. Pyret makes them look like Java. :) We devs put up with such garbage. One reason I want Clojure or CL for this is because the macros will make it easy to deliver a super friendly yet powerful new music DSL.

Looking at Pyret also reminded me of Logo, another super clean yet powerful language aimed at noobs of any age.

Thx for the Pyret pointer!

-hk

On Mon, Jul 6, 2020 at 11:23 PM Daniel Herring <dherring@tentpost.com> wrote:

...

Hi Ken,

I think music is a great way to engage a wider audience of potential developers. It has a wider appeal and lower barrier to entry than many other programming activities.

Having seen kids fire up a web browser to do "Scratch programming", I'm convinced that a web-based platform is the most accessible. People can use almost any computer to create accounts, create projects, and share/publish projects. Only seasoned developers are comfortable with the concept of "install this editor, compiler, and Git". :)

Here's an interesting language, though it may not have a audio library yet.

https://www.pyret.org/

- Daniel

On Mon, 6 Jul 2020, Ken Tilton wrote:

...

"actively under development"! Music (sorry) to my ears! The Lisp and ADD genes must overlap seriously. I started one of the videos. Really nice live coding.

I'll make sure our code camp grad school uses CL.

Thx!

-hk

On Mon, Jul 6, 2020 at 8:11 PM Andy Peterson <andy.arvid@gmail.com> wrote: https://github.com/byulparan/cl-collider "A SuperCollider client for CommonLisp"

Never tried this but I've been following it for a few years and it is actively under development.

Andy

On Mon, 6 Jul 2020 at 13:57, Ken Tilton <kentilton@gmail.com> wrote: Thanks for the seconding motion! But part of the plan is high accessibility, and low cost. I just noticed the pricing on OpusModus, bit of a showstopper there.

We would use Clojure Overtone https://overtone.github.io/ but that sits atop Supercollider, not sure if that would make installation a PITA. Ideally we would have sth built atop Web Audio, but then we really are super low-level. I think! Have to look into that.

We would want to hook the students with solid music before taking them down to the basics, so existing effects etc would be great to have, but again, this is about coding in general, not music generation. That is just the hook.

Thx again! If some campers get more turned on by music than coding that will be a great next step.

On Mon, Jul 6, 2020 at 1:43 PM dbm@refined-audiometrics.com < dbm@refined-audiometrics.com> wrote:

Yes, I was also going to suggest OpusModus. I see little purpose in reinventing any portion of what they have done.

I have been a user for about 2 years now. It seems to be the defacto replacement for an earlier product done in Lispworks, from Italy, called Symbolic Composer. OpusModus is very good, and getting better every day. They just implemented live MIDI recording in the latest version.

- David McClain Refined Audiometrics Laboratory, LLC Tucson, AZ, USA refined-audiometrics.com

On Jul 6, 2020, at 8:11 AM, Ken Tilton <kentilton@gmail.com> wrote:

Sounds great, I will keep it in mind if we loosen the web/mobile-native constraint. Or maybe as a direction for campers who take off -- no need then to fret over platform, power will matter.

Thx!

On Mon, Jul 6, 2020 at 10:54 AM Stonewall Ballard <stoney@sb.org> wrote: Ken,

Are you familiar with Opusmodus? <http://opusmodus.com>

It’s written in Clozure ccl, and besides providing an incredible array of music manipulation functions and structures, it’s got a beautiful window system. Mac only.

Your idea of using music as a hook to learn Lisp sounds plausible. Good Luck!

- Stoney ————Stonewall Ballard stoney@sb.org http://stoney.sb.org

On Monday, July 6 at 8:15:31 AM, Ken Tilton (kentilton@gmail.com) wrote:

So I got to thinking about creating an approachable pathway to IT careers for anyone really, but in the spirit of today one focused on creating career opportunities for African Americans.

The idea would be a code camp developed around algorithmic generation of music. I know nothing about music theory, except that there is prolly enough there to introduce most if not all fundamental programming concepts.

For those campers that accidentally get hooked on programming itself, which is how many of us ended up in IT careers, away they go!

The idea is to: * use music as the hook; * defer as long as possible the annoying things about programming (I am looking at you, node.js); * part of that ^^^ will be using a powerful language with the parentheses in the right place, prolly ClojureScript since that could run where JS runs; * keep programming as the focus, as tempting as the music will be. Sonic Pi comes with all sorts of built-in sound capabilities, but we want to develop those in the code camp; * tailor the program to specific musical genres, to maximize the musical hook. I am dropping this here since I know many Common Lispers have a strong musical bent. My questions are: * Could we use CL instead? I do think this almost has to be a web app, perhaps even mobile. Hmmm, we could CL-ify CLJS with sufficent clever macrology. * What do you think? Can a solid programming fundamentals course be expressed in music theory? Hint: HTTP is not a programming fundamental. * If there is any interest, what would be a good place for an ongoing discussion? Google groups? Ideas, comments, suggestions all welcome.

-hk

-- Kenneth Tilton http://tiltontec.com/

-- Kenneth Tilton http://tiltontec.com/

-- Kenneth Tilton http://tiltontec.com/

-- Kenneth Tilton http://tiltontec.com/

Rust is C++ done right. At this point, I have several stacks based on what I'm doing: * Web back end – Python/Django * Web front end – Javascript/React * ML/AI (as a "client") – Python * Systems programming – Rust On Wed, Dec 2, 2020 at 9:57 AM Marco Antoniotti <marco.antoniotti@unimib.it> wrote:

I second what Scott said. Julia is not "fringe" and I am thinking that - too late probably - that is a Very Good Thing (tm)

Apart from that, Rust was described in "Nature". You cannot get more mainstream than that.

Ciao

Marco

PS Me, I am checking out PL/I

On Wed, Dec 2, 2020 at 8:52 AM Scott McKay <swmckay@gmail.com> wrote:

...

I can't argue with that. My point was, if you're gonna use a fringe language (*), use a *good* fringe language.

(*) I don't think Julia is "fringe" any more.

On Wed, Dec 2, 2020 at 5:45 AM Bob Cassels <bobcassels@netscape.net> wrote:

...

Hey Scott,

Go with Julia. It’s enough like Dylan (multi-argument generic function dispatch, expression-oriented, macros), but better in important ways (better type system, package system, better compilation model, cross-language integration).

It has warts (kludgy, messy syntax), but mostly it has traction (active, growing user community, increasing library support, libraries are cutting edge).

If you long for Dylan, Julia is where you want to be. It’s where the smart cool kids are.

Bob

On Jul 7, 2020, at 8:24 AM, Scott McKay <swmckay@gmail.com> wrote:

I cannot hold my tongue on Pyret – why not Dylan? Pyret breaks no new ground, and does not have as good a language designer as Dave Moon. It's macro system can be trivially used to add the test-ish stuff that Pyret puts in its core language.

Dylan remains the best language I've seen that never got traction.

—S

On Tue, Jul 7, 2020 at 4:41 AM Ken Tilton <kentilton@gmail.com> wrote:

...

Hey, Daniel.

Thanks for the +1, as the kids today say!

Yeah, what we developers deal with must somehow be avoided until the students have felt the thrill of programming, if they will. This programme will not be for everyone. But for those who light up as much over algorithms as they do the music, *then* we can let them see a two thousand line Clojure backtrace on every error. Grrrr. :)

I like the section contrasting Pyret with other languages that are considered clean syntactically. Pyret makes them look like Java. :) We devs put up with such garbage. One reason I want Clojure or CL for this is because the macros will make it easy to deliver a super friendly yet powerful new music DSL.

Looking at Pyret also reminded me of Logo, another super clean yet powerful language aimed at noobs of any age.

Thx for the Pyret pointer!

-hk

On Mon, Jul 6, 2020 at 11:23 PM Daniel Herring <dherring@tentpost.com> wrote:

...

Hi Ken,

I think music is a great way to engage a wider audience of potential developers. It has a wider appeal and lower barrier to entry than many other programming activities.

Having seen kids fire up a web browser to do "Scratch programming", I'm convinced that a web-based platform is the most accessible. People can use almost any computer to create accounts, create projects, and share/publish projects. Only seasoned developers are comfortable with the concept of "install this editor, compiler, and Git". :)

Here's an interesting language, though it may not have a audio library yet.

https://www.pyret.org/

- Daniel

On Mon, 6 Jul 2020, Ken Tilton wrote:

...

"actively under development"! Music (sorry) to my ears! The Lisp and ADD genes must overlap seriously. I started one of the videos. Really nice live coding.

I'll make sure our code camp grad school uses CL.

Thx!

-hk

On Mon, Jul 6, 2020 at 8:11 PM Andy Peterson <andy.arvid@gmail.com> wrote: https://github.com/byulparan/cl-collider "A SuperCollider client for CommonLisp"

Never tried this but I've been following it for a few years and it is actively under development.

Andy

On Mon, 6 Jul 2020 at 13:57, Ken Tilton <kentilton@gmail.com> wrote: Thanks for the seconding motion! But part of the plan is high accessibility, and low cost. I just noticed the pricing on OpusModus, bit of a showstopper there.

We would use Clojure Overtone https://overtone.github.io/ but that sits atop Supercollider, not sure if that would make installation a PITA. Ideally we would have sth built atop Web Audio, but then we really are super low-level. I think! Have to look into that.

We would want to hook the students with solid music before taking them down to the basics, so existing effects etc would be great to have, but again, this is about coding in general, not music generation. That is just the hook.

Thx again! If some campers get more turned on by music than coding that will be a great next step.

On Mon, Jul 6, 2020 at 1:43 PM dbm@refined-audiometrics.com < dbm@refined-audiometrics.com> wrote:

Yes, I was also going to suggest OpusModus. I see little purpose in reinventing any portion of what they have done.

I have been a user for about 2 years now. It seems to be the defacto replacement for an earlier product done in Lispworks, from Italy, called Symbolic Composer. OpusModus is very good, and getting better every day. They just implemented live MIDI recording in the latest version.

- David McClain Refined Audiometrics Laboratory, LLC Tucson, AZ, USA refined-audiometrics.com

On Jul 6, 2020, at 8:11 AM, Ken Tilton <kentilton@gmail.com> wrote:

Sounds great, I will keep it in mind if we loosen the web/mobile-native constraint. Or maybe as a direction for campers who take off -- no need then to fret over platform, power will matter.

Thx!

On Mon, Jul 6, 2020 at 10:54 AM Stonewall Ballard <stoney@sb.org> wrote: Ken,

Are you familiar with Opusmodus? <http://opusmodus.com>

It’s written in Clozure ccl, and besides providing an incredible array of music manipulation functions and structures, it’s got a beautiful window system. Mac only.

Your idea of using music as a hook to learn Lisp sounds plausible. Good Luck!

- Stoney ————Stonewall Ballard stoney@sb.org http://stoney.sb.org

On Monday, July 6 at 8:15:31 AM, Ken Tilton (kentilton@gmail.com) wrote:

So I got to thinking about creating an approachable pathway to IT careers for anyone really, but in the spirit of today one focused on creating career opportunities for African Americans.

The idea would be a code camp developed around algorithmic generation of music. I know nothing about music theory, except that there is prolly enough there to introduce most if not all fundamental programming concepts.

For those campers that accidentally get hooked on programming itself, which is how many of us ended up in IT careers, away they go!

The idea is to: * use music as the hook; * defer as long as possible the annoying things about programming (I am looking at you, node.js); * part of that ^^^ will be using a powerful language with the parentheses in the right place, prolly ClojureScript since that could run where JS runs; * keep programming as the focus, as tempting as the music will be. Sonic Pi comes with all sorts of built-in sound capabilities, but we want to develop those in the code camp; * tailor the program to specific musical genres, to maximize the musical hook. I am dropping this here since I know many Common Lispers have a strong musical bent. My questions are: * Could we use CL instead? I do think this almost has to be a web app, perhaps even mobile. Hmmm, we could CL-ify CLJS with sufficent clever macrology. * What do you think? Can a solid programming fundamentals course be expressed in music theory? Hint: HTTP is not a programming fundamental. * If there is any interest, what would be a good place for an ongoing discussion? Google groups? Ideas, comments, suggestions all welcome.

-hk

-- Kenneth Tilton http://tiltontec.com/

-- Kenneth Tilton http://tiltontec.com/

-- Kenneth Tilton http://tiltontec.com/

-- Kenneth Tilton http://tiltontec.com/

-- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

Hi all, This isn't really replying to Pascal specifically -- his was just teh last message I received. I guess none of you pros are also on the music-dsp list out of Columbia, or look around ccrma at Standford much. Why not start with what's already out there for CL? http://ccrma.stanford.edu/planetccrma/software/soundapps.html#SECTION0004240... Neil Gilmore raito@raito.com On 2020-12-02 09:28, Pascal Costanza wrote:

Hi,

I would also consider Go. It’s actually a really good language in my opinion. It’s one of the few “modern” languages that gets lambda expressions correct. (No funky exceptional behavior, you can assign to variables in the lexical environment, and the correct thing happens.)

It has a “general” type called interface{} that holds values of any type. This is not a kludge like in Java, or so, where java.lang.Object holds any object except for “primitive” types, but interface{} actually stores any type. (Including int8, int16, int32, etc., etc., and if I remember correctly, avoids storing on the heap if possible.)

It has an extremely good parallel, concurrent garbage collector that deals well with pretty large heaps. (Up to 256 GB in our experience.)

Variables are stored by value by default (like in C or C++), but are automatically moved to the heap if necessary, for example if you take the address of the variable and pass it around. This avoids major memory issues that you can easily get in C or C++, but remains efficient by default.

The concurrency model is pretty good, and also works well to a large extent for parallel programming. Parallelism is based on a work-stealing scheduler, which are known to be “optimal,” (except if you program against the lowest level of a CPU, but for portable parallelism, work stealing is pretty hard to beat).

When moving our elPrep software away from Common Lisp, we evaluated C++, Go and Java as potential candidates, and Go turned out to provide the best balance between performance and memory use. See https://bmcbioinformatics.biomedcentral.com/articles/10.1186/s12859-019-2903...

We are still using Common Lisp for prototyping, and then translate to Go. These two languages are actually much more similar than it appears at first. For example, dynamic dispatch feels a lot more like generic functions than OOP-style methods. (Methods are defined outside of the corresponding record definitions, and can actually be defined on any type, including your own variants of “primitive” types, which can be extremely handy.)

We also planned to evaluate Rust for elPrep, but Rust didn’t provide type-safe atomic compare-and-swap, at least not back then. This is a deal breaker for an important part of our software. You can cast away the types and express this with “unsafe” types, but that defies the main purpose of using Rust. We also expect that the performance will be equally bad as that of C++, which suffers a lot from the lack of a proper garbage collector. (Details are in the paper.)

Pascal

Sent from my iPad

...

On 2 Dec 2020, at 16:15, Scott McKay <swmckay@gmail.com> wrote:

...

 Rust is C++ done right. At this point, I have several stacks based on what I'm doing: * Web back end – Python/Django * Web front end – Javascript/React * ML/AI (as a "client") – Python * Systems programming – Rust

On Wed, Dec 2, 2020 at 9:57 AM Marco Antoniotti <marco.antoniotti@unimib.it> wrote:

I second what Scott said. Julia is not "fringe" and I am thinking that - too late probably - that is a Very Good Thing (tm)

Apart from that, Rust was described in "Nature". You cannot get more mainstream than that.

Ciao

Marco

PS Me, I am checking out PL/I

On Wed, Dec 2, 2020 at 8:52 AM Scott McKay <swmckay@gmail.com> wrote:

I can't argue with that. My point was, if you're gonna use a fringe language (*), use a _good_ fringe language.

(*) I don't think Julia is "fringe" any more.

On Wed, Dec 2, 2020 at 5:45 AM Bob Cassels <bobcassels@netscape.net> wrote:

Hey Scott,

Go with Julia. It’s enough like Dylan (multi-argument generic function dispatch, expression-oriented, macros), but better in important ways (better type system, package system, better compilation model, cross-language integration).

It has warts (kludgy, messy syntax), but mostly it has traction (active, growing user community, increasing library support, libraries are cutting edge).

If you long for Dylan, Julia is where you want to be. It’s where the smart cool kids are.

Bob

On Jul 7, 2020, at 8:24 AM, Scott McKay <swmckay@gmail.com> wrote:

I cannot hold my tongue on Pyret – why not Dylan? Pyret breaks no new ground, and does not have as good a language designer as Dave Moon. It's macro system can be trivially used to add the test-ish stuff that Pyret puts in its core language.

Dylan remains the best language I've seen that never got traction.

—S

On Tue, Jul 7, 2020 at 4:41 AM Ken Tilton <kentilton@gmail.com> wrote:

Hey, Daniel.

Thanks for the +1, as the kids today say!

Yeah, what we developers deal with must somehow be avoided until the students have felt the thrill of programming, if they will. This programme will not be for everyone. But for those who light up as much over algorithms as they do the music, _then_ we can let them see a two thousand line Clojure backtrace on every error. Grrrr. :)

I like the section contrasting Pyret with other languages that are considered clean syntactically. Pyret makes them look like Java. :) We devs put up with such garbage. One reason I want Clojure or CL for this is because the macros will make it easy to deliver a super friendly yet powerful new music DSL.

Looking at Pyret also reminded me of Logo, another super clean yet powerful language aimed at noobs of any age.

Thx for the Pyret pointer!

-hk

On Mon, Jul 6, 2020 at 11:23 PM Daniel Herring <dherring@tentpost.com> wrote: Hi Ken,

I think music is a great way to engage a wider audience of potential

developers. It has a wider appeal and lower barrier to entry than many other programming activities.

Having seen kids fire up a web browser to do "Scratch programming", I'm convinced that a web-based platform is the most accessible. People can use almost any computer to create accounts, create projects, and share/publish projects. Only seasoned developers are comfortable with the concept of "install this editor, compiler, and Git". :)

Here's an interesting language, though it may not have a audio library yet.

https://www.pyret.org/

- Daniel

On Mon, 6 Jul 2020, Ken Tilton wrote:

...

"actively under development"! Music (sorry) to my ears! The Lisp and ADD genes must overlap seriously. I started one of the videos. Really nice live coding.

I'll make sure our code camp grad school uses CL.

Thx!

-hk

On Mon, Jul 6, 2020 at 8:11 PM Andy Peterson <andy.arvid@gmail.com> wrote: https://github.com/byulparan/cl-collider "A SuperCollider client for CommonLisp"

Never tried this but I've been following it for a few years and it is actively under development.

Andy

On Mon, 6 Jul 2020 at 13:57, Ken Tilton <kentilton@gmail.com> wrote: Thanks for the seconding motion! But part of the plan is high accessibility, and low cost. I just noticed the pricing on OpusModus, bit of a showstopper there.

We would use Clojure Overtone https://overtone.github.io/ but that sits atop Supercollider, not sure if that would make installation a PITA. Ideally we would have sth built atop Web Audio, but then we really are super low-level. I think! Have to look into that.

We would want to hook the students with solid music before taking them down to the basics, so existing effects etc would be great to have, but again, this is about coding in general, not music generation. That is just the hook.

Thx again! If some campers get more turned on by music than coding that will be a great next step.

On Mon, Jul 6, 2020 at 1:43 PM dbm@refined-audiometrics.com <dbm@refined-audiometrics.com> wrote:

Yes, I was also going to suggest OpusModus. I see little purpose in reinventing any portion of what they have done.

I have been a user for about 2 years now. It seems to be the defacto replacement for an earlier product done in Lispworks, from Italy, called Symbolic Composer. OpusModus is very good, and getting better every day. They just implemented live MIDI recording in the latest version.

- David McClain Refined Audiometrics Laboratory, LLC Tucson, AZ, USA refined-audiometrics.com [1]

On Jul 6, 2020, at 8:11 AM, Ken Tilton <kentilton@gmail.com> wrote:

Sounds great, I will keep it in mind if we loosen the web/mobile-native constraint. Or maybe as a direction for campers who take off -- no need then to fret over platform, power will matter.

Thx!

On Mon, Jul 6, 2020 at 10:54 AM Stonewall Ballard <stoney@sb.org> wrote: Ken,

Are you familiar with Opusmodus? <http://opusmodus.com [2]>

It’s written in Clozure ccl, and besides providing an incredible array of music manipulation functions and structures, it’s got a beautiful window system. Mac only.

Your idea of using music as a hook to learn Lisp sounds plausible. Good Luck!

- Stoney ————Stonewall Ballard stoney@sb.org http://stoney.sb.org [3]

On Monday, July 6 at 8:15:31 AM, Ken Tilton (kentilton@gmail.com) wrote:

So I got to thinking about creating an approachable pathway to IT careers for anyone really, but in the spirit of today one focused on creating career opportunities for African Americans.

The idea would be a code camp developed around algorithmic generation of music. I know nothing about music theory, except that there is prolly enough there to introduce most if not all fundamental programming concepts.

For those campers that accidentally get hooked on programming itself, which is how many of us ended up in IT careers, away they go!

The idea is to: * use music as the hook; * defer as long as possible the annoying things about programming (I am looking at you, node.js); * part of that ^^^ will be using a powerful language with the parentheses in the right place, prolly ClojureScript since that could run where JS runs; * keep programming as the focus, as tempting as the music will be. Sonic Pi comes with all sorts of built-in sound capabilities, but we want to develop those in the code camp; * tailor the program to specific musical genres, to maximize the musical hook. I am dropping this here since I know many Common Lispers have a strong musical bent. My questions are: * Could we use CL instead? I do think this almost has to be a web app, perhaps even mobile. Hmmm, we could CL-ify CLJS with sufficent clever macrology. * What do you think? Can a solid programming fundamentals course be expressed in music theory? Hint: HTTP is not a programming fundamental. * If there is any interest, what would be a good place for an ongoing discussion? Google groups? Ideas, comments, suggestions all welcome.

-hk

-- Kenneth Tilton http://tiltontec.com/

-- Kenneth Tilton http://tiltontec.com/

-- Kenneth Tilton http://tiltontec.com/

--

Kenneth Tilton http://tiltontec.com/

--

Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it [4] Viale Sarca 336 I-20126 Milan (MI) ITALY

Links: ------ [1] http://refined-audiometrics.com/ [2] http://opusmodus.com/ [3] http://stoney.sb.org/ [4] http://bimib.disco.unimib.it/

I occupy a very humble position in the Common Lisp community, but FWIW I think it’s reasonable to either include or exclude this discussion from this list. It’s a subject of interest to the CL professional community but it’s more about Lisp or Lisp-like offshoots or alternatives than about CL itself. My only request would be that if this discussion moves elsewhere, I’d like to know where it goes so I can follow it. Best wishes, Laughing Water

On Dec 2, 2020, at 11:40 AM, Dave Cooper <david.cooper@genworks.com> wrote:

May I respectfully suggest that you guys take this non-CL discussion elsewhere than the "professional common lisp" mailing list.

-- My Best,

Dave Cooper, david.cooper@gen.works genworks.com <http://genworks.com/>, gendl.org <http://gendl.org/> +1 248-330-2979

I'll also note that Kenny's initial posting was just trying to drum up interest in this music coding idea from individuals he respects in this mailing list which happens to be a common-lisp one; fair enough. But even Kenny suggested having the actual discussion elsewhere (he suggested google groups) since the topic is broader than the nominal topic of this mailing list. To the extent the discussion here does revolve around CL (e.g. the plug for Opus Modus) then I would say by all means let's keep that part of the discussion here. On Wed, Dec 2, 2020 at 2:57 PM Dave Cooper <david.cooper@genworks.com> wrote:

Well i'm not meaning to be a wet blanket but I'm pretty sure there are plenty of places to discuss "this language is better than that language because of this or that feature" other than a common lisp - specific email list.

It seems self-evident to me that a "professional common lisp" mailing list is meant for those who are working in Common Lisp professionally (either out of necessity or preference), and wish to discuss various tips/tricks/practicalities of continuing to do so. Discussions about how to introduce Common Lisp to youngsters (some of whom may become the next generation of "common lisp professionals") may also be appropriate. But discussions about "hey, let's teach youngsters programming: now let's discuss what non-commonlisp trendy languages are the cool/smart kids using these days so that we (common lisp professional) may put resources into a coding camp or whatever" seem to run counter to any purpose of a mailing list such as this and moreover smacks of a cuckoldish mentality.

Now, if we are discussing other languages from the perspective of "how can we co-opt some of the nice features of these other languages into common lisp through open-source libraries or some future version of the cl standard" then I feel the discussion would be appropriate here. But that does not seem to be the thrust of this current thread (is it?)

I also should display some humility and perhaps my initial comment on this matter was a bit short and haughty; I apologize if it came through that way. After all, I did not establish this list and I'm not sure who did -- if they are still around perhaps they can chime in with an opinion?

I am however associated with the Foundation which runs common-lisp.net which runs this mailing list so I do feel qualified to express an opinion here.

On Wed, Dec 2, 2020 at 2:24 PM Laughing Water <lw@mt.net> wrote:

...

I occupy a very humble position in the Common Lisp community, but FWIW I think it’s reasonable to either include or exclude this discussion from this list. It’s a subject of interest to the CL professional community but it’s more about Lisp or Lisp-like offshoots or alternatives than about CL itself.

My only request would be that if this discussion moves elsewhere, I’d like to know where it goes so I can follow it.

Best wishes, Laughing Water

On Dec 2, 2020, at 11:40 AM, Dave Cooper <david.cooper@genworks.com> wrote:

May I respectfully suggest that you guys take this non-CL discussion elsewhere than the "professional common lisp" mailing list.

-- My Best,

Dave Cooper, david.cooper@gen.works genworks.com, gendl.org +1 248-330-2979

-- My Best,

Dave Cooper, david.cooper@gen.works genworks.com, gendl.org +1 248-330-2979

-- My Best, Dave Cooper, david.cooper@gen.works genworks.com, gendl.org +1 248-330-2979

Where else do Common Lispers go to talk shop, whether CL or something else? To me, Common Lispers "talking shop" by definition means talking about CL or related topics, not an open-ended "something else." I would turn that question around and ask "where else do Common Lispers go for unapologetic mutual support for their chosen or imposed computing platform, which is Common Lisp?" If groups such as this mailing list become diluted with hand wringing, naysaying, and negativity, then you tell me Tim, where do actual Common Lispers go? CL is very good but it is not perfect. Debating the relative merits of

various languages can lead to cross-pollination of ideas. It appears that most innovation is happening elsewhere, and I hope this community can bring the best of CL into a worthy successor, whatever it may be called.

If "most innovation is happening elsewhere" then those of us who have the propensity to look into other languages can serve the community here by reporting back the cool things they find and discussing how we may or may not be able to co-opt such things into CL. If such is the perspective and purpose of "debating the merits of various languages," then indeed, such debate can result in productive cross-pollination, and this is needed and wanted. If the intention and focus is instead to sing the praises of other environments in order to seek fellow converts or validation for converting, and doing this while specifically targeting a group set up to support "professional common lispers," then I consider such efforts to be unhelpful in the context of this group and I would invite you to take such discussions into the forums of those other environments or into some general language discussion forums. Understand that not all of us have the "luxury" on the one hand, nor the desire on the other hand, to chase the dragon of the latest cool thing, and we look to groups such as this one specifically to support our crusty old entrenched mentality -- and to improve our environment as best we can, understanding the inherent limitations that exist. This is the life we have chosen.

In my opinion, prototyping in Common Lisp, and then translating to a different programming language for creating the final product, is a perfectly valid professional use of Common Lisp. It’s useful to know which programming languages may be good targets for such an approach. This is, of course, not ideal, because this can easily be misunderstood as a statement that Common Lisp is not fit for purpose. However, I don’t see it that way, and you cannot control people’s perceptions. In our particular case, our manager is on board with this approach, and this allows us to pay for regular licenses for LispWorks. The approach works really well for us. Pascal Sent from my iPad

On 3 Dec 2020, at 05:29, Dave Cooper <david.cooper@genworks.com> wrote:



...

Where else do Common Lispers go to talk shop, whether CL or something else?

To me, Common Lispers "talking shop" by definition means talking about CL or related topics, not an open-ended "something else." I would turn that question around and ask "where else do Common Lispers go for unapologetic mutual support for their chosen or imposed computing platform, which is Common Lisp?" If groups such as this mailing list become diluted with hand wringing, naysaying, and negativity, then you tell me Tim, where do actual Common Lispers go?

...

CL is very good but it is not perfect. Debating the relative merits of various languages can lead to cross-pollination of ideas. It appears that most innovation is happening elsewhere, and I hope this community can bring the best of CL into a worthy successor, whatever it may be called.

If "most innovation is happening elsewhere" then those of us who have the propensity to look into other languages can serve the community here by reporting back the cool things they find and discussing how we may or may not be able to co-opt such things into CL. If such is the perspective and purpose of "debating the merits of various languages," then indeed, such debate can result in productive cross-pollination, and this is needed and wanted.

If the intention and focus is instead to sing the praises of other environments in order to seek fellow converts or validation for converting, and doing this while specifically targeting a group set up to support "professional common lispers," then I consider such efforts to be unhelpful in the context of this group and I would invite you to take such discussions into the forums of those other environments or into some general language discussion forums.

Understand that not all of us have the "luxury" on the one hand, nor the desire on the other hand, to chase the dragon of the latest cool thing, and we look to groups such as this one specifically to support our crusty old entrenched mentality -- and to improve our environment as best we can, understanding the inherent limitations that exist. This is the life we have chosen.

I’m very curious about this, too. —Scott

On Dec 3, 2020, at 6:19 AM, Svante Carl v. Erichsen <svante.v.erichsen@web.de> wrote:

So, if it's not because Common Lisp is not seen as “production ready”, why rewrite instead of just adding the production parts (I guess hardening, monitoring, logging, documentation etc.)?

Super interesting, thanks for that! —S On Thu, Dec 3, 2020 at 8:00 AM Pascal Costanza <pc@p-cos.net> wrote:

This was primarily for the lack of good parallel, concurrent garbage collectors in Common Lisp implementations. The CL version of elPrep was actually still a tad faster than any of the C++, Go, or Java versions, but we had to work hard to avoid long GC pauses. elPrep allocates a lot of memory, and the pause time hurts a lot. We solved this by, basically, disabling the garbage collector, and reusing memory manually as much as possible, which turned the program into almost a manually memory-managed affair.

Manual memory management became a huge burden because we wanted to add more and more components to the software, and then it becomes almost impossible to predict object lifetimes.

We evaluated Go and Java for their concurrent, parallel GCs, and C++ for its reference counting. Interestingly, reference counting is often described as more efficient than GC, but in our case that’s not true: Because there is a huge object graph at some stage that needs to be deallocated, reference counting incurs more or less the same pause that a non-concurrent GC does. That’s why we don’t expect Rust to fare better here either.

Again, we’re still prototyping in Common Lisp, which is a huge win, because this makes us much more productive.

Pascal

...

On 3 Dec 2020, at 12:16, Svante Carl v. Erichsen < svante.v.erichsen@web.de> wrote:

Hi!

I vaguely remember having read that you do that. I'm still wondering why, though. I guess that you wrote about it, but I can't find it right now.

So, if it's not because Common Lisp is not seen as “production ready”, why rewrite instead of just adding the production parts (I guess hardening, monitoring, logging, documentation etc.)?

Yours aye

Svante

Pascal Costanza writes:

...

In my opinion, prototyping in Common Lisp, and then translating to a different programming language for creating the final product, is a perfectly valid professional use of Common Lisp. It’s useful to know which programming languages may be good targets for such an approach.

This is, of course, not ideal, because this can easily be misunderstood as a statement that Common Lisp is not fit for purpose. However, I don’t see it that way, and you cannot control people’s perceptions.

In our particular case, our manager is on board with this approach, and this allows us to pay for regular licenses for LispWorks. The approach works really well for us.

Pascal

Sent from my iPad

...

On 3 Dec 2020, at 05:29, Dave Cooper <david.cooper@genworks.com> wrote:



...

Where else do Common Lispers go to talk shop, whether CL or something else?

To me, Common Lispers "talking shop" by definition means talking about CL or related topics, not an open-ended "something else." I would turn that question around and ask "where else do Common Lispers go for unapologetic mutual support for their chosen or imposed computing platform, which is Common Lisp?" If groups such as this mailing list become diluted with hand wringing, naysaying, and negativity, then you tell me Tim, where do actual Common Lispers go?

...

CL is very good but it is not perfect. Debating the relative merits of various languages can lead to cross-pollination of ideas. It appears that most innovation is happening elsewhere, and I hope this community can bring the best of CL into a worthy successor, whatever it may be called.

If "most innovation is happening elsewhere" then those of us who have the propensity to look into other languages can serve the community here by reporting back the cool things they find and discussing how we may or may not be able to co-opt such things into CL. If such is the perspective and purpose of "debating the merits of various languages," then indeed, such debate can result in productive cross-pollination, and this is needed and wanted.

If the intention and focus is instead to sing the praises of other environments in order to seek fellow converts or validation for converting, and doing this while specifically targeting a group set up to support "professional common lispers," then I consider such efforts to be unhelpful in the context of this group and I would invite you to take such discussions into the forums of those other environments or into some general language discussion forums.

Understand that not all of us have the "luxury" on the one hand, nor the desire on the other hand, to chase the dragon of the latest cool thing, and we look to groups such as this one specifically to support our crusty old entrenched mentality -- and to improve our environment as best we can, understanding the inherent limitations that exist. This is the life we have chosen.

-- Pascal Costanza

How automatic (or not) is the translation to Go? Have you built some manner translator on either the CL side or the Go side?

/s/manner translator/manner of translator/

This was primarily for the lack of good parallel, concurrent garbage collectors in Common Lisp implementations.

ABCL on the JVM works pretty good these days. It’s not as fast as SBCL, but much more robust from a runtime (and GC) perspective. Manfred

Am 03.12.2020 um 13:57 schrieb Pascal Costanza <pc@p-cos.net>:

This was primarily for the lack of good parallel, concurrent garbage collectors in Common Lisp implementations. The CL version of elPrep was actually still a tad faster than any of the C++, Go, or Java versions, but we had to work hard to avoid long GC pauses. elPrep allocates a lot of memory, and the pause time hurts a lot. We solved this by, basically, disabling the garbage collector, and reusing memory manually as much as possible, which turned the program into almost a manually memory-managed affair.

Manual memory management became a huge burden because we wanted to add more and more components to the software, and then it becomes almost impossible to predict object lifetimes.

We evaluated Go and Java for their concurrent, parallel GCs, and C++ for its reference counting. Interestingly, reference counting is often described as more efficient than GC, but in our case that’s not true: Because there is a huge object graph at some stage that needs to be deallocated, reference counting incurs more or less the same pause that a non-concurrent GC does. That’s why we don’t expect Rust to fare better here either.

Again, we’re still prototyping in Common Lisp, which is a huge win, because this makes us much more productive.

Pascal

...

On 3 Dec 2020, at 12:16, Svante Carl v. Erichsen <svante.v.erichsen@web.de> wrote:

Hi!

I vaguely remember having read that you do that. I'm still wondering why, though. I guess that you wrote about it, but I can't find it right now.

So, if it's not because Common Lisp is not seen as “production ready”, why rewrite instead of just adding the production parts (I guess hardening, monitoring, logging, documentation etc.)?

Yours aye

Svante

Pascal Costanza writes:

...

In my opinion, prototyping in Common Lisp, and then translating to a different programming language for creating the final product, is a perfectly valid professional use of Common Lisp. It’s useful to know which programming languages may be good targets for such an approach.

This is, of course, not ideal, because this can easily be misunderstood as a statement that Common Lisp is not fit for purpose. However, I don’t see it that way, and you cannot control people’s perceptions.

In our particular case, our manager is on board with this approach, and this allows us to pay for regular licenses for LispWorks. The approach works really well for us.

Pascal

Sent from my iPad

...

On 3 Dec 2020, at 05:29, Dave Cooper <david.cooper@genworks.com> wrote:



...

Where else do Common Lispers go to talk shop, whether CL or something else?

To me, Common Lispers "talking shop" by definition means talking about CL or related topics, not an open-ended "something else." I would turn that question around and ask "where else do Common Lispers go for unapologetic mutual support for their chosen or imposed computing platform, which is Common Lisp?" If groups such as this mailing list become diluted with hand wringing, naysaying, and negativity, then you tell me Tim, where do actual Common Lispers go?

...

CL is very good but it is not perfect. Debating the relative merits of various languages can lead to cross-pollination of ideas. It appears that most innovation is happening elsewhere, and I hope this community can bring the best of CL into a worthy successor, whatever it may be called.

If "most innovation is happening elsewhere" then those of us who have the propensity to look into other languages can serve the community here by reporting back the cool things they find and discussing how we may or may not be able to co-opt such things into CL. If such is the perspective and purpose of "debating the merits of various languages," then indeed, such debate can result in productive cross-pollination, and this is needed and wanted.

If the intention and focus is instead to sing the praises of other environments in order to seek fellow converts or validation for converting, and doing this while specifically targeting a group set up to support "professional common lispers," then I consider such efforts to be unhelpful in the context of this group and I would invite you to take such discussions into the forums of those other environments or into some general language discussion forums.

Understand that not all of us have the "luxury" on the one hand, nor the desire on the other hand, to chase the dragon of the latest cool thing, and we look to groups such as this one specifically to support our crusty old entrenched mentality -- and to improve our environment as best we can, understanding the inherent limitations that exist. This is the life we have chosen.

-- Pascal Costanza

Perhaps this will change with a future JVM with Value Types and with a future ABCL making use of them, but at the moment, that's the sad story. On Thu, 3 Dec 2020 at 15:51, Pascal Costanza <pc@p-cos.net> wrote:

We tested an implementation in Java, and the memory footprint of the JVM is huge. Where C++, Common Lisp, and Go could comfortably run in below 256 GB RAM, Java needed more like 350-400 GB RAM. That was not a good tradeoff. I don’t expect an implementation in ABCL to solve this (which is not ABCL’s problem, but a problem of the JVM).

Pascal

...

On 3 Dec 2020, at 14:47, Manfred Bergmann <manfred.bergmann@me.com> wrote:

...

This was primarily for the lack of good parallel, concurrent garbage

collectors in Common Lisp implementations. > > ABCL on the JVM works pretty good these days. > It’s not as fast as SBCL, but much more robust from a runtime (and GC) perspective. > > > Manfred > > >> Am 03.12.2020 um 13:57 schrieb Pascal Costanza &lt;pc@p-cos.net>: >> >> This was primarily for the lack of good parallel, concurrent garbage collectors in Common Lisp implementations. The CL version of elPrep was actually still a tad faster than any of the C++, Go, or Java versions, but we had to work hard to avoid long GC pauses. elPrep allocates a lot of memory, and the pause time hurts a lot. We solved this by, basically, disabling the garbage collector, and reusing memory manually as much as possible, which turned the program into almost a manually memory-managed affair. >> >> Manual memory management became a huge burden because we wanted to add more and more components to the software, and then it becomes almost impossible to predict object lifetimes. >> >> We evaluated Go and Java for their concurrent, parallel GCs, and C++ for its reference counting. Interestingly, reference counting is often described as more efficient than GC, but in our case that’s not true: Because there is a huge object graph at some stage that needs to be deallocated, reference counting incurs more or less the same pause that a non-concurrent GC does. That’s why we don’t expect Rust to fare better here either. >> >> Again, we’re still prototyping in Common Lisp, which is a huge win, because this makes us much more productive. >> >> Pascal >> >>> On 3 Dec 2020, at 12:16, Svante Carl v. Erichsen &lt; svante.v.erichsen@web.de> wrote: >>> >>> Hi! >>> >>> I vaguely remember having read that you do that. I'm still wondering >>> why, though. I guess that you wrote about it, but I can't find it right >>> now. >>> >>> So, if it's not because Common Lisp is not seen as “production ready”, >>> why rewrite instead of just adding the production parts (I guess >>> hardening, monitoring, logging, documentation etc.)? >>> >>> Yours aye >>> >>> Svante >>> >>> >>> Pascal Costanza writes: >>> >>>> In my opinion, prototyping in Common Lisp, and then translating to a >>>> different programming language for creating the final product, is a >>>> perfectly valid professional use of Common Lisp. It’s useful to know >>>> which programming languages may be good targets for such an approach. >>>> >>>> This is, of course, not ideal, because this can easily be >>>> misunderstood as a statement that Common Lisp is not fit for >>>> purpose. However, I don’t see it that way, and you cannot control >>>> people’s perceptions. >>>> >>>> In our particular case, our manager is on board with this approach, >>>> and this allows us to pay for regular licenses for LispWorks. The >>>> approach works really well for us. >>>> >>>> Pascal >>>> >>>> Sent from my iPad >>>> >>>>> On 3 Dec 2020, at 05:29, Dave Cooper &lt;david.cooper@genworks.com> wrote: >>>>> >>>>>  >>>>> >>>>>> Where else do Common Lispers go to talk shop, whether CL or something else? >>>>> >>>>> >>>>> To me, Common Lispers "talking shop" by definition means talking about CL or related topics, not an open-ended "something else." I would turn that question around and ask "where else do Common Lispers go for unapologetic mutual support for their chosen or imposed computing platform, which is Common Lisp?" If groups such as this mailing list become diluted with hand wringing, naysaying, and negativity, then you tell me Tim, where do actual Common Lispers go? >>>>> >>>>> >>>>>> CL is very good but it is not perfect. Debating the relative merits of >>>>>> various languages can lead to cross-pollination of ideas. It appears that >>>>>> most innovation is happening elsewhere, and I hope this community can >>>>>> bring the best of CL into a worthy successor, whatever it may be called. >>>>>> >>>>> >>>>> If "most innovation is happening elsewhere" then those of us who have the propensity to look into other languages can serve the community here by reporting back the cool things they find and discussing how we may or may not be able to co-opt such things into CL. If such is the perspective and purpose of "debating the merits of various languages," then indeed, such debate can result in productive cross-pollination, and this is needed and wanted. >>>>> >>>>> If the intention and focus is instead to sing the praises of other environments in order to seek fellow converts or validation for converting, and doing this while specifically targeting a group set up to support "professional common lispers," then I consider such efforts to be unhelpful in the context of this group and I would invite you to take such discussions into the forums of those other environments or into some general language discussion forums. >>>>> >>>>> Understand that not all of us have the "luxury" on the one hand, nor the desire on the other hand, to chase the dragon of the latest cool thing, and we look to groups such as this one specifically to support our crusty old entrenched mentality -- and to improve our environment as best we can, understanding the inherent limitations that exist. This is the life we have chosen. >>>>> >>>>> >>> >>> >> >> -- >> Pascal Costanza >> >> >> > >

-- Pascal Costanza

Pascal Costanza wrote:

This was primarily for the lack of good parallel, concurrent garbage collectors in Common Lisp implementations.

I'd be curious to know if there are particularities in CL itself that make this difficult, or if it's simply because there's no manpower to improve the GCs we have currently. -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info

Didier Verna wrote on Thu, Dec 03, 2020 at 03:47:02PM +0100:

Pascal Costanza wrote:

...

This was primarily for the lack of good parallel, concurrent garbage collectors in Common Lisp implementations.

I'd be curious to know if there are particularities in CL itself that make this difficult, or if it's simply because there's no manpower to improve the GCs we have currently.

No, it's as possible as in other languages. Some people don't want to pay the overall performance penalty for concurrent GC (as in total CPU time/energy spent for any given piece of work). This particularly applies to applications that are query-based, and hence want to be as fast as possible in the non-GC part, and can GC between queries. ITA's QPX is an example (although they do desire concurrent GC for better monitoring in the production environment). Parallel GC is no problem and implemented. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/

From Franz's doc on Allegro CL

https://franz.com/support/documentation/10.0/doc/gc.htm#multi-threading-2 On Thu, Dec 3, 2020, 10:29 Pascal Costanza <pc@p-cos.net> wrote:

...

Parallel GC is no problem and implemented.

Which CL implementations have a parallel GC?

Pascal

-- Pascal Costanza

Don't the latest incarnations of ECL use the Bohem GC? Just asking... MA Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: pro <pro-bounces@common-lisp.net> on behalf of Martin Cracauer <cracauer@cons.org> Sent: Thursday, December 3, 2020 6:25:50 PM To: Discussion list for Common Lisp professionals <pro@common-lisp.net> Subject: Re: Call for Interest: Clojure (or Lisp?) Code Camp with BLM focus Pascal Costanza wrote on Thu, Dec 03, 2020 at 04:17:56PM +0100:

...

Parallel GC is no problem and implemented.

Which CL implementations have a parallel GC?

Clasp (via Boehm GC and MPS). I thought SBCL was there, but I just checked, not yet. I think Google is pushing for a parallel GC instead, because of response times to their production monitoring. Another untapped source of performance is userfaultfd(2) in the Linux kernel. It allows those GCs that implement a write barrier using page protections SIGSEGV to use the faster userfaultfd interface instead (as opposed to those using a bitmap). This won't help concurrent GC, but parallel GC would benefit even more than single-thread GC because it uses faster system calls. Proof of concept is here: https://www.cons.org/cracauer/cracauer-userfaultfd.html Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/

Pascal Costanza wrote:

...

...

Parallel GC is no problem and implemented.

Which CL implementations have a parallel GC?

I'm a little late to the conversation, but we have been experimenting with a multi-threaded garbage collector that runs mostly in parallel with the lisp application code. The collector uses a mark-sweep algorithm in which the application code runs in parallel with the collector except for a few brief pauses. Application threads must pause briefly during the mark phase to allow references in their active frames to be recorded. This pause is relatively short. Our current test system, heavily instrumented for validation and performance-measurement purposes, and using just one thread for the marking, is showing typical pauses for this initial stack scan under 1 msec. After these initial references are collected, the application threads run while the marker follows all references to produce a live-object map that is almost correct. With that initial map complete, all threads are stopped briefly to collect any new references and add them to the map. In our test system these reconciliation pauses are typically under 15 msecs and almost always under 25 msec. After the live map has been completed, the application threads are released to continue processing while the collector scans the live map, collecting the storage occupied by dead objects into free pools. Once this is done, the collector can cycle back to do a new mark phase. While we are currently testing the marker running on just one thread, the code is essentially the same as the multi-threaded global gc Allegro has had for several years now. The number of threads used by the marker is a configurable option; experience suggests we can cut the pause times in half by using three or four threads. Mark-sweep collectors can be subject to storage fragmentation. Memory is divided into areas each of which holds objects of one size. As objects leave the live set, their storage is collected into pools according to size. When several areas holding objects of the same size become partially free, it can be useful to relocate live objects from some of those areas into the others, reducing the memory footprint of the live set and making the abandoned area available for objects of some other size. Once the mark phase is complete, we have enough information to recognize areas that could benefit from this sort of reorganization. In order to move an object, however, we must adjust all pointers to that object. This can only be done while all the application threads are paused, and in order to keep application pauses short, it's essential that we find all the in-heap references to those objects without having to scan the entire heap. Fortunately, the mark phase can do the work for us, providing us with a map of those areas holding references to one of the objects we wish to relocate. At the end of the second pause-the-application-threads mark phase, we can see how much time we've kept the application inactive, and estimate how much time it will take to fix the pointers to the objects we want to move. If the pase so far plus the estimated additional time is less than a settable amount, we can perform the relocation and reap the benefits. If not, we can check again next time. Current efforts revolve around global optimization and the proper set of user-visible controls and reports to help optimize performance. The goal of the concurrent gc is to let us apply some of the extra memory and cpu power available in today's machines toward elimination of the lengthy and unpredictable gc pauses that can make lisp unattractive to human users. Real-time response isn't achieved, and isn't the goal. I know people will want to know when it's going to be released, but we don't currently have a release date set. Kevin Layer

Pascal discussed "... the lack of good parallel, concurrent garbage collectors in Common Lisp implementations". We were using Lispworks 7 and retrieving lots of data via Oracle's SQL driver prior to building the application. I introduced multi-thread parallelism, attempting to reduce overall time. The times were the same. I then tried multi-image parallelism and total wall time was cut by half for two parallel images, to one third for three, and close to one fourth for four. That was the number of CPUs our build system had. The single-threaded processes were CPU bound. I didn't experiment further to localize the bottleneck. I was thinking of a global lock around allocating memory on the heap or a GC issue. (Surely each thread could run on its own CPU?) I used multiple parallel images to write Lisp data structures in key/value stores to disk or to generate Lisp code from the data to incorporate in the application build. The application's run time was blazingly fast, albeit in single-threaded mode. Clearly, not every application can take advantage of those techniques. Jeff On Thu, Dec 3, 2020 at 7:58 AM Pascal Costanza <pc@p-cos.net> wrote:

This was primarily for the lack of good parallel, concurrent garbage collectors in Common Lisp implementations. The CL version of elPrep was actually still a tad faster than any of the C++, Go, or Java versions, but we had to work hard to avoid long GC pauses. elPrep allocates a lot of memory, and the pause time hurts a lot. We solved this by, basically, disabling the garbage collector, and reusing memory manually as much as possible, which turned the program into almost a manually memory-managed affair.

Manual memory management became a huge burden because we wanted to add more and more components to the software, and then it becomes almost impossible to predict object lifetimes.

We evaluated Go and Java for their concurrent, parallel GCs, and C++ for its reference counting. Interestingly, reference counting is often described as more efficient than GC, but in our case that’s not true: Because there is a huge object graph at some stage that needs to be deallocated, reference counting incurs more or less the same pause that a non-concurrent GC does. That’s why we don’t expect Rust to fare better here either.

Again, we’re still prototyping in Common Lisp, which is a huge win, because this makes us much more productive.

Pascal

...

On 3 Dec 2020, at 12:16, Svante Carl v. Erichsen <svante.v.erichsen@web.de> wrote:

Hi!

I vaguely remember having read that you do that. I'm still wondering why, though. I guess that you wrote about it, but I can't find it right now.

So, if it's not because Common Lisp is not seen as “production ready”, why rewrite instead of just adding the production parts (I guess hardening, monitoring, logging, documentation etc.)?

Yours aye

Svante

Pascal Costanza writes:

...

In my opinion, prototyping in Common Lisp, and then translating to a different programming language for creating the final product, is a perfectly valid professional use of Common Lisp. It’s useful to know which programming languages may be good targets for such an approach.

This is, of course, not ideal, because this can easily be misunderstood as a statement that Common Lisp is not fit for purpose. However, I don’t see it that way, and you cannot control people’s perceptions.

In our particular case, our manager is on board with this approach, and this allows us to pay for regular licenses for LispWorks. The approach works really well for us.

Pascal

Sent from my iPad

...

On 3 Dec 2020, at 05:29, Dave Cooper <david.cooper@genworks.com> wrote:



...

Where else do Common Lispers go to talk shop, whether CL or something else?

To me, Common Lispers "talking shop" by definition means talking about CL or related topics, not an open-ended "something else." I would turn that question around and ask "where else do Common Lispers go for unapologetic mutual support for their chosen or imposed computing platform, which is Common Lisp?" If groups such as this mailing list become diluted with hand wringing, naysaying, and negativity, then you tell me Tim, where do actual Common Lispers go?

...

CL is very good but it is not perfect. Debating the relative merits of various languages can lead to cross-pollination of ideas. It appears that most innovation is happening elsewhere, and I hope this community can bring the best of CL into a worthy successor, whatever it may be called.

If "most innovation is happening elsewhere" then those of us who have the propensity to look into other languages can serve the community here by reporting back the cool things they find and discussing how we may or may not be able to co-opt such things into CL. If such is the perspective and purpose of "debating the merits of various languages," then indeed, such debate can result in productive cross-pollination, and this is needed and wanted.

If the intention and focus is instead to sing the praises of other environments in order to seek fellow converts or validation for converting, and doing this while specifically targeting a group set up to support "professional common lispers," then I consider such efforts to be unhelpful in the context of this group and I would invite you to take such discussions into the forums of those other environments or into some general language discussion forums.

Understand that not all of us have the "luxury" on the one hand, nor the desire on the other hand, to chase the dragon of the latest cool thing, and we look to groups such as this one specifically to support our crusty old entrenched mentality -- and to improve our environment as best we can, understanding the inherent limitations that exist. This is the life we have chosen.

-- Pascal Costanza

Svante Carl v. Erichsen wrote on Thu, Dec 03, 2020 at 12:16:09PM +0100:

Hi!

I vaguely remember having read that you do that. I'm still wondering why, though. I guess that you wrote about it, but I can't find it right now.

So, if it's not because Common Lisp is not seen as ???production ready???, why rewrite instead of just adding the production parts (I guess hardening, monitoring, logging, documentation etc.)?

There can be large amounts of infrastructure for specific production environments. QPX integration into Google was probably an extreme case. It was still done, because treating the Lisp version of QPX as a "prototype" to then be translated into a different language would effectively mean taking the macroexpansion of QPX and commit that as source code. That would mean extreme amounts of "assumption duplication", assumptions that in the airline industry are badly documented and can change. You want to make that change in one place, not in the macroexpansion where it's in 200 places. That doesn't mean there wasn't a large push to avoid the effort to come up with all the infrastructure integration for Common Lisp. Ironically ITA people could fork those out pretty quickly because they were using Lisp. If you are not in the airline business but in an environment where you don't have to make assumptions during programming that you might have to change later you might be freer to use a language without compile-time computing. I've never seen good specs before I started coding, though, not even in physics. We know nothing. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/

I just spotted this during some perusing… IRCAM, in Paris, France, develops lots of different tools for avant garde music creation. They have this thing called OpenMusic, very simiilar to Max. But in the lower right of the page they have our mascot… http://repmus.ircam.fr/openmusic/home <http://repmus.ircam.fr/openmusic/home> - DM