Some nice language quirks of I7 are mentioned in this article (along with a bunch of other languages). eev.ee/blog/2016/12/01/lets-stop-copying-c/
The worst language quirk of Inform 6/7 IMO is the implicit return true in functions (and return = return true). I’ve gotten tripped up by it so many times, to the extent where I wish the compiler would make a warning any time when we don’t have an explicit return statement.
As an odd side effect of learning Inform before C (or any other procedural languages)*, this has never bothered me. But I can see how it would bother me a lot if I’d gone the other way around.
[size=85]* Technically I learned Pascal in summer camp before 8th grade, but I don’t think it counts, since I promptly forgot it.[/size]
In my view, we should copy C more, not less, since it’s easy and successful.
My view it depend what you are making. There are many good thing in C but also some problems, for example the syntax for specifying types is a bit confusing, and the macros are not hygienic (sometimes this is an advantage but sometimes not), and the syntax for comments interferes with the syntax for dividing by a value accessed through a pointer. C is otherwise good enough though
Well, copy and improve then
I find C syntax quite nice. There’s always corner cases, and some languages based on C-syntax have improved on them (Java and C# are good examples, but D is probably the best example on how to use C syntax but improve on it.)
Unfortunately, when it comes to IF languages, I find none of them did a really good job at copying and improving C syntax. TADS did an OK job; good C-like syntax, but it got the semantics almost completely wrong. Inform 6 is a bit of a mess; it seems like it tried to improve on C syntax, but in fact it made it worse by trying to improve on things that didn’t need improvement.
Where I see a problem is with C semantics, not syntax. That one we can get rid of (and we have; none of the IF languages follow C semantics very closely) since we don’t care about the bare metal; in IF, having control over memory addresses, cache lines, memory layout and prefetching is just not important.
An IF language with the simplicity of C but high-level semantics is what we should strive for. In my experience, if you try to get rid of C-syntax and instead opt for a high-level and convenient syntax, you end up with a language where everyday, mundane things are easier to write, but many special cases are notoriously difficult to deal with, if not outright impossible. You then have to add corner cases and special syntax and exceptions to the rules to make these things possible. And that’s when you have created a huge mess of a language.
So: simple, short, clear C-like syntax but high-level semantics. I don’t think we have an IF language that does this (again, TADS doesn’t quality, since it opted for arcane and error-prone semantics that confuse me to this day.)
All this talk about language design is making me itch to try making my own attempt…
The syntax for C is nice; just there are a few problems I noted with its syntax.