Sadly, I find that the most US-based devs are of the opinion that Indian/Chinese/etc devs are all useless and will cause the project to be a failure.
They spout this nonsense because the alternative upsets their entire world-view of how things should be. The reality is that India and China will *almost certainly* have a larger number of better developers (if not now, then soon).
Those who go on about how indian/chinese schools do not teach students to "think critically" are delusional; understand that you are living in a society where the educational institutions place more emphasis on sports than on academics.
You are living in a country that values an airheaded jock - who can barely chew gum and walk at the same time - over a mathematics lover. It's not just the educational systems, it's the entire culture.
"Geek", "Nerd", etc are (are they still?) insults, when the word "jock" should be an insult. As an example of people taking pride in their ignorance, read the other comments attached to the parent. They all decry the competency of outsourced devs.
In other words, anyone that dares step outside of the slashdot groupthink or the Microsoft-sucks groupthink is to be ostracized.
The international community thinks OOXML sucks; thats one big fucking groupthink, hmmm???
Take a good look at those countries that voted for OOXML @ ISO. Aside from the USA,
all the others were countries that had been stuffed with microsoft partners.
Or to put things in perspective for you - even though people were/paid/ to
vote for OOXML, not enough people could be found to vote for it...
The fact is that this really does make MdI look bad; there are documented
problems that all first world countries found with OOXML. In addition, there is
an existing widely implemented standard. MdI instead rambles on about using
an encumbered, crippled specification. Considering the whole mono/.net moonlight/silverlight
thing, the only logical conclusion that one can draw is that MdI has microsofts
best interests at heart.
Really, the sooner he officially joins Microsoft, the better.
None of your precious little languages can ever solve the ambiguity problem. Observe:
May I suggest that you at least look at the languages I suggested
before going off the deep end? They've all solved at least one of the ambiguity problem,
the default argument problem, the nested function call problem and the named argument
problem. Go on, have a look at them.
I'd really love to see you implement a LISP dialect without using brackets to group stuff together. Really. What are you gonna do?
The argument was not to eliminate brackets, but thanks for knocking that strawman down. The argument I put forward
was that brackets are only needed for inner expressions (not outermost ones). Currently, function calls use
brackets even when there is no ambiguity.
Whatever you put side by side in LISP is a separate argument since it doesn't use infix notation. So, your comma argument doesn't work either. The comma operator is relevant only to infix languages.
Another nice strawman; what about haskell? That is infix. Look up the term curried functions.
*sarcasm set to "stun"*
Yeah, I'm sure he doesn't; especially as the
change suggested hasn't already been used in
languages far superior in expressiveness for at
least the last 30-odd years...
Oh, wait...
If you consider a language such as C++, it's possible to write function/method parameters that can have default values. Those are problematic too.
foo bar 3 4
foo(bar(3,4)) or foo(bar(3),4) ??
I'd suggest learning a little haskell, lisp and smalltalk (in that order)
so that you can see firsthand that the brackets to delimit the arguments
to a function are not really needed, and that the comma used to
separate arguments are also not needed.
Of course, brackets will still be used, but in the more accepted
math-like manner i.e. used to delimit expressions, with the outermost
expression not needing a delimiter.
With the current (non-math) way used in java, c++, etc, the
brackets solve a problem that they introduce. Languages that
do not use the brackets in this manner do not have this problem
you seem to think must exist.
Sure, its easy when you talk about changing sin(theta) to sin theta, but when you have ln(sqrt(x))+y and ln(sqrt(x+y)) and ln(sqrt(x)+y) and they all map to ln sqrt x+y, you start needing parens anyway to enforce sequence, whether explicitly to specify function arguments or to denote expression precedence.
Sure sure, brackets on the outside of the expression will still be
needed but I'd rather see "(sin x) + y" than "sin (x) + y", or
"(ln (sqrt x)) + y" than "ln (sqrt (x)) + y", or
"ln (sqrt x + y)" than "ln (sqrt (x + y))".
Effectively, brackets are only used for disambiguation, and not,
as currently, for everything even when the lack of brackets imply
no ambiguation.
Of course, taking this to the logical conclusion, you would
end up with lisp-ish syntax anyway, which has a damn sight more
expressive power than java-ish syntax anyway:-)
LaTeX is amazing, but hacking a plain text file is a bit rough for 95% of the people out there.
Actually, you might be pleasantly surprised if you actually did a rough poll. Most serious authors (i.e. anyone who actually wants to publish in a journal, book, etc) rather prefer simply typing in their material, instead of futzing with the GUI, trying to get the document to look decent.
It's only non-publication types of work that shine in a word-processor (letters, work reports, etc).
> Clearly the ISO bodies are being corrupted (packed) by MS > and I really don't understand why.
Actually, as a serving member of sc71l (the technical subcommittee tasked with providing a recommendation to our ISO representative to vote on behalf of the country)in South Africa, I object to this blatant painting of all the committee members with the same brush.
Some of us have worked immensely hard to ensure that the OOXML 'spec' is never a 'standard'. We spent a great deal of time preparing arguments, presentations and getting people from IBM, SUN and our local FLOSS businesses to present as well.
We voted against OOXML as a standard 13-2-2 (broken down as "NoWithComments-YesWithComments-YesWithoutComments ), so the real vote was more realistically 15-2 against!
Slashdot Mirror
Sadly, I find that the most US-based devs
:-)
are of the opinion that Indian/Chinese/etc
devs are all useless and will cause the
project to be a failure.
They spout this nonsense because the alternative
upsets their entire world-view of how things should
be. The reality is that India and China will
*almost certainly* have a larger number of better
developers (if not now, then soon).
Those who go on about how indian/chinese schools do
not teach students to "think critically" are
delusional; understand that you are living in a
society where the educational institutions place
more emphasis on sports than on academics.
You are living in a country that values an airheaded
jock - who can barely chew gum and walk at the same
time - over a mathematics lover. It's not just the
educational systems, it's the entire culture.
"Geek", "Nerd", etc are (are they still?) insults,
when the word "jock" should be an insult. As an
example of people taking pride in their ignorance,
read the other comments attached to the parent.
They all decry the competency of outsourced devs.
A case of ignorance being bliss I suppose
In other words, anyone that dares step outside of the slashdot groupthink or the Microsoft-sucks groupthink is to be ostracized.
/paid/ to
vote for OOXML, not enough people could be found to vote for it ...
The international community thinks OOXML sucks; thats one big fucking groupthink, hmmm???
Take a good look at those countries that voted for OOXML @ ISO. Aside from the USA, all the others were countries that had been stuffed with microsoft partners.
Or to put things in perspective for you - even though people were
The fact is that this really does make MdI look bad; there are documented problems that all first world countries found with OOXML. In addition, there is an existing widely implemented standard. MdI instead rambles on about using an encumbered, crippled specification. Considering the whole mono/.net moonlight/silverlight thing, the only logical conclusion that one can draw is that MdI has microsofts best interests at heart.
Really, the sooner he officially joins Microsoft, the better.
None of your precious little languages can ever solve the ambiguity problem. Observe:
May I suggest that you at least look at the languages I suggested before going off the deep end? They've all solved at least one of the ambiguity problem, the default argument problem, the nested function call problem and the named argument problem. Go on, have a look at them.
I'd really love to see you implement a LISP dialect without using brackets to group stuff together. Really. What are you gonna do?
The argument was not to eliminate brackets, but thanks for knocking that strawman down. The argument I put forward was that brackets are only needed for inner expressions (not outermost ones). Currently, function calls use brackets even when there is no ambiguity.
Whatever you put side by side in LISP is a separate argument since it doesn't use infix notation. So, your comma argument doesn't work either. The comma operator is relevant only to infix languages.
Another nice strawman; what about haskell? That is infix. Look up the term curried functions.
Never mind the GP, man. He doesn't have a clue.
...
...
*sarcasm set to "stun"*
Yeah, I'm sure he doesn't; especially as the change suggested hasn't already been used in languages far superior in expressiveness for at least the last 30-odd years
Oh, wait
If you consider a language such as C++, it's possible to write function/method parameters that can have default values. Those are problematic too. foo bar 3 4 foo(bar(3,4)) or foo(bar(3),4) ??
I'd suggest learning a little haskell, lisp and smalltalk (in that order) so that you can see firsthand that the brackets to delimit the arguments to a function are not really needed, and that the comma used to separate arguments are also not needed.
Of course, brackets will still be used, but in the more accepted math-like manner i.e. used to delimit expressions, with the outermost expression not needing a delimiter.
With the current (non-math) way used in java, c++, etc, the brackets solve a problem that they introduce. Languages that do not use the brackets in this manner do not have this problem you seem to think must exist.
Sure, its easy when you talk about changing sin(theta) to sin theta, but when you have ln(sqrt(x))+y and ln(sqrt(x+y)) and ln(sqrt(x)+y) and they all map to ln sqrt x+y, you start needing parens anyway to enforce sequence, whether explicitly to specify function arguments or to denote expression precedence.
:-)
Sure sure, brackets on the outside of the expression will still be needed but I'd rather see "(sin x) + y" than "sin (x) + y", or "(ln (sqrt x)) + y" than "ln (sqrt (x)) + y", or "ln (sqrt x + y)" than "ln (sqrt (x + y))".
Effectively, brackets are only used for disambiguation, and not, as currently, for everything even when the lack of brackets imply no ambiguation.
Of course, taking this to the logical conclusion, you would end up with lisp-ish syntax anyway, which has a damn sight more expressive power than java-ish syntax anyway
LaTeX is amazing, but hacking a plain text file is a bit rough for 95% of the people out there.
Actually, you might be pleasantly surprised if you actually did a rough poll. Most serious authors (i.e. anyone who actually wants to publish in a journal, book, etc) rather prefer simply typing in their material, instead of futzing with the GUI, trying to get the document to look decent.
It's only non-publication types of work that shine in a word-processor (letters, work reports, etc).
There... did I miss any major religion?
The FLOSS movement?
(I kid, I kid:-)
> Clearly the ISO bodies are being corrupted (packed) by MS
s ), so the
/my/ preparations at:
...).
> and I really don't understand why.
Actually, as a serving member of sc71l (the technical subcommittee
tasked with providing a recommendation to our ISO representative to
vote on behalf of the country)in South Africa, I object to this blatant
painting of all the committee members with the same brush.
Some of us have worked immensely hard to ensure that the OOXML
'spec' is never a 'standard'. We spent a great deal of time preparing
arguments, presentations and getting people from IBM, SUN and our
local FLOSS businesses to present as well.
We voted against OOXML as a standard 13-2-2 (broken down as
"NoWithComments-YesWithComments-YesWithoutComment
real vote was more realistically 15-2 against!
You can read one of
http://www.meraka.csir.co.za/~lmanickum/stansa/
Trust me, we worked very hard, and some of us are
still working on this (cleaning up the comments that
go with a "no" vote, etc
goose