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
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 http://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 mailto:stoney@sb.org> wrote: Ken,
Are you familiar with Opusmodus? <http://opusmodus.com 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 mailto:stoney@sb.org http://stoney.sb.org http://stoney.sb.org/ On Monday, July 6 at 8:15:31 AM, Ken Tilton (kentilton@gmail.com mailto: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/ http://tiltontec.com/
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/
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/
"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 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.
- 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%C2%A0%22A 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/%C2%A0but 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/
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.
- 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 clientfor 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 purposein 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.
- 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 clientfor 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 purposein 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/
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
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
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 mailto: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 mailto: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/ 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 mailto:andy.arvid@gmail.com> wrote: https://github.com/byulparan/cl-collider 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 mailto: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/ 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 mailto:dbm@refined-audiometrics.com <dbm@refined-audiometrics.com mailto: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 http://refined-audiometrics.com/
On Jul 6, 2020, at 8:11 AM, Ken Tilton <kentilton@gmail.com <mailto: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 mailto:stoney@sb.org> wrote: Ken,
Are you familiar with Opusmodus? <http://opusmodus.com 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 mailto:stoney@sb.org http://stoney.sb.org http://stoney.sb.org/
On Monday, July 6 at 8:15:31 AM, Ken Tilton (kentilton@gmail.com mailto: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/ http://tiltontec.com/
-- Kenneth Tilton http://tiltontec.com/ http://tiltontec.com/
-- Kenneth Tilton http://tiltontec.com/ http://tiltontec.com/
-- Kenneth Tilton http://tiltontec.com/ http://tiltontec.com/
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.
- 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 SuperColliderclient 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 purposein 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/
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.
- 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 SuperColliderclient 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 littlepurpose 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.
- 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 SuperColliderclient 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 littlepurpose 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,
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 > > > > > > 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.
- 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
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/
May I respectfully suggest that you guys take this non-CL discussion elsewhere than the "professional common lisp" mailing list.
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
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
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
On Wed, 2 Dec 2020, Laughing Water wrote:
My only request would be that if this discussion moves elsewhere, I’d like to know where it goes so I can follow it.
I'll second that. I really value the experience and opinions of this community, and appreciate the occasional random news update. Where else do Common Lispers go to talk shop, whether CL or something else?
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.
- Daniel
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.
then you tell me Tim, where do actual Common Lispers go?
you tell me Dan* (sorry, not sure where Tim came from -- I think I got you confused with someone else who also resigned from the ALU board years ago).
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.
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.
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.)?
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
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
On Thu, Dec 3, 2020 at 7:59 AM Pascal Costanza pc@p-cos.net wrote:
This was primarily for the lack of good parallel, concurrent garbage collectors in Common Lisp implementations.
Thanks for the interesting explanation.
How automatic (or not) is the translation to Go? Have you built some manner translator on either the CL side or the Go side?
On 3 Dec 2020, at 14:24, Dave Cooper david.cooper@genworks.com wrote:
On Thu, Dec 3, 2020 at 7:59 AM Pascal Costanza <pc@p-cos.net mailto:pc@p-cos.net> wrote: This was primarily for the lack of good parallel, concurrent garbage collectors in Common Lisp implementations.
Thanks for the interesting explanation.
How automatic (or not) is the translation to Go? Have you built some manner translator on either the CL side or the Go side?
We do this by hand.
Pascal
-- Pascal Costanza
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
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 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
-- 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 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
-- Pascal Costanza
I've used ABCL very happily as a high-level way to script the JVM, and also as a good way to explore what's going on in a big Java program, using the REPL.
But for the AI planner I maintain and develop (GitHub.com/shop-planner), ABCL simply won't function: it's wildly too slow compared with SBCL, Allegro, and CCL. I can't get it to run the test suite (ECL can't do it, either).
Also, I suspect that the inability to do tail call optimization means that idiomatic CL code behaves very poorly on ABCL (which is the fault of the JVM, not ABCL itself).
I wouldn't recommend ABCL as other than a tool to work with artifacts that already live on the JVM. As a "primary" CL it just does not perform well enough.
On 3 Dec 2020, at 8:55, Alessio Stalla wrote:
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 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
-- Pascal Costanza
Robert P. Goldman Research Fellow Smart Information Flow Technologies (d/b/a SIFT, LLC)
319 N. First Ave., Suite 400 Minneapolis, MN 55401
Voice: (612) 326-3934 Email: rpgoldman@SIFT.net
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.
On 3 Dec 2020, at 15:47, Didier Verna didier@lrde.epita.fr wrote:
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.
I don’t believe there is anything in CL that would prevent it from having a good concurrent, parallel garbage collector. One argument I’m hearing in favor of Go is that it has value semantics by default, which suggests that most objects are stored on the stack, but on the other hand, we have dynamic-extent declarations. Some of the detailed trade-offs might be somewhat different, but I don’t think there are any serious showstoppers.
But I’m not even remotely a GC expert, so I’m just guessing here.
Pascal
-- Pascal Costanza
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
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
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
Don't the latest incarnations of ECL use the Bohem GC?
Just asking...
MA
Get Outlook for Androidhttps://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/
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, 3 December 2020 19:28, Marco Antoniotti marco.antoniotti@unimib.it wrote:
Don't the latest incarnations of ECL use the Bohem GC?
They do, we plan to resurrect the homegrown gc as an alternative though.
Regards, Daniel
Just asking...
MA
Get Outlook for Android
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 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.
It's strictly a lack of manpower. Most CL implementations have GCs that were state-of-the-art 25 years ago: they're either mark-and-sweep or copying & generational, and have to perform all collection while application threads are paused (i.e. stop-the-world), hence the collection pauses that are proportional to the heap size.
The newer GCs of Go and the JVM (ZGC and Shenandoah) are not generational and employ techniques such as pointer coloring and store/load barriers by instrumenting all object read/write operations instead of using virtual memory protection (which tends to have a non-indifferent performance penalty), and because they rely heavily on atomic operations to maintain heap consistency the stop-the-world phase is much shorter and only required to update the internal GC metadata. The result is that instead of 99th percentile pauses of 10+ seconds that we see with QPX or other allocation-heavy applications, these newer GCs show 99th percentile pauses of < 10ms, and perhaps medians going from ~500ms to 2ms (YMMV).
Here's a pretty good description of the difference between the two new JVM collectors and how they compare to the older ones: https://www.youtube.com/watch?v=WU_mqNBEacw.
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
Den tors 3 dec. 2020 20:58Pascal Costanza pc@p-cos.net skrev:
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.
I'm surprised that you seem to acknowledge the myth that refcounting is somehow more efficient in any way compared to a good GC.
Refcounting suffers from a worst-of-both-worlds situation where both allocations and release operations are potentially slow. Allocations need to scan the allocation tree for free memory, and upon release it has to again search the tree to determine where to record it. And that's not even mentioning the overhead during pointer handoff.
A GC language by contrast can optimise allocations down to a single instruction, zero instructions for release and no overhead for pointer transfer.
In practice, when comparing heap memory allocation between Java and C++ the former readily beats the latter. C++ code may still be faster due to the fact that it can often avoid heap allocations altogether by storing things on the stack. C++ developers also go to great length to avoid using reference counting as well.
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
In every case I've been involved in, 'not fit for purpose' was a dog whistle for 'I don't know or understand it, and/or I'm too stupid to learn anything new'.
Neil Gilmore raito@raito.com
On 2020-12-03 02:01, Pascal Costanza wrote:
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.
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
-
Alessio Stalla -
Andy Peterson -
Bob Cassels -
Daniel Herring -
Daniel Kochmański -
Dave Cooper -
dbm＠refined-audiometrics.com -
Didier Verna -
Elias Mårtenson -
Jeff Caldwell -
Ken Tilton -
Kevin Layer -
Laughing Water -
Manfred Bergmann -
Marco Antoniotti -
Martin Cracauer -
Neil Gilmore -
Pascal Costanza -
Robert Goldman -
Scott McKay -
Stelian Ionescu -
Svante Carl v. Erichsen