I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.
C# is hindered by its predecessors and the Microsoft marketing
department. If Anders had his way, this language would be a one where
readable code isn't a near impossibility for non-trivial code; but no,
Microsoft marketing and C++/Java got in his way. The evidence is
blatently apparent in the language.
Microsoft, the company where money comes before technology, has struck
again. The repercussions affect us all.
Nov 16 '05
101  3824 
"Daniel Pratt" <ko******************@hotmail.com> wrote in message
news:u6**************@TK2MSFTNGP09.phx.gbl... Hi C# Learner,
"C# Learner" <cs****@learner.here> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl... I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.
C# is hindered by its predecessors and the Microsoft marketing
department. If Anders had his way, this language would be a one where
readable code isn't a near impossibility for non-trivial code; but no,
Microsoft marketing and C++/Java got in his way. The evidence is
blatently apparent in the language.
Microsoft, the company where money comes before technology, has struck
again. The repercussions affect us all.
No language that I've encountered would I consider perfect. Not even
close. Any language that I've seen is either filled with compromises or is
practically useless (or both). Have you found a language you like better,
or are you considering another vocation?
Regards,
Daniel
Hi and sorry but I have to add here some hints to my favorite language:
Smalltalk.
Smalltalk is pure OO and source-code readability is superior. It is
dynamically typed so type declarations are not necessary - it uses keyword
messages
aMessageBox titled: 'I have had enough' confirm: 'Do you like
Smalltalk?' onYes: [ Transcript show: 'read further'; cr ]
instead of
aMessageBox.Show( "'Do you like Smalltalk?", "'I have had enough'
confirm" ... );
Unfortunaltley major Smalltalk didn't integrate well in the past into the
Windows OS - VisualWorks / IBM VA have their own philospohy about using the
native OS
IBM VAST uses a Motif layer and VisualWorks emulated widgets.
Dolphin ( www.object-arts.com ) is a nice Windows-Smalltalk with a nice
Windows integration.
Smallscript is an ongoing work to integrate Smalltalk with .NET
We have created our own - still proprietary Smalltalk which has also a deep
OS Integration.
It is not easy to integrate Smalltalk with .NET - Traditionally Smalltalk
dialects have their own Virtual-Machine incl. JIT. CLR is too limited in
many ways to run Smalltalk
effectifley on it. David Simmons ( www.smallscript.org ) who was in the
design team of .NET is creating with S# for .NET.
Be carefull - if you enter the world of Smalltalk programming you will
probably never like to go back - which means today swiming against the
mainstream.
Regards, Frank Lesser, www.lesser-software.com
Chris A. R. <so*****@hotmail.com> wrote: It's hard to find anyone that knows how to write Threading code without
wrapping themselves in knots.
True.
Given that, I find the C/C++ programmers are
much more likely to have a clue on how to write working code in a Threaded
environment.
I'm not sure I'd go along with that - they may know how to write
working code in C/C++ in a threaded environment, but that doesn't mean
they'll know the .NET threading model. That's why whenever the
singleton pattern is discussed, there's always someone throwing the
Double Checked Locking Algorithm into the mix, despite it
a) not working as usually presented
b) almost always being a worse approach than various others
:(
I'd like to think I understand threading "better than most" but it
still scares the hell out of me really...
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] wrote: [...]
Personally the first thing I'd ditch from the above is the K&R
bracing...
Well, I have tried the other style (can't remember how it's termed...)
and it is my opinion that the K&R style makes code more readable, as it
places less emphasis on the individual blocks of code.
I'm not expecting everyone to share this viewpoint; I'm merely
expressing it.
I think the K&R bracing style is like Marmite -- you either love it or
you hate it :-)
"Chris A. R." <so*****@hotmail.com> wrote in
news:u9**************@TK2MSFTNGP10.phx.gbl: It's hard to find anyone that knows how to write Threading code without
wrapping themselves in knots. Given that, I find the C/C++ programmers
are much more likely to have a clue on how to write working code in a
Threaded environment. I also find that most VB programmers don't
understand the windows messaging architecture, whereas most C/C++
programmers do understand.
Of course, there are dud C/C++ programmers, but understanding the
foundation of the windows architecture is important for complex
programs. So, as lead engineer and architect at the company I work for,
pointy haired boss and all, I prefer people with C/C++ experience.
Odd. I'd prefer people with .NET experience. You see, It's better
to know how .NET works, than to know how win32 works, as .NET does a lot
for you and sometimes differently than in win32 (i.e.: there is no
messageing architecture to post messages between threads, threads don't
have their own messagepump etc.
FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP
Jon Skeet [C# MVP] wrote: [...]
Actually, I find that less readable than the straight returns, myself.
With returns in the middle of the method, I know that that's the end of
the useful path of that method. [...]
Out of interest, then, which of the top two code snippets would you go
for, only taking into account the code around the 'return' statements?
Here're the top two again:
FontTagElement GetFontTagElement()
{
//...
if (length == SingleElementPartCount) {
if (arr[FirstIndex] == FontNameSpecifier) {
string name = arr[FirstIndex];
return new FontTagElement(name);
} else {
int size = TryStringToInt(arr[FirstIndex]);
return new FontTagElement(size);
}
} else if (length == DualElementPartCount) {
string name = arr[FirstIndex];
int size = TryStringToInt(arr[SecondIndex]);
return new FontTagElement(name, size);
} else {
return null;
}
}
FontTagElement GetFontTagElement()
{
//...
if (length == SingleElementPartCount) {
if (arr[FirstIndex] == FontNameSpecifier) {
string name = arr[FirstIndex];
return new FontTagElement(name);
}
int size = TryStringToInt(arr[FirstIndex]);
return new FontTagElement(size);
}
if (length == DualElementPartCount) {
string name = arr[FirstIndex];
int size = TryStringToInt(arr[SecondIndex]);
return new FontTagElement(name, size);
}
return null;
}
C# Learner <cs****@learner.here> wrote: Jon Skeet [C# MVP] wrote:
[...]
Actually, I find that less readable than the straight returns, myself.
With returns in the middle of the method, I know that that's the end of
the useful path of that method. [...]
Out of interest, then, which of the top two code snippets would you go
for, only taking into account the code around the 'return' statements?
I think I'd use the first one, with the else clause. However, I'd
recode the first part to:
if (length==SingleElementPartCount)
{
string name = arr[FirstIndex];
if (name==FontNameSpecifier)
{
return new FontTagElement(name);
}
else
{
int size = TryStringToInt(name);
return new FontTagElement(size);
}
}
etc
In fact, I'd probably end up declaring name right at the top, as it's
such a common expression in your code.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Daniel O'Connell [C# MVP]" wrote:
"Julie" <ju***@nospam.com> wrote in message
news:40***************@nospam.com... C# Learner wrote:
Julie wrote:
> I'll take the language any day. It is their sucky, buggy, deficient
> IDE that
> gets my goat, day after day.
>
> So far, their IDE can handle "hello world" class projects, but not much
> more...
The IDE seems pretty solid to me; but I guess it could be a case of
different machines, different setups, etc.
How about a deal: you take the language and I take the IDE ;-P
Consider yourself lucky. Any commercial-scope project is way outside the
bounds of the IDE.
I'm currently working on one solution composed of maybe 30-40 projects of
C#,
managed C++, and native C++, with multiple forms, controls, etc.
It is a battle to get through a day w/o numerous restarts due to the piece
getting hung up on itself. As we speak, the compiler can't build a
project
because somewhere else the IDE has a file open (in this case, a debugging
pdb
file). Closing all files, and even the project/solution doesn't solve the
problem, the only solution is to restart and rebuild.
Try closing the IDE and deleting the .suo file. This sounds like a known bug
that has been cropping up for quite some time(I seem to recall filing a bug
report myself), there is hope it will be fixed in whidbey, but I don't know
if there was any official word on that and considering how hard it is to
reproduce I couldn't test. Though I havn't run into it in about a year it
does happen and it will drive you nuts. It seems to crop up most commonly
with large C# or C++ projects and *may* be related to the size of an output
assembly. I imagine someone else here knows waht I'm talking about and
remembers more details that I do.
If this is a known problem, where is the patch? Not coming, have to wait until
whidbey, standard line from Microsoft.
Let's not forget that this is the 13th rev (or so) of the MS compiler suite.
Bugs like this are not to be expected in a product like this, especially at the
price that it is. A *major* piece of crap, but what should I expect, MS is run by a bunch of
snot-nosed adolescents that think they know everything.
Not to sound harsh, but you pretty much sound like a know-it-all in all of
your posts. Considering the content of said posts I'd say you have a long
way to go before that attitude is anywhere near correct.
I'm hardly a know-it-all, but thanks for the comments. I've been programming
Windows since 3.0 -- I've seen how MS operates, and it is frustrating to try
and eek out a living w/ such shoddy tools and lackluster performance. I'm a
contract programmer, and I don't have the time each day to constantly fiddle w/
the fragility of the system, it costs me *big time*. 10+ years ago, Borland
gave MS some serious compiler competition (and had a far superior product), but
alas, those days are gone, so back to non-innovative buggy MS business as
usual.
Max Power wrote: C# Learner <cs****@learner.here> wrote in news:#g9rpoAHEHA.2576
@TK2MSFTNGP11.phx.gbl:
I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.
C# is hindered by its predecessors and the Microsoft marketing
department. If Anders had his way, this language would be a one where
readable code isn't a near impossibility for non-trivial code; but no,
Microsoft marketing and C++/Java got in his way. The evidence is
blatently apparent in the language.
Microsoft, the company where money comes before technology, has struck
again. The repercussions affect us all.
Actually, C#/C++/Java were developed by nerds. The real problem is nerds,
not MS. ;-)
"Very nice" *NERDS* definitions :) http://www.urbandictionary.com/define.php?term=nerd&f=1 http://www.hyperdictionary.com/search.aspx?define=nerd http://www.computeruser.com/resource...ml?lookup=2995
Marcin
Jon Skeet [C# MVP] wrote: C# Learner <cs****@learner.here> wrote:
Out of interest, then, which of the top two code snippets would you go
for, only taking into account the code around the 'return' statements?
I think I'd use the first one, with the else clause.
Okay.
However, I'd recode the first part to:
if (length==SingleElementPartCount)
{
string name = arr[FirstIndex];
if (name==FontNameSpecifier)
{
return new FontTagElement(name);
}
else
{
int size = TryStringToInt(name);
return new FontTagElement(size);
}
}
etc
In fact, I'd probably end up declaring name right at the top, as it's
such a common expression in your code.
Oops, yes! Looking back on it, I can't've been fully awake when I wrote
that method :-)
Regards,
Tom
"Julie" <ju***@nospam.com> skrev i meddelandet
news:40***************@nospam.com... "Daniel O'Connell [C# MVP]" wrote:
"Julie" <ju***@nospam.com> wrote in message
news:40***************@nospam.com... C# Learner wrote:
>
> Julie wrote:
>
> > I'll take the language any day. It is their sucky, buggy,
deficient> > IDE that
> > gets my goat, day after day.
> >
> > So far, their IDE can handle "hello world" class projects, but not
much> > more...
>
> The IDE seems pretty solid to me; but I guess it could be a case of
> different machines, different setups, etc.
>
> How about a deal: you take the language and I take the IDE ;-P
Consider yourself lucky. Any commercial-scope project is way outside
the bounds of the IDE.
I'm currently working on one solution composed of maybe 30-40 projects
of C#,
managed C++, and native C++, with multiple forms, controls, etc.
It is a battle to get through a day w/o numerous restarts due to the
piece getting hung up on itself. As we speak, the compiler can't build a
project
because somewhere else the IDE has a file open (in this case, a
debugging pdb
file). Closing all files, and even the project/solution doesn't solve
the problem, the only solution is to restart and rebuild.
Try closing the IDE and deleting the .suo file. This sounds like a known
bug that has been cropping up for quite some time(I seem to recall filing a
bug report myself), there is hope it will be fixed in whidbey, but I don't
know if there was any official word on that and considering how hard it is to
reproduce I couldn't test. Though I havn't run into it in about a year
it does happen and it will drive you nuts. It seems to crop up most
commonly with large C# or C++ projects and *may* be related to the size of an
output assembly. I imagine someone else here knows waht I'm talking about and
remembers more details that I do.
If this is a known problem, where is the patch? Not coming, have to wait
until whidbey, standard line from Microsoft.
Let's not forget that this is the 13th rev (or so) of the MS compiler
suite. Bugs like this are not to be expected in a product like this, especially
at the price that it is.
A *major* piece of crap, but what should I expect, MS is run by a
bunch of snot-nosed adolescents that think they know everything. Not to sound harsh, but you pretty much sound like a know-it-all in all
of your posts. Considering the content of said posts I'd say you have a
long way to go before that attitude is anywhere near correct.
I'm hardly a know-it-all, but thanks for the comments. I've been
programming Windows since 3.0 -- I've seen how MS operates, and it is frustrating to
try and eek out a living w/ such shoddy tools and lackluster performance. I'm
a contract programmer, and I don't have the time each day to constantly
fiddle w/ the fragility of the system, it costs me *big time*. 10+ years ago,
Borland gave MS some serious compiler competition (and had a far superior
product), but alas, those days are gone, so back to non-innovative buggy MS business as
usual.
So as a contract programmer you kind of have the option to decide which work
you take. If this is so bad, and to be expected of Microsoft then why not
change
your mo and move to java, linux, borland stuff etc? Or are you neglecting to
say
that even though you feel like this for the MS tools, they are still better
than the
others? Or what gives? Its like saying "I really want to loose weight,
honest *eats
a pound of sugar*" =)
//Andreas
"Julie" <ju***@nospam.com> wrote in message
news:40***************@nospam.com... Try closing the IDE and deleting the .suo file. This sounds like a known
bug
that has been cropping up for quite some time(I seem to recall filing a
bug
report myself), there is hope it will be fixed in whidbey, but I don't
know
if there was any official word on that and considering how hard it is to
reproduce I couldn't test. Though I havn't run into it in about a year it
does happen and it will drive you nuts. It seems to crop up most commonly
with large C# or C++ projects and *may* be related to the size of an
output
assembly. I imagine someone else here knows waht I'm talking about and
remembers more details that I do.
If this is a known problem, where is the patch? Not coming, have to wait
until
whidbey, standard line from Microsoft.
Let's not forget that this is the 13th rev (or so) of the MS compiler
suite.
Bugs like this are not to be expected in a product like this, especially
at the
price that it is.
As I said, its a rather complex one. I've yet to meet anyone who can
reproduce it at will. Sorry but a bug I've heard maybe 6 complaints about in
the last 2 years that would require a considerable amount of time to fix
isn't something that warrents being rushed to in my opinion. Especially when
virtually everyone who has had it managed to get around it by modifying
their project layout slightly. Its annoying but its not a show stopper. At
worst, get nant and build with that.
The new project system in whidbey will hopefully squash it, but I can't tell
you for sure. The bug is strange and transient, and its rather hard to
reproduce even when I have a project that exhibits in in some situations. > A *major* piece of crap, but what should I expect, MS is run by a bunch
> of
> snot-nosed adolescents that think they know everything.
Not to sound harsh, but you pretty much sound like a know-it-all in all
of
your posts. Considering the content of said posts I'd say you have a long
way to go before that attitude is anywhere near correct.
I'm hardly a know-it-all, but thanks for the comments. I've been
programming
Windows since 3.0 -- I've seen how MS operates, and it is frustrating to
try
and eek out a living w/ such shoddy tools and lackluster performance. I'm
a
contract programmer, and I don't have the time each day to constantly
fiddle w/
the fragility of the system, it costs me *big time*. 10+ years ago,
Borland
gave MS some serious compiler competition (and had a far superior
product), but
alas, those days are gone, so back to non-innovative buggy MS business as
usual.
Frankly, I would suggest either finding another profession or another system
to work in\build with. I hear Delphi is nice, sharp develop is decent, and
borland C# builder isn't bad either.
Personally I rarely have problems to the point where I need to come on
newsgroups and be snotty about it. If you want help with something ask for
help, if you want to provide answers, provide correct, precise, and
non-predjudiced answers, but if you want to bitch about things(especially
everything except the C# langauge) there are plenty of newsgroups to suit
your needs, its really rather off focus here. I don't have much sympathy for
people who come here to whine, bitch, pass incorrect information, and ask
for help simultaneously.
I rather resent having to waste time reading these posts. This goes to you,
C# Learner, and anyone else here who is even peripherally focused on
complaining. I bothered to respond to you only because I could provide a
little insight into your problem, but you have to take my annoyance and
disdain along with it. I won't let petty whining stop me from providing any
answers I might be able to give, but I won't always do it silently.
"Andreas Håkansson" <andy.h (at) telia.com> wrote in message
news:eK**************@TK2MSFTNGP10.phx.gbl...
"Julie" <ju***@nospam.com> skrev i meddelandet
news:40***************@nospam.com... "Daniel O'Connell [C# MVP]" wrote:
"Julie" <ju***@nospam.com> wrote in message
news:40***************@nospam.com...
> C# Learner wrote:
>>
>> Julie wrote:
>>
>> > I'll take the language any day. It is their sucky, buggy, deficient >> > IDE that
>> > gets my goat, day after day.
>> >
>> > So far, their IDE can handle "hello world" class projects, but
not much >> > more...
>>
>> The IDE seems pretty solid to me; but I guess it could be a case of
>> different machines, different setups, etc.
>>
>> How about a deal: you take the language and I take the IDE ;-P
>
> Consider yourself lucky. Any commercial-scope project is way
outside the > bounds of the IDE.
>
> I'm currently working on one solution composed of maybe 30-40
projects of > C#,
> managed C++, and native C++, with multiple forms, controls, etc.
>
> It is a battle to get through a day w/o numerous restarts due to the piece > getting hung up on itself. As we speak, the compiler can't build a
> project
> because somewhere else the IDE has a file open (in this case, a debugging > pdb
> file). Closing all files, and even the project/solution doesn't
solve the > problem, the only solution is to restart and rebuild.
>
Try closing the IDE and deleting the .suo file. This sounds like a
known bug that has been cropping up for quite some time(I seem to recall filing
a bug report myself), there is hope it will be fixed in whidbey, but I don't know if there was any official word on that and considering how hard it is
to reproduce I couldn't test. Though I havn't run into it in about a year it does happen and it will drive you nuts. It seems to crop up most commonly with large C# or C++ projects and *may* be related to the size of an output assembly. I imagine someone else here knows waht I'm talking about and
remembers more details that I do.
If this is a known problem, where is the patch? Not coming, have to
wait until whidbey, standard line from Microsoft.
Let's not forget that this is the 13th rev (or so) of the MS compiler suite. Bugs like this are not to be expected in a product like this, especially
at the price that it is.
> A *major* piece of crap, but what should I expect, MS is run by a
bunch of > snot-nosed adolescents that think they know everything.
Not to sound harsh, but you pretty much sound like a know-it-all in
all of your posts. Considering the content of said posts I'd say you have a long way to go before that attitude is anywhere near correct.
I'm hardly a know-it-all, but thanks for the comments. I've been
programming Windows since 3.0 -- I've seen how MS operates, and it is frustrating to
try and eek out a living w/ such shoddy tools and lackluster performance.
I'm a contract programmer, and I don't have the time each day to constantly fiddle w/ the fragility of the system, it costs me *big time*. 10+ years ago,
Borland gave MS some serious compiler competition (and had a far superior
product), but alas, those days are gone, so back to non-innovative buggy MS business
as usual.
So as a contract programmer you kind of have the option to decide which
work you take. If this is so bad, and to be expected of Microsoft then why not
change
your mo and move to java, linux, borland stuff etc? Or are you neglecting
to say
that even though you feel like this for the MS tools, they are still
better than the
others? Or what gives? Its like saying "I really want to loose weight,
honest *eats
a pound of sugar*" =)
//Andreas
Probably because as a contractor they are at the mercy of the hosting
company. It is rare to come in and completely change a company's
environment, even if there are better choices as you mention. Usual mantra
as a contractor is "anything, anywhere, anytime" (that's what I used when I
did body-shop work). Best bet is to keep whatever they have and plug them
for lot's of overtime if it's buggy.
bob
C# Learner <cs****@learner.here> wrote in news:#g9rpoAHEHA.2576
@TK2MSFTNGP11.phx.gbl: I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code that's both
readable and consistent, impossible.
C# is hindered by its predecessors and the Microsoft marketing
department. If Anders had his way, this language would be a one where
readable code isn't a near impossibility for non-trivial code; but no,
Microsoft marketing and C++/Java got in his way. The evidence is
blatently apparent in the language.
Microsoft, the company where money comes before technology, has struck
again. The repercussions affect us all.
You could always use VB.NET, if you like its constructs better. No-
one is forcing you to use just C#, as VB.NET can do what you want too.
(except a little operator overloading limitations here and there...)
FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP
Daniel O'Connell [C# MVP] wrote:
<snip>
If you can't take the heat, get out of the kitchen.
Daniel O'Connell [C# MVP] wrote: Not to sound harsh, but you pretty much sound like a know-it-all in all of
your posts. Considering the content of said posts I'd say you have a long
way to go before that attitude is anywhere near correct.
To be honest, I think that you make yourself out to be a _god_ in /your/
posts.
I remember the first time I ever replied to you in a thread. I think
the thread was on the subject of coding with Notepad when not using an
IDE. I posted a reply to you giving a joke about Notepad.
From your reply to my post, I got the impression that you were
thinking, "Who the hell are you to reply to me?!"
I get a similar impression to many of your posts.
C# Learner <cs****@learner.here> wrote: Not to sound harsh, but you pretty much sound like a know-it-all in all of
your posts. Considering the content of said posts I'd say you have a long
way to go before that attitude is anywhere near correct.
To be honest, I think that you make yourself out to be a _god_ in /your/
posts.
I remember the first time I ever replied to you in a thread. I think
the thread was on the subject of coding with Notepad when not using an
IDE. I posted a reply to you giving a joke about Notepad.
The only thread I can see on groups.google.com where you posted and
there was anything about Notepad, Daniel didn't post at all. Were you
thinking of William Stacey, perhaps?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] wrote: C# Learner <cs****@learner.here> wrote:
Not to sound harsh, but you pretty much sound like a know-it-all in all of
your posts. Considering the content of said posts I'd say you have a long
way to go before that attitude is anywhere near correct.
To be honest, I think that you make yourself out to be a _god_ in /your/
posts.
I remember the first time I ever replied to you in a thread. I think
the thread was on the subject of coding with Notepad when not using an
IDE. I posted a reply to you giving a joke about Notepad.
The only thread I can see on groups.google.com where you posted and
there was anything about Notepad, Daniel didn't post at all. Were you
thinking of William Stacey, perhaps?
You're right -- I made a mistake here, confusing Daniel with William.
My stated general feeling about Daniel's posts still remains, though.
"C# Learner" <cs****@learner.here> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl... Daniel O'Connell [C# MVP] wrote:
Not to sound harsh, but you pretty much sound like a know-it-all in all
of your posts. Considering the content of said posts I'd say you have a
long way to go before that attitude is anywhere near correct.
To be honest, I think that you make yourself out to be a _god_ in /your/
posts.
Now now, I'm a jerk, not a god, ;).
I remember the first time I ever replied to you in a thread. I think the
thread was on the subject of coding with Notepad when not using an IDE. I
posted a reply to you giving a joke about Notepad.
From your reply to my post, I got the impression that you were thinking,
"Who the hell are you to reply to me?!"
I get a similar impression to many of your posts.
Your first reply to me, as best I can tell, was on the subject of naming
conventions. I argued that forcing all developers to use one single
convention was impossible while you felt it should be done. I don't see
where I came off as egotistical there however. Indeed I can only find 3
references to notepad in any of my posts, you were involved with none.
Now, maybe I am arrogant. It really doesn't matter to me much. I'm here to
help when I can, learn when I can't, and participate in the rare interesting
discussion where there isn't an answer. I don't think I'm particularly
egotistical, but if you feel my posts are, then you are free to ignore them.
Also, in general I prefer responses to silence. An extra post doesn't take
up much time to read, as long as its somewhat on subject. Generally the only
time I'll lambaste a reply is when its purpose is entirely to 1) enrage, 2)
bitch, or 3) tell me I'm wrong because the person doesn't want my answer to
be right. (I will often reply sharply to someone who is intentionally
spreading mis-information, either by willful ignorance or by malicious
intent, but that isn't strictly applied to replies to my posts).
I think you will find in this newsgroup, people who are very passionate
about the technology they work in and down right top-notch. It really is a
no bullshit approach. If you are wrong, expect to get chewed thoroughly.
There seldom will be a nice way to spin it. It may not be politically
correct but I believe if you leave your feelings at the door, you can
definitely learn in here.
At least you will learn to post technically accurate stuff or research
issues thoroughly before you post. I am very guilty of jumping technically
inaccurate posters (something i learned in here btw). And I've been jumped
more times than i care to remember. It's rarely personal. It's tough love.
You grow to be technically correct as a result. And that makes you a better
professional.
--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here... http://tinyurl.com/27cok
"C# Learner" <cs****@learner.here> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl... Daniel O'Connell [C# MVP] wrote:
Not to sound harsh, but you pretty much sound like a know-it-all in all
of your posts. Considering the content of said posts I'd say you have a
long way to go before that attitude is anywhere near correct.
To be honest, I think that you make yourself out to be a _god_ in /your/
posts.
I remember the first time I ever replied to you in a thread. I think
the thread was on the subject of coding with Notepad when not using an
IDE. I posted a reply to you giving a joke about Notepad.
From your reply to my post, I got the impression that you were
thinking, "Who the hell are you to reply to me?!"
I get a similar impression to many of your posts.
Frans & Jon,
Perhaps I should have clarified... of course I prefer people with .Net
experience. I was referring to a previous posting talking about VB versus
C/C++ programmers (I left out Java programmers, since they may have a clue
about OOP, but usually not about the Windows architecture).
So, the comparison I was making was in pre-.Net, windows directed languages
only. While there is no message pump for threads, it is important to
understand how threading works on the GUI components and how Invoke,
BeginInvoke, and EndInvoke actually do work with the GUI's message
architecture in these situations.
Continuing on that concept, there are often times when knowing the
underlying architecture can make a programmers ability to program .Net
programs a lot better.
Chris A.R.
"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> wrote in message
news:Xn********************************@207.46.248 .16... "Chris A. R." <so*****@hotmail.com> wrote in
news:u9**************@TK2MSFTNGP10.phx.gbl:
It's hard to find anyone that knows how to write Threading code without
wrapping themselves in knots. Given that, I find the C/C++ programmers
are much more likely to have a clue on how to write working code in a
Threaded environment. I also find that most VB programmers don't
understand the windows messaging architecture, whereas most C/C++
programmers do understand.
Of course, there are dud C/C++ programmers, but understanding the
foundation of the windows architecture is important for complex
programs. So, as lead engineer and architect at the company I work for,
pointy haired boss and all, I prefer people with C/C++ experience.
Odd. I'd prefer people with .NET experience. You see, It's better
to know how .NET works, than to know how win32 works, as .NET does a lot
for you and sometimes differently than in win32 (i.e.: there is no
messageing architecture to post messages between threads, threads don't
have their own messagepump etc.
FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP
Daniel O'Connell [C# MVP] wrote: "C# Learner" <cs****@learner.here> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl...
Daniel O'Connell [C# MVP] wrote:
Not to sound harsh, but you pretty much sound like a know-it-all in all
of your posts. Considering the content of said posts I'd say you have a
long way to go before that attitude is anywhere near correct.
To be honest, I think that you make yourself out to be a _god_ in /your/
posts.
Now now, I'm a jerk, not a god, ;).
I remember the first time I ever replied to you in a thread. I think the
thread was on the subject of coding with Notepad when not using an IDE. I
posted a reply to you giving a joke about Notepad.
From your reply to my post, I got the impression that you were thinking,
"Who the hell are you to reply to me?!"
I get a similar impression to many of your posts.
Your first reply to me, as best I can tell, was on the subject of naming
conventions. I argued that forcing all developers to use one single
convention was impossible while you felt it should be done. I don't see
where I came off as egotistical there however. Indeed I can only find 3
references to notepad in any of my posts, you were involved with none.
I was wrong, and confused you with someone else; sorry.
I think you're right that the first thread where we communicated was the
thread on naming conventions. In it, you were not unfriendly at all.
Now, maybe I am arrogant. It really doesn't matter to me much. I'm here to
help when I can, learn when I can't, and participate in the rare interesting
discussion where there isn't an answer. I don't think I'm particularly
egotistical, but if you feel my posts are, then you are free to ignore them.
Also, in general I prefer responses to silence. An extra post doesn't take
up much time to read, as long as its somewhat on subject. Generally the only
time I'll lambaste a reply is when its purpose is entirely to 1) enrage, 2)
bitch, or 3) tell me I'm wrong because the person doesn't want my answer to
be right. (I will often reply sharply to someone who is intentionally
spreading mis-information, either by willful ignorance or by malicious
intent, but that isn't strictly applied to replies to my posts).
I am pleasantly surprised that your reply (quoted here) isn't a flame.
"C# Learner" <cs****@learner.here> wrote in message
news:O8**************@TK2MSFTNGP12.phx.gbl... Daniel O'Connell [C# MVP] wrote:
"C# Learner" <cs****@learner.here> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl...
Daniel O'Connell [C# MVP] wrote:
Not to sound harsh, but you pretty much sound like a know-it-all in all
of your posts. Considering the content of said posts I'd say you have a
long way to go before that attitude is anywhere near correct.
To be honest, I think that you make yourself out to be a _god_ in /your/
posts.
Now now, I'm a jerk, not a god, ;).
I remember the first time I ever replied to you in a thread. I think the
thread was on the subject of coding with Notepad when not using an IDE.
I posted a reply to you giving a joke about Notepad.
From your reply to my post, I got the impression that you were thinking,
"Who the hell are you to reply to me?!"
I get a similar impression to many of your posts.
Your first reply to me, as best I can tell, was on the subject of naming
conventions. I argued that forcing all developers to use one single
convention was impossible while you felt it should be done. I don't see
where I came off as egotistical there however. Indeed I can only find 3
references to notepad in any of my posts, you were involved with none.
I was wrong, and confused you with someone else; sorry.
I think you're right that the first thread where we communicated was the
thread on naming conventions. In it, you were not unfriendly at all.
Now, maybe I am arrogant. It really doesn't matter to me much. I'm here
to help when I can, learn when I can't, and participate in the rare
interesting discussion where there isn't an answer. I don't think I'm
particularly egotistical, but if you feel my posts are, then you are free
to ignore them.
Also, in general I prefer responses to silence. An extra post doesn't
take up much time to read, as long as its somewhat on subject. Generally
the only time I'll lambaste a reply is when its purpose is entirely to 1)
enrage, 2) bitch, or 3) tell me I'm wrong because the person doesn't want
my answer to be right. (I will often reply sharply to someone who is
intentionally spreading mis-information, either by willful ignorance or
by malicious intent, but that isn't strictly applied to replies to my
posts).
I am pleasantly surprised that your reply (quoted here) isn't a flame.
There is no reason to flame you. However I don't think you have much
standing to be rude yourself.
Daniel O'Connell [C# MVP] wrote:
[...] I am pleasantly surprised that your reply (quoted here) isn't a flame.
There is no reason to flame you. However I don't think you have much
standing to be rude yourself.
I wasn't trying to be rude; I was just letting you know that I was
pleasantly surprised in not getting flamed. threads don't
have their own messagepump etc.
actually, .Net threads don't have access to the message queue - i.e. no
inherent GetMessage/DispatchMessage support from which to build a pump.
roy fine
C# Learner wrote: Daniel O'Connell [C# MVP] wrote:
[...]
I am pleasantly surprised that your reply (quoted here) isn't a flame.
There is no reason to flame you. However I don't think you have much
standing to be rude yourself.
I wasn't trying to be rude; I was just letting you know that I was
pleasantly surprised in not getting flamed.
Or did you mean my other two posts about god and the kitchen? Just to
make sure...
It's hard to find anyone that knows how to write Threading code without
wrapping themselves in knots. Given that, I find the C/C++ programmers are
much more likely to have a clue on how to write working code in a Threaded
environment. I also find that most VB programmers don't understand the
windows messaging architecture, whereas most C/C++ programmers do
understand.
Of course, there are dud C/C++ programmers, but understanding the foundation
of the windows architecture is important for complex programs. So, as lead
engineer and architect at the company I work for, pointy haired boss and
all, I prefer people with C/C++ experience.
Chris A.R.
"microsoft.public.dotnet.languages.csharp"
<an*******@discussions.microsoft.com> wrote in message
news:A3**********************************@microsof t.com... I also disagree with the industry. Many places are going VB.NET because
of > the number of VB and ASP developers they are retraining.
terrible. generally speaking, I'd have more faith in Java & C
developers than VB and ASP people. having experienced frustration of
working with these VB and ASP people.
<snip>
Odd. I'd prefer people with .NET experience. You see, It's better
to know how .NET works, than to know how win32 works, as .NET does a lot
for you and sometimes differently than in win32 (i.e.: there is no
messageing architecture to post messages between threads, threads don't
have their own messagepump etc.
I have to disagree. I find it important to understand not only the tool that
is in your hand, but where it came from and the design choices that were
made in building it (i.e. the limitations and why they exist).
It may be that you can do 95% or more of your work without needing to know
what lies below the surface, but the small percentage that is left can be
the difference between relying on voodoo programming and being able to
design a good solution or fix a difficult problem. You can be a good .net
programmer without a win32 background, but it's a lot tougher then for
someone with a good win32 background.
Programmers certainly need experience in .net, but if that's all they have
there will be some problems that are just plain mysterious (and perhaps
unsolvable) to them. Part of that is because the .net platform is still
immature and you can't go very far before it p/invokes back to a win32 API
or COM object. I think you'll find that a number of the
limitations/restrictions of the .net platform and the BCL are directly
derived (even when it's not obvious) from the platform.
As the platform matures more services will be ported to .NET so this will be
less of a problem, but that could be a long ways in the future.
Dave
Chris A. R. <so*****@hotmail.com> wrote: It's hard to find anyone that knows how to write Threading code without
wrapping themselves in knots.
True.
Given that, I find the C/C++ programmers are
much more likely to have a clue on how to write working code in a Threaded
environment.
I'm not sure I'd go along with that - they may know how to write
working code in C/C++ in a threaded environment, but that doesn't mean
they'll know the .NET threading model. That's why whenever the
singleton pattern is discussed, there's always someone throwing the
Double Checked Locking Algorithm into the mix, despite it
a) not working as usually presented
b) almost always being a worse approach than various others
:(
I'd like to think I understand threading "better than most" but it
still scares the hell out of me really...
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Chris A. R." <so*****@hotmail.com> wrote in
news:u9**************@TK2MSFTNGP10.phx.gbl: It's hard to find anyone that knows how to write Threading code without
wrapping themselves in knots. Given that, I find the C/C++ programmers
are much more likely to have a clue on how to write working code in a
Threaded environment. I also find that most VB programmers don't
understand the windows messaging architecture, whereas most C/C++
programmers do understand.
Of course, there are dud C/C++ programmers, but understanding the
foundation of the windows architecture is important for complex
programs. So, as lead engineer and architect at the company I work for,
pointy haired boss and all, I prefer people with C/C++ experience.
Odd. I'd prefer people with .NET experience. You see, It's better
to know how .NET works, than to know how win32 works, as .NET does a lot
for you and sometimes differently than in win32 (i.e.: there is no
messageing architecture to post messages between threads, threads don't
have their own messagepump etc.
FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP
"Chris A. R." <so*****@hotmail.com> wrote in
news:uA**************@TK2MSFTNGP10.phx.gbl: So, the comparison I was making was in pre-.Net, windows directed
languages only. While there is no message pump for threads, it is
important to understand how threading works on the GUI components and
how Invoke, BeginInvoke, and EndInvoke actually do work with the GUI's
message architecture in these situations.
I disagree. The reason for that is that .NET is a layer abstracting
away the win32 architecture. It provides a new API. If a developer reads
and understands the .NET methods like BeginInvoke() and friends (there was
a nice discussion about these on the DOT-NET developmentor list recently),
it *should* be fine. After all, those are the routines a developer works
with. Even if the developer understands that below the surface WM_*
messages are sent to messagepumps, it doesn't matter, as the developer
can't do a thing about it.
Continuing on that concept, there are often times when knowing the
underlying architecture can make a programmers ability to program .Net
programs a lot better.
This is partly true for winforms control usage, for the rest, I
don't think it is that important. Partly true as in: why do I have to do
an Application.DoEvents() here and why will my program lock up when I do
that right before a TreeView.EndUpdate() ? For the rest, it's out of your
hands anyway, the information that disabling a textbox control will call
Win32's SendMessage() below the surface is great, but it only helps you
understand why some things work differently than expected, it can't help
you fix it.
Frans
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP
"Dave" <no****************@wi.rr.com> wrote in
news:uO**************@TK2MSFTNGP11.phx.gbl: <snip> Odd. I'd prefer people with .NET experience. You see, It's better
to know how .NET works, than to know how win32 works, as .NET does a
lot for you and sometimes differently than in win32 (i.e.: there is no
messageing architecture to post messages between threads, threads don't
have their own messagepump etc.
I have to disagree. I find it important to understand not only the tool
that is in your hand, but where it came from and the design choices that
were made in building it (i.e. the limitations and why they exist).
if you require that information, OR the documentation is not up to
par OR the API is not up to par.
It may be that you can do 95% or more of your work without needing to
know what lies below the surface, but the small percentage that is left
can be the difference between relying on voodoo programming and being
able to design a good solution or fix a difficult problem. You can be a
good .net programmer without a win32 background, but it's a lot tougher
then for someone with a good win32 background.
I fail to see that. I mean: does it help you if you understand how
Win32's messaging works? It's an asynchronous architecture. .NET is not
(unless you use asynchronous routines). It's about concepts: what's a
thread, what's MTA, what's STA, how do threads communicate, what's the
difference between a thread and a process in windows terms (because on
Unix it's different). What's thread local storage etc. etc. If you
understand these concepts, you can pick up the .NET documentation and
check for implementations of these concepts. After that, use the
implementations on .NET. I don't see why it is important to understand how
it works below the surface. Ok, it's nice to know from a geeky point of
view, but for the rest I don't think it's important.
I think the reasoning behind your point is that in win32 you were
forced to understand the concepts first, because it is a big giant api and
no namespaces/classes which group the functionality (ok, dll's perhaps,
but you start with the platform SDK, 1 big api doc). In .NET it is easy to
run into a Thread class, oh what can it do? Oh that's nice, let's try...
*poof*. However if people understand the concepts, I don't think you need
to understand what win32 does below the surface.
Programmers certainly need experience in .net, but if that's all they
have there will be some problems that are just plain mysterious (and
perhaps unsolvable) to them. Part of that is because the .net platform
is still immature and you can't go very far before it p/invokes back to
a win32 API or COM object. I think you'll find that a number of the
limitations/restrictions of the .net platform and the BCL are directly
derived (even when it's not obvious) from the platform.
true, however the knowledge of these limitations is also learned
from using .NET: 'it can't do this'. Why it can't do this is not
important, because you can't change it anyway :)
For one area I agree with you: COM+ / ServicedComponent.
FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP
"Daniel O'Connell [C# MVP]" wrote:
"Julie" <ju***@nospam.com> wrote in message
news:40***************@nospam.com... C# Learner wrote:
Julie wrote:
> I'll take the language any day. It is their sucky, buggy, deficient
> IDE that
> gets my goat, day after day.
>
> So far, their IDE can handle "hello world" class projects, but not much
> more...
The IDE seems pretty solid to me; but I guess it could be a case of
different machines, different setups, etc.
How about a deal: you take the language and I take the IDE ;-P
Consider yourself lucky. Any commercial-scope project is way outside the
bounds of the IDE.
I'm currently working on one solution composed of maybe 30-40 projects of
C#,
managed C++, and native C++, with multiple forms, controls, etc.
It is a battle to get through a day w/o numerous restarts due to the piece
getting hung up on itself. As we speak, the compiler can't build a
project
because somewhere else the IDE has a file open (in this case, a debugging
pdb
file). Closing all files, and even the project/solution doesn't solve the
problem, the only solution is to restart and rebuild.
Try closing the IDE and deleting the .suo file. This sounds like a known bug
that has been cropping up for quite some time(I seem to recall filing a bug
report myself), there is hope it will be fixed in whidbey, but I don't know
if there was any official word on that and considering how hard it is to
reproduce I couldn't test. Though I havn't run into it in about a year it
does happen and it will drive you nuts. It seems to crop up most commonly
with large C# or C++ projects and *may* be related to the size of an output
assembly. I imagine someone else here knows waht I'm talking about and
remembers more details that I do.
If this is a known problem, where is the patch? Not coming, have to wait until
whidbey, standard line from Microsoft.
Let's not forget that this is the 13th rev (or so) of the MS compiler suite.
Bugs like this are not to be expected in a product like this, especially at the
price that it is. A *major* piece of crap, but what should I expect, MS is run by a bunch of
snot-nosed adolescents that think they know everything.
Not to sound harsh, but you pretty much sound like a know-it-all in all of
your posts. Considering the content of said posts I'd say you have a long
way to go before that attitude is anywhere near correct.
I'm hardly a know-it-all, but thanks for the comments. I've been programming
Windows since 3.0 -- I've seen how MS operates, and it is frustrating to try
and eek out a living w/ such shoddy tools and lackluster performance. I'm a
contract programmer, and I don't have the time each day to constantly fiddle w/
the fragility of the system, it costs me *big time*. 10+ years ago, Borland
gave MS some serious compiler competition (and had a far superior product), but
alas, those days are gone, so back to non-innovative buggy MS business as
usual.
> > I have to disagree. I find it important to understand not only the tool
that is in your hand, but where it came from and the design choices that
were made in building it (i.e. the limitations and why they exist).
if you require that information, OR the documentation is not up to
par OR the API is not up to par.
The documentation is good enough for most cases but there are many times
when it isn't. This was especially true in the early days of .net - it's
gotten a lot better.
I fail to see that. I mean: does it help you if you understand how
Win32's messaging works? It's an asynchronous architecture. .NET is not
(unless you use asynchronous routines). It's about concepts: what's a
thread, what's MTA, what's STA, how do threads communicate, what's the
difference between a thread and a process in windows terms (because on
Unix it's different). What's thread local storage etc. etc. If you
understand these concepts, you can pick up the .NET documentation and
check for implementations of these concepts. After that, use the
implementations on .NET. I don't see why it is important to understand how
it works below the surface. Ok, it's nice to know from a geeky point of
view, but for the rest I don't think it's important.
Some of its pure geek curiousity, but often it makes a practical difference.
For one, there's a lot of win32-isms in the System.Forms classes. There is
some behavior that can only be explained by knowing that behind the scenes a
bit of functionality was implemented by posting a message to a hidden
window.
I think the reasoning behind your point is that in win32 you were
forced to understand the concepts first, because it is a big giant api and
no namespaces/classes which group the functionality (ok, dll's perhaps,
but you start with the platform SDK, 1 big api doc).
Agreed. But I don't think .NET is all that different. I regard .NET as an
operating system, and to write non-trivial, effective code you have to
understand a lot. Sure, you can write a .NET HelloWorld in a flash, but I
can do that just as fast in MFC. You can't get far before you hit a wall
that you can't get beyond until you understand lots of other concepts.
In .NET it is easy to
run into a Thread class, oh what can it do? Oh that's nice, let's try...
*poof*. However if people understand the concepts, I don't think you need
to understand what win32 does below the surface.
Threads are interesting. You can get a lot done without knowing much about
win32, but even here you cannot get far or do a lot without needing to
understand what lies below the surface. Here's one example....why are .net
mutexes visible across processes on the same machine but .net events are
not? Another is that a thread must be in a runnable state before certain
operations will take affect (a ThreadAbort wont actually be delivered until
the thread is running).
Another aspect of threading that is directly related to win32 is the entire
topic of exception handling. This is built directly on top of the SEH
mechanism of win32, and if you want to understand why things happen as they
do you must understand win32 SEH. From what I've read of the exception
portion of the ECMA spec, it was written around some win32 assumptions.
In the original ROTOR sources, because the exception handling was built on
top of a UNIX model the actual delivery of some exception semantics is
subtly different.
Programmers certainly need experience in .net, but if that's all they
have there will be some problems that are just plain mysterious (and
perhaps unsolvable) to them. Part of that is because the .net platform
is still immature and you can't go very far before it p/invokes back to
a win32 API or COM object. I think you'll find that a number of the
limitations/restrictions of the .net platform and the BCL are directly
derived (even when it's not obvious) from the platform.
true, however the knowledge of these limitations is also learned
from using .NET: 'it can't do this'. Why it can't do this is not
important, because you can't change it anyway :)
Hmmm. I agree in part. Quite often what I've found is that a rule is stated
as "Always do this" or "Never do that" but given sufficient understanding of
where those rules come from they should really be stated as "Almost always
do this" or "Almost never do that". It is knowing when it is allowable to
deviate, or when your circumstances are sufficiently different that you can
"do that" that makes all the difference. This can only come from a deep
understanding of the platform.
For one area I agree with you: COM+ / ServicedComponent.
I have the happy pleasure of never working with those :-) So I've skipped
over many of the COM problems (apartment models are just nuts).
"Julie" <ju***@nospam.com> skrev i meddelandet
news:40***************@nospam.com... "Daniel O'Connell [C# MVP]" wrote:
"Julie" <ju***@nospam.com> wrote in message
news:40***************@nospam.com... C# Learner wrote:
>
> Julie wrote:
>
> > I'll take the language any day. It is their sucky, buggy,
deficient> > IDE that
> > gets my goat, day after day.
> >
> > So far, their IDE can handle "hello world" class projects, but not
much> > more...
>
> The IDE seems pretty solid to me; but I guess it could be a case of
> different machines, different setups, etc.
>
> How about a deal: you take the language and I take the IDE ;-P
Consider yourself lucky. Any commercial-scope project is way outside
the bounds of the IDE.
I'm currently working on one solution composed of maybe 30-40 projects
of C#,
managed C++, and native C++, with multiple forms, controls, etc.
It is a battle to get through a day w/o numerous restarts due to the
piece getting hung up on itself. As we speak, the compiler can't build a
project
because somewhere else the IDE has a file open (in this case, a
debugging pdb
file). Closing all files, and even the project/solution doesn't solve
the problem, the only solution is to restart and rebuild.
Try closing the IDE and deleting the .suo file. This sounds like a known
bug that has been cropping up for quite some time(I seem to recall filing a
bug report myself), there is hope it will be fixed in whidbey, but I don't
know if there was any official word on that and considering how hard it is to
reproduce I couldn't test. Though I havn't run into it in about a year
it does happen and it will drive you nuts. It seems to crop up most
commonly with large C# or C++ projects and *may* be related to the size of an
output assembly. I imagine someone else here knows waht I'm talking about and
remembers more details that I do.
If this is a known problem, where is the patch? Not coming, have to wait
until whidbey, standard line from Microsoft.
Let's not forget that this is the 13th rev (or so) of the MS compiler
suite. Bugs like this are not to be expected in a product like this, especially
at the price that it is.
A *major* piece of crap, but what should I expect, MS is run by a
bunch of snot-nosed adolescents that think they know everything. Not to sound harsh, but you pretty much sound like a know-it-all in all
of your posts. Considering the content of said posts I'd say you have a
long way to go before that attitude is anywhere near correct.
I'm hardly a know-it-all, but thanks for the comments. I've been
programming Windows since 3.0 -- I've seen how MS operates, and it is frustrating to
try and eek out a living w/ such shoddy tools and lackluster performance. I'm
a contract programmer, and I don't have the time each day to constantly
fiddle w/ the fragility of the system, it costs me *big time*. 10+ years ago,
Borland gave MS some serious compiler competition (and had a far superior
product), but alas, those days are gone, so back to non-innovative buggy MS business as
usual.
So as a contract programmer you kind of have the option to decide which work
you take. If this is so bad, and to be expected of Microsoft then why not
change
your mo and move to java, linux, borland stuff etc? Or are you neglecting to
say
that even though you feel like this for the MS tools, they are still better
than the
others? Or what gives? Its like saying "I really want to loose weight,
honest *eats
a pound of sugar*" =)
//Andreas
"Julie" <ju***@nospam.com> wrote in message
news:40***************@nospam.com... Try closing the IDE and deleting the .suo file. This sounds like a known
bug
that has been cropping up for quite some time(I seem to recall filing a
bug
report myself), there is hope it will be fixed in whidbey, but I don't
know
if there was any official word on that and considering how hard it is to
reproduce I couldn't test. Though I havn't run into it in about a year it
does happen and it will drive you nuts. It seems to crop up most commonly
with large C# or C++ projects and *may* be related to the size of an
output
assembly. I imagine someone else here knows waht I'm talking about and
remembers more details that I do.
If this is a known problem, where is the patch? Not coming, have to wait
until
whidbey, standard line from Microsoft.
Let's not forget that this is the 13th rev (or so) of the MS compiler
suite.
Bugs like this are not to be expected in a product like this, especially
at the
price that it is.
As I said, its a rather complex one. I've yet to meet anyone who can
reproduce it at will. Sorry but a bug I've heard maybe 6 complaints about in
the last 2 years that would require a considerable amount of time to fix
isn't something that warrents being rushed to in my opinion. Especially when
virtually everyone who has had it managed to get around it by modifying
their project layout slightly. Its annoying but its not a show stopper. At
worst, get nant and build with that.
The new project system in whidbey will hopefully squash it, but I can't tell
you for sure. The bug is strange and transient, and its rather hard to
reproduce even when I have a project that exhibits in in some situations. > A *major* piece of crap, but what should I expect, MS is run by a bunch
> of
> snot-nosed adolescents that think they know everything.
Not to sound harsh, but you pretty much sound like a know-it-all in all
of
your posts. Considering the content of said posts I'd say you have a long
way to go before that attitude is anywhere near correct.
I'm hardly a know-it-all, but thanks for the comments. I've been
programming
Windows since 3.0 -- I've seen how MS operates, and it is frustrating to
try
and eek out a living w/ such shoddy tools and lackluster performance. I'm
a
contract programmer, and I don't have the time each day to constantly
fiddle w/
the fragility of the system, it costs me *big time*. 10+ years ago,
Borland
gave MS some serious compiler competition (and had a far superior
product), but
alas, those days are gone, so back to non-innovative buggy MS business as
usual.
Frankly, I would suggest either finding another profession or another system
to work in\build with. I hear Delphi is nice, sharp develop is decent, and
borland C# builder isn't bad either.
Personally I rarely have problems to the point where I need to come on
newsgroups and be snotty about it. If you want help with something ask for
help, if you want to provide answers, provide correct, precise, and
non-predjudiced answers, but if you want to bitch about things(especially
everything except the C# langauge) there are plenty of newsgroups to suit
your needs, its really rather off focus here. I don't have much sympathy for
people who come here to whine, bitch, pass incorrect information, and ask
for help simultaneously.
I rather resent having to waste time reading these posts. This goes to you,
C# Learner, and anyone else here who is even peripherally focused on
complaining. I bothered to respond to you only because I could provide a
little insight into your problem, but you have to take my annoyance and
disdain along with it. I won't let petty whining stop me from providing any
answers I might be able to give, but I won't always do it silently.
"Andreas Håkansson" <andy.h (at) telia.com> wrote in message
news:eK**************@TK2MSFTNGP10.phx.gbl...
"Julie" <ju***@nospam.com> skrev i meddelandet
news:40***************@nospam.com... "Daniel O'Connell [C# MVP]" wrote:
"Julie" <ju***@nospam.com> wrote in message
news:40***************@nospam.com...
> C# Learner wrote:
>>
>> Julie wrote:
>>
>> > I'll take the language any day. It is their sucky, buggy, deficient >> > IDE that
>> > gets my goat, day after day.
>> >
>> > So far, their IDE can handle "hello world" class projects, but
not much >> > more...
>>
>> The IDE seems pretty solid to me; but I guess it could be a case of
>> different machines, different setups, etc.
>>
>> How about a deal: you take the language and I take the IDE ;-P
>
> Consider yourself lucky. Any commercial-scope project is way
outside the > bounds of the IDE.
>
> I'm currently working on one solution composed of maybe 30-40
projects of > C#,
> managed C++, and native C++, with multiple forms, controls, etc.
>
> It is a battle to get through a day w/o numerous restarts due to the piece > getting hung up on itself. As we speak, the compiler can't build a
> project
> because somewhere else the IDE has a file open (in this case, a debugging > pdb
> file). Closing all files, and even the project/solution doesn't
solve the > problem, the only solution is to restart and rebuild.
>
Try closing the IDE and deleting the .suo file. This sounds like a
known bug that has been cropping up for quite some time(I seem to recall filing
a bug report myself), there is hope it will be fixed in whidbey, but I don't know if there was any official word on that and considering how hard it is
to reproduce I couldn't test. Though I havn't run into it in about a year it does happen and it will drive you nuts. It seems to crop up most commonly with large C# or C++ projects and *may* be related to the size of an output assembly. I imagine someone else here knows waht I'm talking about and
remembers more details that I do.
If this is a known problem, where is the patch? Not coming, have to
wait until whidbey, standard line from Microsoft.
Let's not forget that this is the 13th rev (or so) of the MS compiler suite. Bugs like this are not to be expected in a product like this, especially
at the price that it is.
> A *major* piece of crap, but what should I expect, MS is run by a
bunch of > snot-nosed adolescents that think they know everything.
Not to sound harsh, but you pretty much sound like a know-it-all in
all of your posts. Considering the content of said posts I'd say you have a long way to go before that attitude is anywhere near correct.
I'm hardly a know-it-all, but thanks for the comments. I've been
programming Windows since 3.0 -- I've seen how MS operates, and it is frustrating to
try and eek out a living w/ such shoddy tools and lackluster performance.
I'm a contract programmer, and I don't have the time each day to constantly fiddle w/ the fragility of the system, it costs me *big time*. 10+ years ago,
Borland gave MS some serious compiler competition (and had a far superior
product), but alas, those days are gone, so back to non-innovative buggy MS business
as usual.
So as a contract programmer you kind of have the option to decide which
work you take. If this is so bad, and to be expected of Microsoft then why not
change
your mo and move to java, linux, borland stuff etc? Or are you neglecting
to say
that even though you feel like this for the MS tools, they are still
better than the
others? Or what gives? Its like saying "I really want to loose weight,
honest *eats
a pound of sugar*" =)
//Andreas
Probably because as a contractor they are at the mercy of the hosting
company. It is rare to come in and completely change a company's
environment, even if there are better choices as you mention. Usual mantra
as a contractor is "anything, anywhere, anytime" (that's what I used when I
did body-shop work). Best bet is to keep whatever they have and plug them
for lot's of overtime if it's buggy.
bob
Daniel O'Connell [C# MVP] wrote:
<snip>
If you can't take the heat, get out of the kitchen.
Daniel O'Connell [C# MVP] wrote: Not to sound harsh, but you pretty much sound like a know-it-all in all of
your posts. Considering the content of said posts I'd say you have a long
way to go before that attitude is anywhere near correct.
To be honest, I think that you make yourself out to be a _god_ in /your/
posts.
I remember the first time I ever replied to you in a thread. I think
the thread was on the subject of coding with Notepad when not using an
IDE. I posted a reply to you giving a joke about Notepad.
From your reply to my post, I got the impression that you were
thinking, "Who the hell are you to reply to me?!"
I get a similar impression to many of your posts.
C# Learner <cs****@learner.here> wrote: Not to sound harsh, but you pretty much sound like a know-it-all in all of
your posts. Considering the content of said posts I'd say you have a long
way to go before that attitude is anywhere near correct.
To be honest, I think that you make yourself out to be a _god_ in /your/
posts.
I remember the first time I ever replied to you in a thread. I think
the thread was on the subject of coding with Notepad when not using an
IDE. I posted a reply to you giving a joke about Notepad.
The only thread I can see on groups.google.com where you posted and
there was anything about Notepad, Daniel didn't post at all. Were you
thinking of William Stacey, perhaps?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] wrote: C# Learner <cs****@learner.here> wrote:
Not to sound harsh, but you pretty much sound like a know-it-all in all of
your posts. Considering the content of said posts I'd say you have a long
way to go before that attitude is anywhere near correct.
To be honest, I think that you make yourself out to be a _god_ in /your/
posts.
I remember the first time I ever replied to you in a thread. I think
the thread was on the subject of coding with Notepad when not using an
IDE. I posted a reply to you giving a joke about Notepad.
The only thread I can see on groups.google.com where you posted and
there was anything about Notepad, Daniel didn't post at all. Were you
thinking of William Stacey, perhaps?
You're right -- I made a mistake here, confusing Daniel with William.
My stated general feeling about Daniel's posts still remains, though.
"C# Learner" <cs****@learner.here> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl... Daniel O'Connell [C# MVP] wrote:
Not to sound harsh, but you pretty much sound like a know-it-all in all
of your posts. Considering the content of said posts I'd say you have a
long way to go before that attitude is anywhere near correct.
To be honest, I think that you make yourself out to be a _god_ in /your/
posts.
Now now, I'm a jerk, not a god, ;).
I remember the first time I ever replied to you in a thread. I think the
thread was on the subject of coding with Notepad when not using an IDE. I
posted a reply to you giving a joke about Notepad.
From your reply to my post, I got the impression that you were thinking,
"Who the hell are you to reply to me?!"
I get a similar impression to many of your posts.
Your first reply to me, as best I can tell, was on the subject of naming
conventions. I argued that forcing all developers to use one single
convention was impossible while you felt it should be done. I don't see
where I came off as egotistical there however. Indeed I can only find 3
references to notepad in any of my posts, you were involved with none.
Now, maybe I am arrogant. It really doesn't matter to me much. I'm here to
help when I can, learn when I can't, and participate in the rare interesting
discussion where there isn't an answer. I don't think I'm particularly
egotistical, but if you feel my posts are, then you are free to ignore them.
Also, in general I prefer responses to silence. An extra post doesn't take
up much time to read, as long as its somewhat on subject. Generally the only
time I'll lambaste a reply is when its purpose is entirely to 1) enrage, 2)
bitch, or 3) tell me I'm wrong because the person doesn't want my answer to
be right. (I will often reply sharply to someone who is intentionally
spreading mis-information, either by willful ignorance or by malicious
intent, but that isn't strictly applied to replies to my posts).
I think you will find in this newsgroup, people who are very passionate
about the technology they work in and down right top-notch. It really is a
no bullshit approach. If you are wrong, expect to get chewed thoroughly.
There seldom will be a nice way to spin it. It may not be politically
correct but I believe if you leave your feelings at the door, you can
definitely learn in here.
At least you will learn to post technically accurate stuff or research
issues thoroughly before you post. I am very guilty of jumping technically
inaccurate posters (something i learned in here btw). And I've been jumped
more times than i care to remember. It's rarely personal. It's tough love.
You grow to be technically correct as a result. And that makes you a better
professional.
--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here... http://tinyurl.com/27cok
"C# Learner" <cs****@learner.here> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl... Daniel O'Connell [C# MVP] wrote:
Not to sound harsh, but you pretty much sound like a know-it-all in all
of your posts. Considering the content of said posts I'd say you have a
long way to go before that attitude is anywhere near correct.
To be honest, I think that you make yourself out to be a _god_ in /your/
posts.
I remember the first time I ever replied to you in a thread. I think
the thread was on the subject of coding with Notepad when not using an
IDE. I posted a reply to you giving a joke about Notepad.
From your reply to my post, I got the impression that you were
thinking, "Who the hell are you to reply to me?!"
I get a similar impression to many of your posts.
Frans & Jon,
Perhaps I should have clarified... of course I prefer people with .Net
experience. I was referring to a previous posting talking about VB versus
C/C++ programmers (I left out Java programmers, since they may have a clue
about OOP, but usually not about the Windows architecture).
So, the comparison I was making was in pre-.Net, windows directed languages
only. While there is no message pump for threads, it is important to
understand how threading works on the GUI components and how Invoke,
BeginInvoke, and EndInvoke actually do work with the GUI's message
architecture in these situations.
Continuing on that concept, there are often times when knowing the
underlying architecture can make a programmers ability to program .Net
programs a lot better.
Chris A.R.
"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> wrote in message
news:Xn********************************@207.46.248 .16... "Chris A. R." <so*****@hotmail.com> wrote in
news:u9**************@TK2MSFTNGP10.phx.gbl:
It's hard to find anyone that knows how to write Threading code without
wrapping themselves in knots. Given that, I find the C/C++ programmers
are much more likely to have a clue on how to write working code in a
Threaded environment. I also find that most VB programmers don't
understand the windows messaging architecture, whereas most C/C++
programmers do understand.
Of course, there are dud C/C++ programmers, but understanding the
foundation of the windows architecture is important for complex
programs. So, as lead engineer and architect at the company I work for,
pointy haired boss and all, I prefer people with C/C++ experience.
Odd. I'd prefer people with .NET experience. You see, It's better
to know how .NET works, than to know how win32 works, as .NET does a lot
for you and sometimes differently than in win32 (i.e.: there is no
messageing architecture to post messages between threads, threads don't
have their own messagepump etc.
FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP
Daniel O'Connell [C# MVP] wrote: "C# Learner" <cs****@learner.here> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl...
Daniel O'Connell [C# MVP] wrote:
Not to sound harsh, but you pretty much sound like a know-it-all in all
of your posts. Considering the content of said posts I'd say you have a
long way to go before that attitude is anywhere near correct.
To be honest, I think that you make yourself out to be a _god_ in /your/
posts.
Now now, I'm a jerk, not a god, ;).
I remember the first time I ever replied to you in a thread. I think the
thread was on the subject of coding with Notepad when not using an IDE. I
posted a reply to you giving a joke about Notepad.
From your reply to my post, I got the impression that you were thinking,
"Who the hell are you to reply to me?!"
I get a similar impression to many of your posts.
Your first reply to me, as best I can tell, was on the subject of naming
conventions. I argued that forcing all developers to use one single
convention was impossible while you felt it should be done. I don't see
where I came off as egotistical there however. Indeed I can only find 3
references to notepad in any of my posts, you were involved with none.
I was wrong, and confused you with someone else; sorry.
I think you're right that the first thread where we communicated was the
thread on naming conventions. In it, you were not unfriendly at all.
Now, maybe I am arrogant. It really doesn't matter to me much. I'm here to
help when I can, learn when I can't, and participate in the rare interesting
discussion where there isn't an answer. I don't think I'm particularly
egotistical, but if you feel my posts are, then you are free to ignore them.
Also, in general I prefer responses to silence. An extra post doesn't take
up much time to read, as long as its somewhat on subject. Generally the only
time I'll lambaste a reply is when its purpose is entirely to 1) enrage, 2)
bitch, or 3) tell me I'm wrong because the person doesn't want my answer to
be right. (I will often reply sharply to someone who is intentionally
spreading mis-information, either by willful ignorance or by malicious
intent, but that isn't strictly applied to replies to my posts).
I am pleasantly surprised that your reply (quoted here) isn't a flame.
"C# Learner" <cs****@learner.here> wrote in message
news:O8**************@TK2MSFTNGP12.phx.gbl... Daniel O'Connell [C# MVP] wrote:
"C# Learner" <cs****@learner.here> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl...
Daniel O'Connell [C# MVP] wrote:
Not to sound harsh, but you pretty much sound like a know-it-all in all
of your posts. Considering the content of said posts I'd say you have a
long way to go before that attitude is anywhere near correct.
To be honest, I think that you make yourself out to be a _god_ in /your/
posts.
Now now, I'm a jerk, not a god, ;).
I remember the first time I ever replied to you in a thread. I think the
thread was on the subject of coding with Notepad when not using an IDE.
I posted a reply to you giving a joke about Notepad.
From your reply to my post, I got the impression that you were thinking,
"Who the hell are you to reply to me?!"
I get a similar impression to many of your posts.
Your first reply to me, as best I can tell, was on the subject of naming
conventions. I argued that forcing all developers to use one single
convention was impossible while you felt it should be done. I don't see
where I came off as egotistical there however. Indeed I can only find 3
references to notepad in any of my posts, you were involved with none.
I was wrong, and confused you with someone else; sorry.
I think you're right that the first thread where we communicated was the
thread on naming conventions. In it, you were not unfriendly at all.
Now, maybe I am arrogant. It really doesn't matter to me much. I'm here
to help when I can, learn when I can't, and participate in the rare
interesting discussion where there isn't an answer. I don't think I'm
particularly egotistical, but if you feel my posts are, then you are free
to ignore them.
Also, in general I prefer responses to silence. An extra post doesn't
take up much time to read, as long as its somewhat on subject. Generally
the only time I'll lambaste a reply is when its purpose is entirely to 1)
enrage, 2) bitch, or 3) tell me I'm wrong because the person doesn't want
my answer to be right. (I will often reply sharply to someone who is
intentionally spreading mis-information, either by willful ignorance or
by malicious intent, but that isn't strictly applied to replies to my
posts).
I am pleasantly surprised that your reply (quoted here) isn't a flame.
There is no reason to flame you. However I don't think you have much
standing to be rude yourself.
Daniel O'Connell [C# MVP] wrote:
[...] I am pleasantly surprised that your reply (quoted here) isn't a flame.
There is no reason to flame you. However I don't think you have much
standing to be rude yourself.
I wasn't trying to be rude; I was just letting you know that I was
pleasantly surprised in not getting flamed. threads don't
have their own messagepump etc.
actually, .Net threads don't have access to the message queue - i.e. no
inherent GetMessage/DispatchMessage support from which to build a pump.
roy fine
C# Learner wrote: Daniel O'Connell [C# MVP] wrote:
[...]
I am pleasantly surprised that your reply (quoted here) isn't a flame.
There is no reason to flame you. However I don't think you have much
standing to be rude yourself.
I wasn't trying to be rude; I was just letting you know that I was
pleasantly surprised in not getting flamed.
Or did you mean my other two posts about god and the kitchen? Just to
make sure...
<snip>
Odd. I'd prefer people with .NET experience. You see, It's better
to know how .NET works, than to know how win32 works, as .NET does a lot
for you and sometimes differently than in win32 (i.e.: there is no
messageing architecture to post messages between threads, threads don't
have their own messagepump etc.
I have to disagree. I find it important to understand not only the tool that
is in your hand, but where it came from and the design choices that were
made in building it (i.e. the limitations and why they exist).
It may be that you can do 95% or more of your work without needing to know
what lies below the surface, but the small percentage that is left can be
the difference between relying on voodoo programming and being able to
design a good solution or fix a difficult problem. You can be a good .net
programmer without a win32 background, but it's a lot tougher then for
someone with a good win32 background.
Programmers certainly need experience in .net, but if that's all they have
there will be some problems that are just plain mysterious (and perhaps
unsolvable) to them. Part of that is because the .net platform is still
immature and you can't go very far before it p/invokes back to a win32 API
or COM object. I think you'll find that a number of the
limitations/restrictions of the .net platform and the BCL are directly
derived (even when it's not obvious) from the platform.
As the platform matures more services will be ported to .NET so this will be
less of a problem, but that could be a long ways in the future.
Dave
"Chris A. R." <so*****@hotmail.com> wrote in
news:uA**************@TK2MSFTNGP10.phx.gbl: So, the comparison I was making was in pre-.Net, windows directed
languages only. While there is no message pump for threads, it is
important to understand how threading works on the GUI components and
how Invoke, BeginInvoke, and EndInvoke actually do work with the GUI's
message architecture in these situations.
I disagree. The reason for that is that .NET is a layer abstracting
away the win32 architecture. It provides a new API. If a developer reads
and understands the .NET methods like BeginInvoke() and friends (there was
a nice discussion about these on the DOT-NET developmentor list recently),
it *should* be fine. After all, those are the routines a developer works
with. Even if the developer understands that below the surface WM_*
messages are sent to messagepumps, it doesn't matter, as the developer
can't do a thing about it.
Continuing on that concept, there are often times when knowing the
underlying architecture can make a programmers ability to program .Net
programs a lot better.
This is partly true for winforms control usage, for the rest, I
don't think it is that important. Partly true as in: why do I have to do
an Application.DoEvents() here and why will my program lock up when I do
that right before a TreeView.EndUpdate() ? For the rest, it's out of your
hands anyway, the information that disabling a textbox control will call
Win32's SendMessage() below the surface is great, but it only helps you
understand why some things work differently than expected, it can't help
you fix it.
Frans
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: C# Learner |
last post by:
I've had enough of C#. I've had enough of using parentheses for every
'if' statement. I've had enough of having to mix assignment of return
value of methods with flow control, making writing code...
|
by: Simon |
last post by:
I've had enough of C# Learner. I've had enough of his complaining
about using parentheses for every 'if' statement. I've had enough of
his complaining about having to mix assignment of return...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
