This repo isn't even 24 hours old yet and it's on HackerNews... Just wow....
not Scotish sadly, AFAIK so: wowsers! kinda recall someone saying something about this?! \o/ yey
The Titania Programming Language
41–50 of 68 posts
Re: The Titania Programming Language
#42Earlier quoted context omitted.
A nice side-effect of "variables at the top": you keep your functions short.
"Functions should always be short" is also one of those guidelines that people treat like a hard rule. There are occasions when a 100 line function is easier to read than 5 20 line functions, or god forbid 20 5 line functions. Stop being overly dogmatic, it ALSO leads to worse code.
There are occasions => There are only rare occasions.
Re: The Titania Programming Language
#43Having 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…
> Wirthwhile languages,
This made me smile; going to use it in the future.
Re: The Titania Programming Language
#44Having 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…
When I write the backend (this repo isn't even 24 hours old yet), you'll find out why variable declarations are at the top of a procedure. (Hint: it has something to do with the stack).
I wondered why my university made us use C90 for Systems Programming class (circa 2010) until I took Compilers. This quirk specifically stood out to me when considering code generation from an AST - it's a lot easier to simply allocate all required memory at the top of a stack frame when you have the variable declarations at the top of the function.
Re: The Titania Programming Language
#45Very nice project, I'm a big fan of implementing Wirthian languages to learn compilers. Also, in true Wirth style, the documentation mainly consists of the language grammar :)
The project is not even 24 hours old... And I might plan on making this a recorded series of explaining how to make compilers from scratch with this language as a reference.
Of course! It wasn't really a criticism, just a cheeky observation that the documentation for every Wirth-style language I've ever seen begins with the EBNF grammar. Though it's rare for a new language to do that today, I appreciate you continuing the tradition.
Re: The Titania Programming Language
#46Having 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…
> Wirthwhile languages, This made me smile; going to use it in the future.
Though it would be pronounced vehrt-while.
Re: The Titania Programming Language
#47Earlier quoted context omitted.
Supporting lowercase keywords and making (at least some) semicolons optional already makes Oberon much more attractive ;-)
And removing unnecessary keywords and modernizing it too. `[N]T` for arrays and `^T` for pointers, rather than `array N of T` and `pointer of T`. And supporting C++ style code `/*/` and `//`. And as I develop this, I'll tweak it more so that people can actually understand without having to know the full histories of Pascals or Oberons or whatever.
Trying to eliminate semicolons by doing JS-style ASI is gross and complicates things unnecessarily. You can trivially change the parser/grammar so that the semicolons in import, var, procedure, etc. declarations just aren't required, and likewise with statements that end in "end". They'll still be necessary for statements comprising things like assignments and procedure calls, but for a teaching language who cares.
(Your grammar is missing a definition for proc_call, by the way.)
Re: The Titania Programming Language
#48Earlier quoted context omitted.
And removing unnecessary keywords and modernizing it too. `[N]T` for arrays and `^T` for pointers, rather than `array N of T` and `pointer of T`. And supporting C++ style code `/*/` and `//`. And as I develop this, I'll tweak it more so that people can actually understand without having to know the full histories of Pascals or Oberons or whatever.
Trying to eliminate semicolons by doing JS-style ASI is gross and complicates things unnecessarily. You can trivially change the parser/grammar so that the semicolons in import, var, procedure, etc. declarations just aren't required, and likewise with statements that end in "end". They'll still be necessary for statements comprising things like assignments and procedure calls, but for a teaching language who cares. (…
I only added that a few minutes ago, and it's a question of whether I should or not. This project is so goddamn new that I have not even decided anything. I was not expecting anyone posting this to HackerNews in the slightest.
Also this isn't JS-style ASI technically speaking, and it won't have any of the problems either. The syntax for this language is different enough that it won't be a problem. Procedures don't even return things.
Re: The Titania Programming Language
#49Earlier quoted context omitted.
Wirth was obsessed with the idea of creating the absolutely minimal useful language, and many of his languages' warts come from that. Variables are at the top because: - you immediately see them (so, perhaps, easier to reason about a function? I dunno) - the compiler is significantly simplified (all of Wirths' languages compile superfast and, if I'm not mistaken, all are single-pass compilers) However, I feel that Wi…
This has nothing to do with "dogma" and something simpler. It has nothing to do with "immediately see them". Hint: This about this from a single pass compiler basis and how much memory needs to be reserved from the procedure's stack frame.
"This is nothing to do with something simpler" and "this is from a single pass compiler".
Are you sure you actually read my second bullet point?
If you read texts and papers by Wirth you'll see a single theme emerge: simplicity. Everything he didn't consider simple was thrown away and derided.
Re: The Titania Programming Language
#50Remarkable that Bill is interested in a version of Oberon-07. It's even more minimalistic than the previous Oberon versions. I spent a lot of time with the original Oberon language versions and experimented with extensions to make the language more useful for system programming (e.g. https://oberon-lang.github.io/ and https://github.com/rochus-keller/oberon/ ). Eventually I had to give up backward compatibility to ge…
Please note the project isn't even 24 hours old yet. But I am using Oberon-07 as base, and I might deviate from it quite soon too. But I won't be going in the direction of things like Oberon+ (which adds generic and OOP programming) or Micron which adds the entire type system necessary to interact with foreign code. I just wanted something to explain to people how to do tokenizing, parsing, semantic checking (not jus…
Really nice project, well done.
I would say it's probably not necessary to explain what the connection between Titania and Oberon is in the README. It's probably evident to most people?