[M3devel] "target specific pragmas"?

[Darko]

I don't really question the usefulness of any given feature, just the  
incremental cost of adding any given feature. One of M3's great  
strengths is that it is low on features, but the ones it has are  
powerful and well chosen.

The comparison I meant in the typing discussion was between C and M3,  
not the length of symbols. C is a bit obsessive about source size,  
which was meaningful back in the day, but today is totally irrelevant.  
Even if you don't use macros on your editor, the amount of time spent  
staring and your code is much greater than the time you spend typing  
it. You could argue that BEGIN/END is easier to read than {/} but I  
think the more important point is that this issue is not a significant  
one.


On 15/02/2008, at 5:34 AM, hendrik at topoi.pooq.com wrote:

> 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