The Titania Programming Language
github.com
The Titania Programming Language
1–10 of 68 posts
Re: The Titania Programming Language
#2Clever name.
It'd be nice to see some discussion of the motivation for its departures from Oberon07.
Re: The Titania Programming Language
#3No pointers ?
Re: The Titania Programming Language
#4Looking at your source, I was introduced to Odin -- now I want to hear a lot more about that.
Re: The Titania Programming Language
#5A modest proposal…
Instead of having println() or it’s equivalent in your programming language, add a new special character that denotes a newline after a string:
print(“Hello world”.)
Re: The Titania Programming Language
#6Looking at your source, I was introduced to Odin -- now I want to hear a lot more about that.
He is also the creator of Odin :)
Re: The Titania Programming Language
#7No pointers ?
from the grammar:
> pointer_type = "^" type.
Re: The Titania Programming Language
#8A modest proposal… Instead of having println() or it’s equivalent in your programming language, add a new special character that denotes a newline after a string: print(“Hello world”.)
That would mess with dot syntax usually reserved for method calls. Like rust's "hello".to_string();
Re: The Titania Programming Language
#9A modest proposal… Instead of having println() or it’s equivalent in your programming language, add a new special character that denotes a newline after a string: print(“Hello world”.)
That would mess with dot syntax usually reserved for method calls. Like rust's "hello".to_string();
Oberon doesn't have string methods (and people who opt not to parenthesize for cases like that deserve the punishment).
Re: The Titania Programming Language
#10Having done a fair degree of programming in Wirthwhile languages, I think the only main design decision that I think was a mistake was the variables at the top.
I'm not sure of the value of seeing all of the variables used listed in one place, it has certainly led to me encountering a identifier scrolling up to determine the type then scrolling back down. When the variable is only used on a few consecutive lines it's just adding work to read and adding work to create. I daresay I have written harder to read code than I intended because I didn't want to go up and declare another variable for short term use. The temptation to inline the expression is always there, because you know what all the parts mean when you write it. It's only when you come back later that you get the regret.
It's possible it could be mitigated by defining something like (not sure if this is a valid grammar)
stmt_sequence = {decl_sequence}. stmt {";" stmt} [";"].