[M3devel] "target specific pragmas"?

[Mika Nystrom]

I just have to add a small comment on syntax, in response to how
weird M3's syntax is, etc.

One of the nice thing when I was teaching intro programming was
that "serious" CS books (and a large fraction of academic publications)
still use a kind of standard pseudocode that is based on Algol.
And that pseudocode looks a lot more like Modula-3 than it looks
like C!  No explanation of braces or the fact that when you see "="
in the pseudocode you want "==" in the machine-readable version,
and when you see ":=" you want "=".

What your video game developer friend needs is to do exercise #12
in section 2.3.5 in Knuth.  (There are references to three existing
solutions in the answer key.)

     Mika

hendrik at topoi.pooq.com writes:
>On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote:
>> M3 is the antithesis in the sense that it takes the opposite approach.  
>> C has few protections, M3 has many. M3 does examine what was wrong  
>> with C and other languages and fix them and it did a good job. The M3  
>> design team made an explicit goal to look at features from other  
>> languages and take the best. The fact that M3 works so well is the  
>> proof.
>> 
>> Some of the things you raise, like braces
>
>I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and 
>'END'.
>
>Natural languages evolve in the direction of having the mopst-oftern 
>used words be the shortest.  This makes it possible to say muc in less 
>space and time.  And it makes it easier to get an overview of a 
>program whose physical size is becoming inconvenient.  Just haveing 
>the code be readable and seeing enough of its context makes 
>debugging easier.
>
>> or stack allocations of  
>> objects are just features of C++ with no justification.
>
>Stack allocation of objects is not such a big issue in C++.  But it can 
>be a big issue in those programs where split-second real-time 
>interaction is an issue.  Yes, I know this is the traditional argument 
>against garbage collection, and that it is usually based on FUD rather 
>than reality.  But I have recently been in close contact with a 
>programmer of video games, and for some of them the fraction-of-a-second 
>pauses are a real problem.  He really *wants* to write his games in a 
>decent language, and he knows that C is not one.
>
>But every time he avoids heap allocation he delays the pause.  If
>he can delay it enough, it's a win.  If he can delay it altogether, 
>that's success.
>
>> Can you show  
>> that typing less characters is important? You say M3 is less  
>> convenient, but what is less convenient, less typing or less bugs?
>
>  This is a false dichotomy.  You may well be able to reduce typing 
>*and* reduce bugs, just by making code more readable.
>
>I doubt that typing "PROC" instead of "PROCEDURE", for example, is 
>likely to introdice bugs.  Not typing '{' instead of "BEGIN".  Using 
>special characters and lower-case keywords is likely to reduce bugs, 
>because it's less likely that one will be misread for another.
>
>> Do  
>> you spend most of your time typing or thinking when you write code?
>
>I think before I write code.  I don't stop thinking when I start 
>writing code, and I like to record my thoughts as I think.  The less 
>typing I need to do, the better I can get visual feedback on my 
>thoughts while thinking.  Sometimes the typing gets so tedious I get 
>bored and lose interest.  Then extra typing causes extra bugs.
>> 
>> Should language include every feature anyone can think of?
>
>No.
>
>> How is
>> excluding unimportant features 'arbitrary'? Each feature must be  
>> weighed to avoid unnecessary complexity and size, which have a direct  
>> impact on compiler maintainability and language usability. Language  
>> bloat is a real problem. I doubt that anyone understands the full  
>> semantics of C++.
>> 
>> You say that C has 'won', but in what sense? More people use it?  
>> Language design is not American Idol, it's not a question of who has  
>> the most votes.
>
>Enough people use it that it has become a fixture in the programming 
>world.  If you want to reuse existing code instead of always writing 
>new, you are pretty much forced into some kind of interfacing between C 
>and a reasonable language.  The convenience of this interfacing can well 
>determine whether the reasonable language is feasible for a specific 
>application.
>
>-- hendrik