4 ms·

Any info on the motivation for making an entire language instead of a library for an existing language (e.g. for C, Python, or Go)? Especially if the syntax mi

by jchook 7y ago

Any info on the motivation for making an entire language instead of a library for an existing language (e.g. for C, Python, or Go)? Especially if the syntax mimics C-like languages, what important advantages do we get?

tomduncalf 7y ago
The overview at https://github.com/soul-lang/SOUL/blob/master/docs/SOUL_Overview.md https://github.com/soul-lang/SOUL/blob/master/docs/SOUL_Over... should help explain the motivation. I’m sure Jules can elaborate further :)
julesrms 7y ago
We pre-emptively answered this inevitable question in the overview doc: https://github.com/soul-lang/SOUL/blob/master/docs/SOUL_Overview.md https://github.com/soul-lang/SOUL/blob/master/docs/SOUL_Over... The main TL;DRs are: - this needs to get JITed to compete with C++ performance, so dynamic and interpreted languages are out. - it needs to stop people doing anything which is real-time unsafe, so any language which involves a heap or GC is out - it needs to be secure enough to not pose a security risk if deployed to an embedded bare-metal device, so C is out. - it needs to be super-easy to learn for all programmers, and especially for grizzled old C/C++/Javascript/C# people who aren't into any of that fancy functional nonsense - it needs to strongly enforce and represent a graph structure at a syntactic level, so.. pretty much all existing languages are out.
- deleted 7y ago
  [deleted]
- jcelerier 7y ago
  > - it needs to strongly enforce and represent a graph structure at a syntactic level, so.. pretty much all existing languages are out. ... except languages designed for real-time signal processing based on dataflow graphs such as Kronos (https://www.mitpressjournals.org/doi/pdfplus/10.1162/COMJ_a_00330 https://www.mitpressjournals.org/doi/pdfplus/10.1162/COMJ_a_...), Céu (http://www.ceu-lang.org/chico/ceumedia_webmedia16_pre.pdf http://www.ceu-lang.org/chico/ceumedia_webmedia16_pre.pdf), Antescofo (https://hal.inria.fr/hal-01585489 https://hal.inria.fr/hal-01585489) and the oldies such as SIGNAL, Lustre, Esterel, etc... :p
  - julesrms 7y ago
    OK, fair point! Maybe a better way for me to phrase what I meant there would have been "pretty much all mainstream languages are out"
julesrms 7y ago
oh.. I should also mention that we don't expect it to replace all the other audio systems and languages that are already established and have large user-bases. (At least not overnight ;) ) ..but we are attempting to do something that nobody else is, which is to provide a platform they can use as a target. If we can do the hard work and graft of turning this into a super-portable runtime that can target whatever low-latency hardware the user has (and create a market for new audio accelerators that don't yet exist), then we expect it to be attractive for all those existing frameworks to use SOUL (or our IR) as the thing they emit, rather than using LLVM's JIT or WASM or just interpreters as they do now.
sigil 7y ago
I had the same reaction to SOUL at first (why do we need yet another language?!!), but I've come around to it. The precedent to consider is shader languages. A language like GLSL constrains what the programmer can do, with very good reason: the probability a newcomer will write a performant-enough and correct-enough shader in a general purpose programming language is low. Similarly with audio programming. Not blocking the audio thread is hard! Heck, just dealing with multithreading itself is hard. JUCE tries to make audio programming much simpler, but at the end of the day it's still C++, and footguns abound. So I like to think of SOUL as a sort of shader language for audio. We built https://soul.dev/playground/ https://soul.dev/playground/ to be a sort of "Shadertoy for Audio."

by jchook 7y ago

tomduncalf 7y ago

The overview at https://github.com/soul-lang/SOUL/blob/master/docs/SOUL_Overview.md https://github.com/soul-lang/SOUL/blob/master/docs/SOUL_Over... should help explain the motivation. I’m sure Jules can elaborate further :)

julesrms 7y ago

We pre-emptively answered this inevitable question in the overview doc: https://github.com/soul-lang/SOUL/blob/master/docs/SOUL_Overview.md https://github.com/soul-lang/SOUL/blob/master/docs/SOUL_Over... The main TL;DRs are: - this needs to get JITed to compete with C++ performance, so dynamic and interpreted languages are out. - it needs to stop people doing anything which is real-time unsafe, so any language which involves a heap or GC is out - it needs to be secure enough to not pose a security risk if deployed to an embedded bare-metal device, so C is out. - it needs to be super-easy to learn for all programmers, and especially for grizzled old C/C++/Javascript/C# people who aren't into any of that fancy functional nonsense - it needs to strongly enforce and represent a graph structure at a syntactic level, so.. pretty much all existing languages are out.

deleted 7y ago
[deleted]
jcelerier 7y ago
> - it needs to strongly enforce and represent a graph structure at a syntactic level, so.. pretty much all existing languages are out. ... except languages designed for real-time signal processing based on dataflow graphs such as Kronos (https://www.mitpressjournals.org/doi/pdfplus/10.1162/COMJ_a_00330 https://www.mitpressjournals.org/doi/pdfplus/10.1162/COMJ_a_...), Céu (http://www.ceu-lang.org/chico/ceumedia_webmedia16_pre.pdf http://www.ceu-lang.org/chico/ceumedia_webmedia16_pre.pdf), Antescofo (https://hal.inria.fr/hal-01585489 https://hal.inria.fr/hal-01585489) and the oldies such as SIGNAL, Lustre, Esterel, etc... :p
- julesrms 7y ago
  OK, fair point! Maybe a better way for me to phrase what I meant there would have been "pretty much all mainstream languages are out"

julesrms 7y ago

oh.. I should also mention that we don't expect it to replace all the other audio systems and languages that are already established and have large user-bases. (At least not overnight ;) ) ..but we are attempting to do something that nobody else is, which is to provide a platform they can use as a target. If we can do the hard work and graft of turning this into a super-portable runtime that can target whatever low-latency hardware the user has (and create a market for new audio accelerators that don't yet exist), then we expect it to be attractive for all those existing frameworks to use SOUL (or our IR) as the thing they emit, rather than using LLVM's JIT or WASM or just interpreters as they do now.

sigil 7y ago

I had the same reaction to SOUL at first (why do we need yet another language?!!), but I've come around to it. The precedent to consider is shader languages. A language like GLSL constrains what the programmer can do, with very good reason: the probability a newcomer will write a performant-enough and correct-enough shader in a general purpose programming language is low. Similarly with audio programming. Not blocking the audio thread is hard! Heck, just dealing with multithreading itself is hard. JUCE tries to make audio programming much simpler, but at the end of the day it's still C++, and footguns abound. So I like to think of SOUL as a sort of shader language for audio. We built https://soul.dev/playground/ https://soul.dev/playground/ to be a sort of "Shadertoy for Audio."