473,854 Members | 1,476 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

I've Had Enough

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
123 4023
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
Nov 16 '05 #101

"Julie" <ju***@nospam.c om> 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(especial ly
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.
Nov 16 '05 #102
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...
Nov 16 '05 #103

"Andreas Håkansson" <andy.h (at) telia.com> wrote in message
news:eK******** ******@TK2MSFTN GP10.phx.gbl...

"Julie" <ju***@nospam.c om> skrev i meddelandet
news:40******** *******@nospam. com...
"Daniel O'Connell [C# MVP]" wrote:

"Julie" <ju***@nospam.c om> 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
Nov 16 '05 #104

<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
Nov 16 '05 #105
"Chris A. R." <so*****@hotmai l.com> wrote in
news:uA******** ******@TK2MSFTN GP10.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.DoE vents() here and why will my program lock up when I do
that right before a TreeView.EndUpd ate() ? 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
Nov 16 '05 #106
"Dave" <no************ ****@wi.rr.com> wrote in
news:uO******** ******@TK2MSFTN GP11.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+ / ServicedCompone nt.

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
Nov 16 '05 #107
Daniel O'Connell [C# MVP] wrote:

<snip>

If you can't take the heat, get out of the kitchen.
Nov 16 '05 #108
> >
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+ / ServicedCompone nt.


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).

Nov 16 '05 #109
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.
Nov 16 '05 #110

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

23
264
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 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...
101
4017
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 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...
26
1125
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 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...
98
2430
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 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...
0
9752
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
11031
Oralloy
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, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10685
jinu1996
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 tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10763
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 Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10371
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
7082
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 then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5750
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 last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5942
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
3
3188
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.