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-5
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 <swmc...@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.antonio...@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 <swmc...@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 <bobcass...@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 <swmc...@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 <kentil...@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 <dherr...@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.ar...@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 <kentil...@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 d...@refined-audiometrics.com
>>>>>>> > <d...@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 <kentil...@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 <sto...@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 sto...@sb.org http://stoney.sb.org
>>>>>>> >
>>>>>>> > On Monday, July 6 at 8:15:31 AM, Ken Tilton (kentil...@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
