#1

This post is a wiki, which means anyone can edit it. As an experiment, I’d like to see if we can compile a document that summarizes the underlying philosophy of the Teletype language. The original post describing the idea is at the bottom of this wiki. Changes to the wiki can be reverted or edited. However, discussion is easiest in replies in the thread. NOTE: if you quote from this in a reply, it will be attributed to @cmcavoy, even though this is a wiki with multiple authors. For clarity, if you quote, remove the attribution. When possible, include a footnote link to the post that justifies the axiom in the list below.

  • The Teletype language is designed for musical [4] expression and creativity. [2]
  • The Teletype language should be easy to hold in your head. [3]
  • The Teletype language should feel like patching. [3]
  • Everything can be translated into or expressed as voltage
  • Parsing Teletype language programmatically is easy and should remain easy [1]

Active Discussion, move it up (ideally with a link to the discussion) when it feels like we’ve got consensus on the move.

  • The script should be entirely visible on a single screen
  • Musically interesting choices are sometimes preferable to scientifically correct choices
  • Readability and learnability matter. Everything should be understandable at a glance.
  • There should be one-- and preferably only one --obvious way to do it
  • No runtime errors

From the original post, should be deleted at some point
I admire the Zen of Python and the related PEP 8, Idiomatic Python. The Zen of Python,

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea – let’s do more of those!

I’m interested in compiling a similar statement about Teletype the language based on what I see here. When someone suggests adding a feature to Python, PEP 8 and the ZofP end up being referenced at some point in the conversation. It’s a guiding statement.

Anyone interested in contributing ideas? I’m not in a hurry. Just something that’s been floating around in the back of my mind this week.

(Teletype) expanding scripts: length and amount
CHAOS Operators
A user's guide to the wonderful world of teletype ⌨
#2

Musically interesting is better than computer science interesting

My interpretation of,

Related, but based on my interpretation of the language,

CV theory is better than music theory

1 Like
#3

Had a good conversation with someone about this line (they can self identify if they want, but as it was in private not sure if they want to be named). The statement doesn’t hold up under even minor challenge. I think maybe a better way to say it is that core of the language emphasizes control voltage. Other concepts can be layered on top of that - the N operator and lots of bits in the telex command set - but they all translate down to and can be manipulated as voltages. Although that’s not exactly true either, or else V wouldn’t exist.

So - given all that - :-1: to that line.

2 Likes
#4

I tried rewriting that line so that it’s true:
Everything can be translated into or expressed as voltage

2 Likes
#5

It could be said that Teletype is a tool that permits translation between the conceptual layer of music and the physical layer of modular synthesis.

As such, it establishes primitives of those layers within the internal context of its scripting language.

… I’m not sure that gets us any closer to a maxim. :upside_down_face:

6 Likes
#6

This is more about the hardware than the language though, right? @scanner_darkly has talked about ‘Ansible Satellite’ where code written on the Teletype could be loaded to Ansible and executed as a sort of headless Teletype. It doesn’t exist yet, but given his track record it’s probably only a matter of time :wink:. Here’s a post explaining it a bit more, Grid ops / integration

If Teletype code running on not-Teletype hardware exists, do we lose the constraints of the current hardware? Or is there something to the available space on the TT module that’s important beyond the actual size of the screen?

#7

It’s not a hardware constraint at all. We have discussed scrolling and wrapping, and they have been rejected by the community. Intention of this constraint is to keep scripts small and easy to understand at a glance.

In fact, I’m going to add that:

Readability and learnability are important. Everything should be understandable at a glance

5 Likes
#8

That’s a pretty high bar for anything sufficiently complex.

Come to think of it,

This is super hard to achieve with Polish Notation. What’s the idiomatic ordering of operators? Consider:

A - * + / X 9 2 7 3
A - * 7 + 2 / X 9 3

Given the fact that divide and subtract are position dependent, the more consistent ordering is the first, IMO.

Even this simple math equation illustrates that it’s pretty hard for this syntax to be readable at-a-glance.

edit: I suppose my pedantry itself violates the anti-purism maxim in a meta sense :slight_smile:

2 Likes
#9

Maxims are hard…

2 Likes
#10

Except, how often do you write in pure python? I suppose a software developer might. Then again, I suppose a software developer would be spending more time in C/++ than Python. My work always starts with importing a bunch of libraries without which I would be severely handicapped, and most of which do not adhere to the commandments, even the Google-maintained tensorflow.
My point is, absolutism is a two-faced hag.

1 Like
#11

The first sentence and second sentence are not necessarily compatible. Something can be learnable - consistent in its rules, small vocabulary and grammar - and yet still take more than a glance to understand.

A useful adjective in language design, to throw into the mix I’m not sure how, is expressive. I would not sacrifice learnability for expressiveness, but I might sacrifice legibility.

2 Likes
#12

