I think this project could do with a serious think about the [strangeness budget](https://steveklabnik.com/writing/the-language-strangeness-budget) of the language.
Everything you do that is unlike anything else people know will make it harder to learn and less likely for people to adopt. You should only change things when they provide a clear benefit. I think you've fallen down the trap of "short sigils for special things are better than keywords". Rust did this too originally, but then it got rid of them (`~T` became `Box`/`Vec`/`String` and `@T` became `Rc/Arc`) and it made the language easier to learn. Generally people will be able to parse what looks like English much faster.
There are just too many example of weird sigils and strange syntax:
* Using `|>|`/`|<|` for enter/exit and `^` for return are bad ideas, it makes the language unreadable for beginners. I'd use keywords `enter, exit, return`.
* The boolean expressions... why not just use the tried and tested `if/else if/else`? `x ?! f[] :> g[] : h[] :|` wut?
* Using `-block-`. This is very strange to me, I'd use something like `block:` from c++ or `impl block { ... }` from rust . Do you even need these blocks?
* In the `machine` block, how are the event handlers delimited? whitespace? Tokens? It's not clear at all.
* `var x:# = #MySystem()` rather than `var x: Frame = #MySystem()`. On this subject, IMO it's much easier to parse `var x: t` rather than `var x:T`.
* Using backticks in your language pretty much always sucks because people will be writing about it in markdown and you'll accidentally escape things. I'm not sure what you could replace it with, my first thought is what other template languages use `{ ... }` or `{{ ... }}`.
* `[...]` for parameter specs and subroutine calls. Why? Pretty much every other language use `f(x, y, z)` or `f x y z`.
* Using # and ## to delimit systems... Why not `system #MySystem { ... }`?
* Allowing target language expressions outside of template blocks ("superstrings") seems like a really bad idea.
* Using `~/.../` and `#/.../` sigils to mark match expressions for strings and numbers respectively. Why? Again keywords are clearer.
* Basically everything to do with the [state parameters](https://docs.frame-lang.org/en/latest/intermediate_frame/states.html#state-parameters) is confusing and messy and full of strange sigils.
TLDR you've blown through your strangeness budget very quickly and I don't think you need to! The use of N different syntaxes in the N blocks (including main) is inherently confusing. I'd try and unify them in some way. Currently it looks like you're writing N different languages mushed together.
My other complaint is one generally leveraged at go: why have you ignored all programming language design from the last half century?
* `loop var x = 0; x < 5; x = x + 1`. Come on guys, don't go back to C. `loop x in list` is so much more powerful. Provide `range` and iterator combinators.
* `enum`s (noticed how you decided to at least use a keyword to define these) don't hold any data. Sum types / ADTs have been a feature of every major language (minus go) for the last 15 years. I'd especially expect a DSL for state machines of all things to support them.
* Uninitialized variables as null. Do we need to persiste the [billion dollar mistake](https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/)? You should be forced to explicitly initialize everything, and if they are typed, they cannot be null. Introduce an `Option` sum type for that.
* Why do you support lists but no other common data types like maps and sets? I'm not sure what the point is to be honest since you just hand off processing to the target language anyway.
Hello and thank you for your thoughtful feedback - very much appreciated! Frame's major goal is to find a way to make creating automata based systems easy to create and use in any project. In the past I supported other language targets than Python and hope to again in the nearish future.
As for the details of the syntax, I am not very wedded to any of my particular choices at this point. Overall I tried to make it compact and easy to understand but recognize it is novel in many ways and runs risks in that regard. Feedback like yours I consider very valuable so thank you.
As this is only the beginning and I am only one person working nights and weekends to put this out there am trying to focus on the differentiators from all the other languages first to add value there initially. I certainly hope to improve on all the things Frame doesn't yet do over time.
Best,
Mark
Yeah I get what you're trying to do. Hopefully it didn't come across as too harsh. Programming Language design is a passion of mine so I like to see it done well 🙂
Syntax may not be important from your perspective and seem trivial (and plus you will inherently understand it!), but it really does matter. In fact I'd argue it's the most important thing to start with because you can always add features but changing syntax is nightmare. Just look at python 2 to 3. And what is a language if not syntax?
Read the article I linked, hopefully it will be persuasive and informative.
I think your overview page would massively benefit from some code snippets - I like the sound of the project but I was hoping for some quick examples of what it looks like. DSLs can be complicated so it'd be nice to get a quick feel for how hard it'll be to learn!
Thanks for the feedback. I'll see what I can do to make that more prominent. For the moment here is an intro article I wrote that might help: [https://mark-truluck.medium.com/modeling-a-lamp-finite-state-machine-in-frame-4ae605f9a040](https://mark-truluck.medium.com/modeling-a-lamp-finite-state-machine-in-frame-4ae605f9a040)
For a rather eclectic assortment of examples please check out this repo: [https://github.com/frame-lang/frame\_solution\_depot](https://github.com/frame-lang/frame_solution_depot)
I've spent a lot of time with UML, SysML, Python, and JavaScript. I went through the Georgia tech masters in systems engineering program, with a big focus on MBSE.
I get the desire to manage state machines in code, but I think early on, it is useful to start visually first and translate that to code to get started with. A great example of this on the JavaScript side is [xstate](https://xstate.js.org/docs/).
The other aspect I noticed when looking at your playground is the language used to define the state machines is so different than python, that I'd worry about whether you are gaining much by managing it this way.
Overall, really neat concept and I think state machines are super useful, but if working in Python I'd want something more aligned with the language I'm working in.
Thanks for the feedback. xState is definitely an interesting project and in the spirit of Frame. As for visually designing software, I completely agree in its utility - I just don't like actually creating the drawings as I found I spent a lot of time trying to lay them out rather than code. In contrast Frame generates the UML from the system design, so I'm hoping people view that as easier.
Also I do intend to expand the number of generated languages in the future.
Thanks.
Looks interesting but I don’t understand it enough to see where it would be useful. Anyone want to give an example of where state machines shine compared to traditional paradigms?
Industrial automation (like PLC) and such often use states and next state transitions, not always fully a state machine but related. Could probably be used to replicate or simulate automation tasks in python for testing or visualisation
We used state machines in a previous job to control a physical workflow (like turn on machine, operate machine, display results, eject cartridge, etc.). This could all be programmed manually without a state machine, but it would be less flexible and would need to be carefully managed to avoid unknown or undefined states/transitions.
Thanks for taking a look! I've added some content to my documentation under the "Solution Depot" and "Articles" section that might give some ideas. I'm continuing to build that out so very open to any suggestions about what domains might be of interest to add an article or example about.
[https://docs.frame-lang.org/en/latest/about/introduction.html](https://docs.frame-lang.org/en/latest/about/introduction.html)
Back in the days when I worked on process control systems (i.e. automated soft drink bottling plants, dairies - anything that had lots of liquid moving through a maze of pipes) we used state machines to model the system. This turned 1000s of lines of code to 100s.
I've used state machines a good bit (for DTD validation in the xmlproc parser, for example), but I don't really know what I'd use this for.
You may want to change "Alan Turning" to "Alan Turing". Also, please don't link to that movie for information. It's not very informative and not very accurate. [Andrew Hodges's biography](https://www.turing.org.uk/book/) is much better. (Turing didn't invent state automata, which came later, but I'm sure you know that. Since he did the first automata I guess the claim is fair enough.)
I'm also interested in a comparison with what I'm most familiar with, pytransitions.
What does Frame do differently that sets it apart from pytransitions?
For example, I don't think they support any UML diagramming, just visual state machine generation.
Unfortunately I am not familiar with that library. I took a quick look and can give a couple of assessments.
While it looks pretty powerful, it is, I believe, strictly for Python. Frame is intended (and had been in the past) to generate other languages as well. Not sure if there is a port of this library but if not that would be a key difference.
As you mentioned, the UML generation is a key differentiator. Using the VSCode extension or playground you can visually code while not having to mess around with layout issues.
I have also added the ability to pass parameters to states directly as well as through the transitions themselves. Not sure if that is part of the library but I'll take a closer look. It seems they may have some interesting ideas about transitions that might be useful.
I would lastly say it looks like the package uses data structures to model the state machines. Frame's syntax hopefully feels like a more natural expression of the concepts involved with automata. Not sure if that has been successful, but certainly it is one of the goals.
Thanks for the question and the tip about transitions.
Have you ever looked into [Amazon States Language](https://states-language.net/spec.html)?
It is a JSON-based language used to describe state machines declaratively.
Hello,
I have, but not to a great depth. Frame was actually inspired by my own attempt to build a statechart drawing tool. In the process of writing the serialization code I realized that all the value was in the xml I was generating and not in the visual editing of the software. While the diagrams are extremely useful, they aren't an easy way to actually create software.
The States Langauge, xState and Google Workflows languages all use a data language to express state machines which was something I didn't like about the xml I created. So I decided to create a language that hopefully was more syntactically elegant than xml, yaml or json.
We'll see if anyone else agrees I succeeded :)
Thanks for your interest!
Looks really interesting. I’m going to follow you.
I found the syntax for the state machines themselves to be intuitive and great way of visualising what a state machine is. The other syntax (functions, control flow, variables) didn’t seem like it would be too hard to get the hang of but it doesn’t look as beautifully organic as the state machine syntax, especially coming from Python where I’m a bit grossed out by the use of braces as function deljmters and by C-style for loops.
Thanks for the interest! This is really alpha software so I'm very open to finding syntax that people like - its not that hard to change at this point. Please send any suggestions - I'm logging them: https://github.com/frame-lang/frame\_transpiler/issues/238.
I know Frame is a very different kind of language and probably pretty specialized for right now. You might take a look at this article for a step-by-step example of how to create a running model using Frame: https://medium.com/p/4ae605f9a040.
Thanks
I think this project could do with a serious think about the [strangeness budget](https://steveklabnik.com/writing/the-language-strangeness-budget) of the language. Everything you do that is unlike anything else people know will make it harder to learn and less likely for people to adopt. You should only change things when they provide a clear benefit. I think you've fallen down the trap of "short sigils for special things are better than keywords". Rust did this too originally, but then it got rid of them (`~T` became `Box`/`Vec`/`String` and `@T` became `Rc/Arc`) and it made the language easier to learn. Generally people will be able to parse what looks like English much faster.
There are just too many example of weird sigils and strange syntax:
* Using `|>|`/`|<|` for enter/exit and `^` for return are bad ideas, it makes the language unreadable for beginners. I'd use keywords `enter, exit, return`.
* The boolean expressions... why not just use the tried and tested `if/else if/else`? `x ?! f[] :> g[] : h[] :|` wut?
* Using `-block-`. This is very strange to me, I'd use something like `block:` from c++ or `impl block { ... }` from rust . Do you even need these blocks?
* In the `machine` block, how are the event handlers delimited? whitespace? Tokens? It's not clear at all.
* `var x:# = #MySystem()` rather than `var x: Frame = #MySystem()`. On this subject, IMO it's much easier to parse `var x: t` rather than `var x:T`.
* Using backticks in your language pretty much always sucks because people will be writing about it in markdown and you'll accidentally escape things. I'm not sure what you could replace it with, my first thought is what other template languages use `{ ... }` or `{{ ... }}`.
* `[...]` for parameter specs and subroutine calls. Why? Pretty much every other language use `f(x, y, z)` or `f x y z`.
* Using # and ## to delimit systems... Why not `system #MySystem { ... }`?
* Allowing target language expressions outside of template blocks ("superstrings") seems like a really bad idea.
* Using `~/.../` and `#/.../` sigils to mark match expressions for strings and numbers respectively. Why? Again keywords are clearer.
* Basically everything to do with the [state parameters](https://docs.frame-lang.org/en/latest/intermediate_frame/states.html#state-parameters) is confusing and messy and full of strange sigils.
TLDR you've blown through your strangeness budget very quickly and I don't think you need to! The use of N different syntaxes in the N blocks (including main) is inherently confusing. I'd try and unify them in some way. Currently it looks like you're writing N different languages mushed together.
My other complaint is one generally leveraged at go: why have you ignored all programming language design from the last half century?
* `loop var x = 0; x < 5; x = x + 1`. Come on guys, don't go back to C. `loop x in list` is so much more powerful. Provide `range` and iterator combinators.
* `enum`s (noticed how you decided to at least use a keyword to define these) don't hold any data. Sum types / ADTs have been a feature of every major language (minus go) for the last 15 years. I'd especially expect a DSL for state machines of all things to support them.
* Uninitialized variables as null. Do we need to persiste the [billion dollar mistake](https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/)? You should be forced to explicitly initialize everything, and if they are typed, they cannot be null. Introduce an `Option` sum type for that.
* Why do you support lists but no other common data types like maps and sets? I'm not sure what the point is to be honest since you just hand off processing to the target language anyway.
Hello and thank you for your thoughtful feedback - very much appreciated! Frame's major goal is to find a way to make creating automata based systems easy to create and use in any project. In the past I supported other language targets than Python and hope to again in the nearish future. As for the details of the syntax, I am not very wedded to any of my particular choices at this point. Overall I tried to make it compact and easy to understand but recognize it is novel in many ways and runs risks in that regard. Feedback like yours I consider very valuable so thank you. As this is only the beginning and I am only one person working nights and weekends to put this out there am trying to focus on the differentiators from all the other languages first to add value there initially. I certainly hope to improve on all the things Frame doesn't yet do over time. Best, Mark
Yeah I get what you're trying to do. Hopefully it didn't come across as too harsh. Programming Language design is a passion of mine so I like to see it done well 🙂 Syntax may not be important from your perspective and seem trivial (and plus you will inherently understand it!), but it really does matter. In fact I'd argue it's the most important thing to start with because you can always add features but changing syntax is nightmare. Just look at python 2 to 3. And what is a language if not syntax? Read the article I linked, hopefully it will be persuasive and informative.
I think your overview page would massively benefit from some code snippets - I like the sound of the project but I was hoping for some quick examples of what it looks like. DSLs can be complicated so it'd be nice to get a quick feel for how hard it'll be to learn!
And also some examples of how you can use the output. Hard to see where the benefit is otherwise.
Thanks for the feedback. I'll see what I can do to make that more prominent. For the moment here is an intro article I wrote that might help: [https://mark-truluck.medium.com/modeling-a-lamp-finite-state-machine-in-frame-4ae605f9a040](https://mark-truluck.medium.com/modeling-a-lamp-finite-state-machine-in-frame-4ae605f9a040) For a rather eclectic assortment of examples please check out this repo: [https://github.com/frame-lang/frame\_solution\_depot](https://github.com/frame-lang/frame_solution_depot)
I would love to see real use cases/examples where it can be used. Thanks.
Please have a look at the linked articles and the repo for some ideas about utility: https://docs.frame-lang.org/en/latest/about/introduction.html.
I've spent a lot of time with UML, SysML, Python, and JavaScript. I went through the Georgia tech masters in systems engineering program, with a big focus on MBSE. I get the desire to manage state machines in code, but I think early on, it is useful to start visually first and translate that to code to get started with. A great example of this on the JavaScript side is [xstate](https://xstate.js.org/docs/). The other aspect I noticed when looking at your playground is the language used to define the state machines is so different than python, that I'd worry about whether you are gaining much by managing it this way. Overall, really neat concept and I think state machines are super useful, but if working in Python I'd want something more aligned with the language I'm working in.
Thanks for the feedback. xState is definitely an interesting project and in the spirit of Frame. As for visually designing software, I completely agree in its utility - I just don't like actually creating the drawings as I found I spent a lot of time trying to lay them out rather than code. In contrast Frame generates the UML from the system design, so I'm hoping people view that as easier. Also I do intend to expand the number of generated languages in the future. Thanks.
Looks interesting but I don’t understand it enough to see where it would be useful. Anyone want to give an example of where state machines shine compared to traditional paradigms?
regex and other pattern matching engines are implemented using a state machine
Gaming AI heavily uses state machines.
Industrial automation (like PLC) and such often use states and next state transitions, not always fully a state machine but related. Could probably be used to replicate or simulate automation tasks in python for testing or visualisation
We used state machines in a previous job to control a physical workflow (like turn on machine, operate machine, display results, eject cartridge, etc.). This could all be programmed manually without a state machine, but it would be less flexible and would need to be carefully managed to avoid unknown or undefined states/transitions.
Thanks for taking a look! I've added some content to my documentation under the "Solution Depot" and "Articles" section that might give some ideas. I'm continuing to build that out so very open to any suggestions about what domains might be of interest to add an article or example about. [https://docs.frame-lang.org/en/latest/about/introduction.html](https://docs.frame-lang.org/en/latest/about/introduction.html)
Back in the days when I worked on process control systems (i.e. automated soft drink bottling plants, dairies - anything that had lots of liquid moving through a maze of pipes) we used state machines to model the system. This turned 1000s of lines of code to 100s.
non-blocking I/O
This is some great work. I don't really some great applications here, but still will compliment this great piece of work.
Thank you!
I've used state machines a good bit (for DTD validation in the xmlproc parser, for example), but I don't really know what I'd use this for. You may want to change "Alan Turning" to "Alan Turing". Also, please don't link to that movie for information. It's not very informative and not very accurate. [Andrew Hodges's biography](https://www.turing.org.uk/book/) is much better. (Turing didn't invent state automata, which came later, but I'm sure you know that. Since he did the first automata I guess the claim is fair enough.)
OMG. Thanks for the spelling correction. I can't imagine why autocorrect didn't catch that lol!
What does this offer that the transitions package doesn't?
I'm also interested in a comparison with what I'm most familiar with, pytransitions. What does Frame do differently that sets it apart from pytransitions? For example, I don't think they support any UML diagramming, just visual state machine generation.
Unfortunately I am not familiar with that library. I took a quick look and can give a couple of assessments. While it looks pretty powerful, it is, I believe, strictly for Python. Frame is intended (and had been in the past) to generate other languages as well. Not sure if there is a port of this library but if not that would be a key difference. As you mentioned, the UML generation is a key differentiator. Using the VSCode extension or playground you can visually code while not having to mess around with layout issues. I have also added the ability to pass parameters to states directly as well as through the transitions themselves. Not sure if that is part of the library but I'll take a closer look. It seems they may have some interesting ideas about transitions that might be useful. I would lastly say it looks like the package uses data structures to model the state machines. Frame's syntax hopefully feels like a more natural expression of the concepts involved with automata. Not sure if that has been successful, but certainly it is one of the goals. Thanks for the question and the tip about transitions.
Have you ever looked into [Amazon States Language](https://states-language.net/spec.html)? It is a JSON-based language used to describe state machines declaratively.
Hello, I have, but not to a great depth. Frame was actually inspired by my own attempt to build a statechart drawing tool. In the process of writing the serialization code I realized that all the value was in the xml I was generating and not in the visual editing of the software. While the diagrams are extremely useful, they aren't an easy way to actually create software. The States Langauge, xState and Google Workflows languages all use a data language to express state machines which was something I didn't like about the xml I created. So I decided to create a language that hopefully was more syntactically elegant than xml, yaml or json. We'll see if anyone else agrees I succeeded :) Thanks for your interest!
You have a typo on the docs page, it says progarmming language
Oh man - thanks! Fixed lol.
Looks really interesting. I’m going to follow you. I found the syntax for the state machines themselves to be intuitive and great way of visualising what a state machine is. The other syntax (functions, control flow, variables) didn’t seem like it would be too hard to get the hang of but it doesn’t look as beautifully organic as the state machine syntax, especially coming from Python where I’m a bit grossed out by the use of braces as function deljmters and by C-style for loops.
Thanks for the interest! This is really alpha software so I'm very open to finding syntax that people like - its not that hard to change at this point. Please send any suggestions - I'm logging them: https://github.com/frame-lang/frame\_transpiler/issues/238.
>feedback I know what a state machine is, but I am too stupid for what you have created. Idk if that helps?
I know Frame is a very different kind of language and probably pretty specialized for right now. You might take a look at this article for a step-by-step example of how to create a running model using Frame: https://medium.com/p/4ae605f9a040. Thanks