Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Comment on Frame Syntax from Reddit #238

Open
frame-lang opened this issue May 14, 2024 · 0 comments
Open

Comment on Frame Syntax from Reddit #238

frame-lang opened this issue May 14, 2024 · 0 comments
Assignees
Labels

Comments

@frame-lang
Copy link
Owner

https://www.reddit.com/r/Python/comments/1cqoyuq/frame_a_new_language_for_programming_state/

I think this project could do with a serious think about the 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 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.

enums (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? 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.

@frame-lang frame-lang self-assigned this May 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant