Oh, and just for the record, I don't like the math precedence rules.
If you mean 1 + ((3 * 6) / 9) - 5 then say that, preferably left to
right like the rest of the program is written.  I have enough
complexity in my life without having to switch to a complex reading
context when I see numbers.

On Nov 23, 2007 10:01 PM, Jason Johnson <[EMAIL PROTECTED]> wrote:
> On Nov 23, 2007 1:29 PM, Waldemar Kornewald <[EMAIL PROTECTED]> wrote:
> > Hi,
> > it looks like you mistakenly sent this only to me instead of to the list.
>
> Ugh.
>
> > Nobody forces anyone to make it so complicated.
>
> But it is complicated.  Or are you suggesting that only the precedence
> rules you happen to like are allowed and the rest thrown out?  What
> happens when people from other parts of math start using the language?
>  Remember those "icky" symbols you were complaining about in Haskell?
> Those are made to look as close as possible to the actual math
> symbols.  So why is it that you like the really trivial precedence
> rules but strongly dislike higher math symbols? :)
>
> > You *might* be right that functional programming is the best answer to
> > concurrency,
>
> It's not "me", it's a great many people who are actually researching this 
> stuff.
>
> > but to be fair you should also mention other solutions
> > like message-passing concurrency
>
> Ala Erlang (functional language that does not allow variable mutation)?
>
> > and transactional memory.
>
> Ala Haskell (pure functional language)?
>
> > The latter
> > is getting quite a bit of research lately, with Intel also working on
> > hardware extensions to increase performance and decrease
> > implementation complexity. You can't claim that functional programming
> > actually is the *only* or even *best* answer.
>
> All aspects are getting a lot of research.  Message passing has the
> distinction of being truly proven in the field by Erlang.  I didn't
> say functional programming was the best or only answer.  I said it
> makes the problem easier, which it does.  Most problems in concurrency
> programming come from dealing with variable mutation.  Take that away
> and those problems go away.
>

_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Reply via email to