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
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.
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.
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 . 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?
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
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.
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.
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.
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
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”.
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.
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).
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
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.
Teletype’s scripting language (TTSL? ) 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”.
to that line.
. Here’s a post explaining it a bit more, 