Problem is… the Teletype language is based on Forth, and Forth is a bit of a “write once read never” (WORN) language.

Admittedly Forth is even worse as it’s reverse Polish notation (RPN), rather than the Polish notation that we use.

We get away with it’s unreadability because the scripts are so short. Imagine a 500 line long Teletype script open in your favourite text editor! To go up to that level we’d have to start moving towards adding brackets a la Lisp, and Lisp is a fundamentally different paradigm to Forth.

Things of interest about the Teletype language:

  • Forth (RPN) itself is extremely light on memory usage. Internally our Teletype code (forward Polish notation) is run backwards (with some allowances added in for sub commands / PRE statements).
  • The grammatical rules of the language are really simple, unlike infix notation, there are no issues with operator precedence.
  • It’s easy to write a parser for the language due to it’s simplicity.
  • It runs quickly (again due to it’s simplicity).
  • The above points mean that you don’t need to be a compiler or language expert to get involved with firmware development.
  • No runtime errors, something that is not picked up very much, but the design of the language rules them out.
  • There is even a bit of functional programming in there… a MOD, (i.e. the first part of a PRE) actually takes code as one of it’s arguments (the POST, or the bit after the :).

edit: I’ve added “no runtime errors” to the list at the top, please feel free to make it more poetic

edit 2: I actually think it should go at the top of the list and be in bold

2 Likes
#13

OK. So it feels like there’s something along the lines of

Whilst the small screen and terse syntax of TT code lead towards a style based on brevity, expressivity and legibility are always more important than character count.

But, you know, briefer and possibly verified by someone who actually owns a TT. (Hanging around here as a language geek).

I think the other thing to definitely remember is: maxims can be aspirational towards what we’d like things to be like, but they must include the set of “how things are now”.

#14

So I really agree with this statement (I always preferred Python to Ruby)… but I’m going to try and make an argument against it…

The Teletype language is designed for creativity. Maybe that should be in the list at the top? If it is, I believe it to be at odds with the quoted statement. I don’t think such a statement would ever apply to any creative endeavour.

Given that the Teletype name and language hark back to the early days of computing, consider:

  • Fortran, lit. “FORmula TRANslation” (1956)
  • Lisp, lit. “LISt Processor” (1958)

This is the 1950s version of Python vs Ruby. Which would you want to use for composing music?

To my mind Lisp (and Scheme) are the ultimate in creative computing languages (and I say this begrudgingly as a Haskell coder). I cannot imagine a language less likely to have “one way to do it” than Lisp.

2 Likes
#15

Yes. I like that.

I mean, it’s literally not true of modular synthesis, the landscape Teletype exists within. And it’s also at odds with expressivity: sometimes, the only-one-way-to-do-it fails to communicate one’s intent clearly. (for instance, in _$LANGUAGE$, I use both if !thing and unless thing because to me, they are semantically different, even if they are functionally the same).

2 Likes
#16

Not sure if this is eloquent enough to add to the coda but what attracted me to TT language is the fact that the line between events and values gets very blurry

Elsewhere in the modular world values of parameters reign supreme. As a language teletype somehow makes users rethink/revaluate this hierarchy.

Put another way, rhythm and melody/modulation exist on equal footing within the environment.

This might not really make sense to anyone else so feel free to ignore :see_no_evil:

3 Likes
#17

This feels important. I believe that the reason eurorack is so interesting is because the core rules of eurorack are simple, which makes it easy for small shops to get involved. It’s relatively easy to design a new module with off the shelf commercial parts, which leads to a healthy DIY community.

I know that’s an over simplification and many modules are way more complicated, but I think it’s helpful to keep in mind.

If we commit to the language’s ease of parsing as a feature, then it encourages more implementations of the language, as you can be a language parsing dabbler and write a reasonable implementation of it. That feels like a feature and well aligned with the eurorack philosophy.

1 Like
#18

Maybe that’s the essence of what I was trying to get at. I was simply trying to find a rationale for limiting scripts to a few lines.

2 Likes
#19

Teletype’s scripting language (TTSL? :wink: ) indeed has a simple grammar that is also flexible. As such, it’s possible to write the same statement several different ways.

While it may be easy for a computer to parse TTSL, I find it a ~somewhat~ difficult task for a human. It takes concentration to simulate the stack in your head. Though there are techniques to reduce the cognitive memory load, parsing a TTSL command takes experience and/or education.

Therefore, I echo these sentiments,

because legibility is a hurdle built-in to the language.

A relatively conservative maxim from this:

Mnemonics should be easy to remember and analagous to musical intention

This guards against arguments along the line of “how is a new user going to know that X means Xylophone?” as “remember” implies “learn”.

2 Likes
#20

I like expressive. Expressive and creative go well together.

Like this too.

Perhaps “The Teletype language is designed for creativity.” becomes:

The Teletype language is designed for musical creativity.

or even:

The Teletype language is designed for musical expression and creativity.

2 Likes