Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

.Net Oddities

By e8johan in Technology
Sat Jul 12, 2003 at 03:40:27 PM EST
Tags: Software (all tags)

.Net has been hyped by Microsoft. From the propaganda it seems as if .Net is a bit like the solution to all problems. After a company policy decision I was forced into the .Net world. This article describes what I have found - bad design, strange solutions and bad documentation.


This article is divided into a number of sections dealing with specific areas. This article does not claim to point out all problems with .Net, but rather to show a few examples.

This article is based on a series of diary entries.

My Expectations of .Net

As .Net has been hyped by Microsoft for a while now I was expecting something revolutionary. I have developed software using Qt for a while and feel fairly experienced, so I base many on my expectations on what Qt does better than win32/MFC.

As the .Net applications run in a virtual machine and the languages support garbage collection and references (instead of pointers1). I expected these languages to be on a higher level (further away from the machine code) than for example C++.

During my previous experiences as a developer for the Windows platform I have been working with C++ (MFC/win32), C (win32) and Visual Basic (version 1, 3, 4 and 6). The only thing that I found somewhat bearable was C++ combined with win32. This was much due to the fact that win32 is well documented, even though it is quite heavy to code for.

It should be noted that I run Microsoft Visual Studio .Net Enterprise Architect 2002. I base my observations on that version, even though I sometimes refer to the on-line MSDN version available at the time of writing.

The Creation of Objects

When creating an instance of a class my first reflex is to look at the documentation for the constructors for the class in question. This sort of division is used by Qt, where the constructor of the different classes handle any communication with other objects (such as parent widgets or paint devices). In .Net this is not always the case.

When drawing something in a widget, or a control as they are referred to in .Net, one needs a graphics context to draw through. In Qt this is embodied though the QPainter class, in .Net, the Graphics class is used.

The first scenario: we have received a repaint order thus we are in the PaintEvent method in the Qt version and in the OnPaint method in the .Net method. The this-pointer points at a QWidget/Control derivate.

The .Net part is simple. We get a PaintEventArgs structure containing a Graphics instance. Just use it and it all works.

In Qt, we know that we want to create a QPainter, thus we look for a good constructor. In the detailed description, the first thing that we run into is an example of how to respond to a paint event. So we put it as follows:

  QPainter p( this );

What we do is that we create a QPainter based on this, i.e. a QWidget derivate and thus a QPaintDevice (look here for the inheritance details). Both solutions are quick and easy, so lets go on!

The second scenario: we are in the same situation as the first scenario, but we are not responding to an event. We do not wish to invalidate a part of the control to trigger a repaint event for some reason (read: performance). But we still need a graphics context.

The Qt version is the same. We have a this-pointer from which we can create a QPainter. The we just draw as we did in the first scenario.

The .Net solution is a little bit more tricky. We want to create a Graphics instance from a Control. It wasn't nice to find out that the Graphics class had no (documented) public constructors. Now, it is a good thing that I have fiddled around with win32 for a while (one has to pay one's bread). The code for creating a Graphics object looks like this:

  Graphics g = CreateGraphics();

Or, the verbose version (that Visual Studio seems to like):

  Graphics g = this.CreateGraphics();

How did I find this? I do not remember as the formerly great MSDN has degraded into a disorganized source of shallow knowledge. No more great code examples, nor any in-depth descriptions. This is one of many examples where the win32 structure blends through the thin .Net layer.

Collections and Arrays

Lets start this section by citing the good Dr. GUI; Microsoft's GUI expert who answers the users' questions.

One very important difference between Visual Basic .NET and C# is in the number of array elements allocated when you ask for a fixed number of elements.

For instance, if you say int [] a = new int[5]; in C#, you get five elements, a[0] through a[4].

In Visual Basic .NET, if you say Dim a() as Integer = New Integer(5), you get SIX elements, a[0] through a[5].

In other words, Visual Basic .NET adds one to the size of each dimension automatically and silently. Visual Basic does this for legacy reasons--again, to make porting old Visual Basic programs to Visual Basic .NET a little easier.


Beware! Especially if you mix languages! And if you're a Visual Basic .NET programmer, be aware of this when you pass arrays to .NET Framework methods!

Another short question on the subject is: why do Collections have a Count while Arrays have a Length? This does not matter much to the language implementer, but it adds unnecessary confusion for the end developer.

Now to a more specific problem. I needed a type-safe collection. As C# fails to support generics and/or templates I had to go look for information elsewhere. I started by searching MSDN for "typesafe collection". All that I found was painfully useless.

I'll just follow a short side-track concerning generics here. When designing a completely new language, why wasn't templates introduced at once? They appearantly believe that it is a Good Thing as it is a coming feature. The reason for doing this is:

Microsoft is announcing these four features to demonstrate rapid innovation in the C# language and to solicit developer feedback in the evolution of the language. We hope that customers will provide feedback on these features to the C# language designers at the sharp@microsoft.com email alias.

Rapid innovation of the C# language? I want my language to be as static as possible, to avoid incompatibilities and yet another versioning factor to pay attention to. All this proves is that they released the language too early.

Ok, back to the type-safe collection. Since MSDN didn't offer anything useful I had to change my tactics. By simply browsing the namespaces available in .Net I found System.Collections. Seemed promising. After having looked around for a short while I found this:

Provides the abstract (MustInherit in Visual Basic) base class for a strongly typed collection.

The described class is the CollectionBase, so I went on and checked it out. I quote the remarks here:

Remarks A CollectionBase instance is always modifiable. See ReadOnlyCollectionBase for a read-only version of this class.

Notes to Implementers: This base class is provided to make it easier for implementers to create a strongly typed custom collection. Implementers should extend this base class instead of creating their own.

Not much information and the members' list didn't make me happier. Still, no time to give up, there seems to be an internal list called List, so lets just implement Add, Remove, Insert, IndexOf and operator[] (called public ClassName this [ int i ] in C#, odd that other operators still use the operator+ notation). This made things work. p>Now, I realized that it must be time to check the on-line MSDN version. The reason to this was to provide links for this text. To my surprise (in a positive manner), the MSDN entry for CollectionBase now contains an example. This appeared to be a piece of badly commented, non-hyperlinked, code. Wouldn't it be nice if the methods and classes used in the example were linked to, from the code (Qt does it, so it can be done).

After having looked though the example I ended up with another question. Why implement both a typed version of Add and Insert and then an OnInsert that checks for the type? To me, it seems as if the typed versions of Add and Insert aught to catch any misstypes, so OnInsert wouldn't be needed. Perhaps I'm stupid, but there is no explaining comments or notes.

Strange Design

I need a listbox with custom items such as a colour or perhaps an image. No problems, this part is even quite well documented. Just set the DrawMode to OwnerDrawVariable and handle the MeasureItem and DrawItem events.

My problem is that I want to be able to put 10-15 different items into the list box. Each of them with their own scaling and drawing logic. Now, as the drawing and scaling is located in the ListBox, this leaves me with two options: 1) put a huge switch-statement in the event handlers or 2) define an interface with the methods Draw and Measure and call these for each event.

How come that the Microsoft guys didn't do it this way from the start. I feel that a ListBoxItem class and a typesafe Items collection in the ListBox would be a nicer solution. To me, it seems as if the current list box relies on the ToString() method in the default drawing method. This means that as a long as I put strings into it everything is fine, but otherwise I do not know what will happen. It will probably list type names.

To me, this is yet another example of win32 blending though the thin .Net layer.

Focus Stupidity

I want a listbox which one can edit. The user simply marks the item that it wants to alter and it appears in a textbox below. When editing the text the listbox reflects the changes live. This, I thought in my naive little world, will be easy. But no.

My first code looks like this:

  private void tbDrawingNo_TextChanged(object sender, System.EventArgs e)
    if( tbDrawingNo.Enabled )
      lbDrawingNo.Items[ lbDrawingNo.SelectedIndex ] = tbDrawingNo.Text;

I check for the Enabled-property before I do any alterations. This way I can just disable the textbox and alter it freely from the code without the changes being reflected back into the listbox. When I alter the text this means that the focus moves to the listbox again.

The next attempt is also quite natural. Since the Select() method "Activates the control" according to the documentation, I went for it.

  private void tbDrawingNo_TextChanged(object sender, System.EventArgs e)
    if( tbDrawingNo.Enabled )
      lbDrawingNo.Items[ lbDrawingNo.SelectedIndex ] = tbDrawingNo.Text;

This means that all the text in the textbox gets selected so the second character overwrites all the text. Stupid! I also tried to replace the Select() method with a Focus() call, but the same thing happened. More stupidity!

After some fiddling around I came up with this version that seems to work:

  private void tbDrawingNo_TextChanged(object sender, System.EventArgs e)
    if( tbDrawingNo.Enabled )
      int selStart = tbDrawingNo.SelectionStart;
      int selLength = tbDrawingNo.SelectionLength;

      lbDrawingNo.Items[ lbDrawingNo.SelectedIndex ] = tbDrawingNo.Text;

      tbDrawingNo.SelectionLength = selLength;
      tbDrawingNo.SelectionStart = selStart;

Why does the focus move? Why isn't this "feature" documented somewhere? I'm sorry, but I cannot understand why this is.

Loose Coupling

.Net has signals and slots, or easy to use, type-safe(ish) callbacks built in. Whatever you call them, they provide the same functionality. Making this a part of the system is, in my opinion, a Good Thing.

How are they used they? You may ask. Not very will is my answer2. I will explain here.

All events and signals (which are treated as custom events in .Net) generated in .Net (I'm talking about Windows.Forms, but ASP.Net is practically the same) pass a sender object reference and an events parameter that is either EventArgs or one of its descendants.

For performance Qt treats events as protected virtual functions and signals as signals. This difference in performance is not an issue in .Net (since all is running in a virtual machine which is fairly slow by definition). Ergo (always wanted to use that word since I saw Matrix Reloaded... sorry) treating events and signals differently is The Right Thing in Qt, but not in .Net.

Qt signals pass their parameters as a part of the signaling function. If .Net was designed as Qt, passing parameters with the signal, this would mean that all slots would have to receive all parameters. This is not always desirable as one wants to be able to bind different signals to the same slots. Qt solves this by passing the parameters that fit, so if slot( int ) is connected to signal( int, string ), the slot would only recieve the integer. This is probably one of the limiting factors, but not the only one.

For example, take Qt's classical example, a trackbar (a slider in Qt) feeding its value into a display widget. Let us say that we have a LCDDisplay widget in .Net. It has a property public int Value. Now if we want to connect a slider's Value to the LCDDisplay's we'll have to listen to the ValueChanged event. This event do not send the actual value that the trackbar has been set to. We'll end up having to write a function (an event handler) transfering the value from the trackbar to the LCDDisplay. Even worse, this function must know what a trackbar is in order to be able to extract the value.

Now, imagine that the ValueChanged event would look like this: ValueChanged( int ). This would mean that the glue code handing the event could forget about the trackbar, it gets the value that it needs and it puts it in the LCDDisplay. We could easily use any other signal emitting an integer and connect it to the ValueChanged event handler.

There is only one hurdle left. The Value is a property. In .Net you can either do a public variable (public int Value;) or a public variable with code triggered at get or set (public int Value { get { ... } set { ... } } ). To handle the latter, a local copy of the value has to be kept (private int m_value; public int Value { get { return m_value; } set { m_value = value; } }). This amounts to the same code that is needed in the Qt case where you would have a void setValue( int ); and int value( void ); pair. The advantage in the Qt case is that a ValueChanged( int ) event could be connected directly to the void setValue( int ) method. Loose coupling.

Loose coupling means that the receiver and sender does not have to know about each other. As long as the signal and slot, event and handler, foo and bar fits together they can be connected. This could have been done fairly well in .Net, but Microsoft didn't even though there are examples of this available.


.Net Windows.Forms is really just a thin layer over win32. Many strange things are still there and I would dare to say that Microsoft has not spent much time on refactoring and actually look through their design.

The previously great documentation that used to accompany Microsoft's development tools has been neglected this time around. Now there is too much with too little information. Most of the information is shallow, lost are the great examples and in-depth descriptions for every method.

I would go so far as to call .Net a marketing trick. It does not bring anything new to the programmers. The only thing that I can like is that Visual Basic fails to be backwards compatible, so perhaps some developers try a real programming language.

A side note is that the on-line version of MSDN can be real fun reading. Look for documents describing the differences between .Net and the predecessors and you will find lists of earlier design mistakes by Microsoft.

1 .Net also supports pointers, but this is not promoted very hard by Microsoft.

2 I realized the power of loose coupling after a discussion with Philippe Fremy.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o inheritanc e details
o coming feature
o MSDN entry
o Also by e8johan

Display: Sort:
.Net Oddities | 127 comments (91 topical, 36 editorial, 1 hidden)
Great Article (3.66 / 6) (#2)
by bugmaster on Fri Jul 11, 2003 at 03:26:36 AM EST

Great article -- I will vote it +1FP when I can. Out of curiosity, what do you think about thread safety in .Net ? Somehow I find Java's synchronized keyword much easier to use, but this may just be a force of habit.
Java's threads suck (1.00 / 4) (#23)
by jpmorgan on Fri Jul 11, 2003 at 09:11:21 AM EST

Java's thread safety is bad. Synchronized is horribly slow, and its monitors are an abomination.

[ Parent ]
Urban performance legend #1 (5.00 / 6) (#29)
by komadori on Fri Jul 11, 2003 at 10:47:39 AM EST


"When we are victorious on a world scale I think we shall use gold for the purpose of building public lavatories in the streets of some of the largest cities of the world." Vladimir Illich Lenin

[ Parent ]
C# use the 'lock' keyword (none / 0) (#96)
by jhannes on Sun Jul 13, 2003 at 12:02:30 PM EST

For creating a mutual exclusion synchronized on an object, C# uses the 'lock' statment. It is used identically with Java's 'synchronized', except it cannot be used as a method modifier, only on statement-blocks. See http://msdn.microsoft.com/library/en-us/csref/html/vclrflockstatement.asp.

[ Parent ]
You can also do (none / 0) (#109)
by daragh on Mon Jul 14, 2003 at 10:34:18 AM EST

public void MyMethod

to make a method synchronised, in a more Java-like manner.

No work.
[ Parent ]

Suffering the trauma, even as we speak. (4.66 / 6) (#5)
by Akshay on Fri Jul 11, 2003 at 03:49:37 AM EST

Just spent half a day trying to figure out what the calls Web.Global.CfgKeyFirstDayOfWeek and Web.Global.CfgKeyUserAcctSource return.

The answer, dear reader, is too traumatic to post here.

(That said, the company has made it policy to develop only in .Net, and the pay's good in these hard times, so who am I to complain.)

a (none / 0) (#6)
by e8johan on Fri Jul 11, 2003 at 04:00:11 AM EST

That said, the company has made it policy to develop only in .Net, and the pay's good in these hard times, so who am I to complain.

Nice to hear that I am not alone in this situation. But I do complain...

[ Parent ]

Get a new job. (3.00 / 1) (#9)
by mr strange on Fri Jul 11, 2003 at 04:33:50 AM EST

It's not that hard. There's nothing worse than tolerating a bad situation because you can't be bothered to leave.

Alternatively, ask for a pay rise and make it clear that you're charging more because your CV is being diluted by unmarketable .Net skills. Get your colleagues to do the same. Companies' technology decisions are driven by fashion as much as by the merits of the technology. You need to make the deficiencies of .Net an issue at your company.

intrigued by your idea that fascism is feminine - livus
[ Parent ]

Precisely. (5.00 / 1) (#12)
by Akshay on Fri Jul 11, 2003 at 05:18:31 AM EST

Will be leaving the company in a week or 10 days, by the time the school starts. Best to shut up, complete the project, get the reco letter/cash, party for 7 days, and then hit the books.

World domination was never simpler. Too bad I'll be spending the weekend at the cubicle.

Then again, there's K5 to wind down and get distracted, so to repeat, who am I to complain? :-D

[ Parent ]

Searching MSDN. (5.00 / 6) (#10)
by Jetifi on Fri Jul 11, 2003 at 05:06:22 AM EST

C4L, who works at MS, says that it's better to use Google than MSDN's built-in search tool. Dunno if that helps you or not.

Tried (3.66 / 3) (#11)
by e8johan on Fri Jul 11, 2003 at 05:10:06 AM EST

Yes, I've tried it. But it doesn't mean that the contents of MSDN is practically useless. They have some good articles, but one has to be lucky to find one concerning the subject one is interested in.

[ Parent ]
good job (2.75 / 8) (#13)
by circletimessquare on Fri Jul 11, 2003 at 05:23:41 AM EST

Open k5comment For Output As #1
Do Until story = frontpage
   Print #1, "great story! +1 fp"
   story = story + 1

The tigers of wrath are wiser than the horses of instruction.

/me claws eyes out [n/t] (none / 0) (#53)
by EMHMark3 on Fri Jul 11, 2003 at 04:27:02 PM EST

T H E   M A C H I N E   S T O P S
[ Parent ]

Modernized version (VB6) (none / 0) (#102)
by vadim on Sun Jul 13, 2003 at 07:49:34 PM EST

With Comment
    .Subject = "great story! +1 fp [n/t]"

    Do Until Story.PostedOnFrontPage
End With
<@chani> I *cannot* remember names. but I did memorize 214 digits of pi once.
[ Parent ]

Nitpicks (4.77 / 18) (#18)
by CaptainSuperBoy on Fri Jul 11, 2003 at 07:44:41 AM EST

Most of your criticisms can be described as nitpicks by an experienced programmer who expects his languages to behave a certain way. Please remember, that is not the main audience for .NET. If it had been designed for people who want a clone of C++ and Qt, it would be unusable by people who want a rapid development platform.

jimmysquid.com - I take pictures.
Qt - RAD - Win32 (4.00 / 2) (#19)
by e8johan on Fri Jul 11, 2003 at 07:48:45 AM EST

Qt is, in my mind, a RAD for real applications.

If you want a rapid development platform, isn't good documentation, orthoginality, etc. the Right Thing?

As for the bad OO that I point out (e.g. the ListBox), why isn't well designed code an issue when dealing with RADs? You'll get along fine with the MS solution, but as soon as you try to do something more complex than a simple database frontend you'll run into the wall.

[ Parent ]

Database frontend (5.00 / 2) (#20)
by CaptainSuperBoy on Fri Jul 11, 2003 at 08:00:30 AM EST

The fact is, the database frontend crew is the intended audience for .NET. That's not to say that is all .NET is good for, or that you can't write good code in .NET. You seem to be doing a few very specific things in your client application that you are expecting the language to support in a certain way - and this has never really been possible on MS platforms. With Win32, you'd end up writing a lot of it yourself.

Sorry, I don't have time to respond more thoroughly. I enjoyed the article but I respectfully disagree.

jimmysquid.com - I take pictures.
[ Parent ]

Cocoa is RAD for real Apps (nt) (none / 0) (#35)
by jdrake on Fri Jul 11, 2003 at 11:25:53 AM EST

- If a tree falls in the forest, and nobody is around, is there any sound?
- If the universe is created, and nobody is around, is there any bang?

[ Parent ]
what the hell is .NET? (1.16 / 12) (#25)
by rmg on Fri Jul 11, 2003 at 09:52:47 AM EST

look, i'm all for trying new things, but i looked around for free implementations of this stuff, and let me tell you, i did not like what i saw...

a little research shows that this is some new scheme by Micorsoft to take over the internet. now if Micorsoft was the rightful inventor of the internet, like valeko, i might think that's alright, but as it stnads.... well. maybe if CERN introduced some new .EDU platform i'd be more supportive.

anyway, this gets a "-1 Micorsoft" from me.

_____ intellectual tiddlywinks

Agreed (2.00 / 1) (#33)
by b1t r0t on Fri Jul 11, 2003 at 11:07:42 AM EST

This Mac OS X user (me) could care less about .NET except to see it go down in flames.

Anyhow, it gets a "-1 Use The Edit Queue" from me. It's chock-full of spelling and grammar errors, and it should have been submitted as an Op-Ed, too.

-- Indymedia: the fanfiction.net of journalism.
[ Parent ]

Is St. Nads (2.50 / 2) (#59)
by TRASG0 on Fri Jul 11, 2003 at 06:33:32 PM EST

the patron saint of hair removal or of sweatty genitals?
sorry no sig now
[ Parent ]
I'm a linux zealot (3.58 / 17) (#27)
by phred on Fri Jul 11, 2003 at 10:15:58 AM EST

I go home, boot up my home network, all of them running lovely, finely crafted, well tuned installations of 100 percent Debian. I invite my friends over, show them how I live free from the evils of Microsoft, demonstrate no less than 4 standards compliant WWW browsers (as well as a few text based browsers to boot). We talk at length about what the future will bring, where all information will be free, society will be caring, and evil will be forever banished from the earth. We say our goodbyes and I am once again satisfied that I'm spreading the word of freedom.

I then lock my doors, open a beer, reboot into windows 98 second edition, and fuck off on mirc the rest of the night, get some sleep, and repeat the cycle.

BTW, great article, +1.

Huh? (3.75 / 4) (#30)
by ghjm on Fri Jul 11, 2003 at 10:52:03 AM EST

I can see rebooting into Win98 for, say, EverQuest - but mirc? Why, when there are perfectly good (actually better) irc clients for Linux?


[ Parent ]

of course its a subjective thing (5.00 / 1) (#31)
by phred on Fri Jul 11, 2003 at 11:02:33 AM EST

I haven't seen one I like as much as mirc.

Bitchx is ok, epic isn't too bad. Kirc is tolerable, sirc is fun to hack on, but mirc is my personal favorite. Any other linux compatible clients out there I should try?

[ Parent ]

ksirc, kopete, konsole-w-multiple-bitch-X's :)-nt- (5.00 / 1) (#34)
by lemming prophet on Fri Jul 11, 2003 at 11:22:50 AM EST

Follow me.
[ Parent ]
xchat (5.00 / 2) (#37)
by 23 on Fri Jul 11, 2003 at 11:33:40 AM EST

Try xchat. I'm not often on IRC but if my memory serves me right it is similar to mirc.

[ Parent ]
Wine, m'boy (5.00 / 1) (#41)
by Xoder on Fri Jul 11, 2003 at 12:16:48 PM EST

Also, mIRC runs in Wine, if you really feel you need it. I hear from a friend that it runs even better in WineX, aside from a few strange quirks.

Lately I've been hearing that god's on our side But rumor has it, there's one on their side too So what I'd like to know is, when it comes down to it, can my god kick their god's ass or what?
[ Parent ]
Irssi. (5.00 / 1) (#92)
by EiZei on Sun Jul 13, 2003 at 03:14:02 AM EST

I used mIRC for 2 years and after trying irssi I havent gone back.

[ Parent ]
Try xchat (5.00 / 1) (#117)
by salsaman on Mon Jul 14, 2003 at 11:36:55 PM EST


[ Parent ]
screened irssi => run once, attach anywhere(nt) (5.00 / 1) (#86)
by NeXTer on Sat Jul 12, 2003 at 05:50:44 PM EST

[ Parent ]
Who zero-rated this comment? (none / 0) (#107)
by ghjm on Mon Jul 14, 2003 at 09:26:23 AM EST

And why?


[ Parent ]

Sad (5.00 / 1) (#90)
by Joe9999 on Sat Jul 12, 2003 at 09:21:07 PM EST

The only thing sadder than a Linux zealot is an anti-linux zealot. The former places way too much importance on what operating system he's using, and the latter thinks it's even more important than the original zealot did.

[ Parent ]
why is it sad to be a linux zealot? (none / 0) (#106)
by phred on Mon Jul 14, 2003 at 09:05:00 AM EST

Why does this sadden you? Are you one of those M$ astroturfers I read about?

[ Parent ]
Zealots are sad period... (none / 0) (#126)
by anthonyr on Sat Sep 06, 2003 at 04:04:59 PM EST

Zealots tend to advocate their object of worship even when something else is better suited.

If I ask a Linux zealot what I should use for a system that has to be secure, they're more likely to say Linux when VMS or OpenBSD is probably a better choice. That is sad. If I ask a Linux zealot what OS will be easy to use, they'll say Linux even though Windows and Mac OS X are easier to use. That is sad.

To most Linux zealots, a solution being open source is a priority, but it's not necessarily my priority. The various benefits of open source ultimately have to be evaluated by me.

Zealots attempt to make decisions for me, and that is sad.


[ Parent ]

Right. (3.81 / 11) (#28)
by Agent1 on Fri Jul 11, 2003 at 10:42:01 AM EST

.NET isn't a language.

"Thats the whole point of the internet, to slander people anonymously." - Anonymous
I think that proves the point (5.00 / 1) (#110)
by ethereal on Mon Jul 14, 2003 at 02:35:22 PM EST

It's not a language, it's a marketing ploy. Which, at least in the "Everything's going to be .Net this and that" sense, seems to mostly have been abandoned. Although I'm sure the language-related parts of it will stick around.


Stand up for your right to not believe: Americans United for Separation of Church and State
[ Parent ]

How about trying to understand before you rant? (4.50 / 20) (#40)
by untrusted user on Fri Jul 11, 2003 at 12:03:36 PM EST

Let me summarize:
  • Interfaces don't have constructors.
  • C# doesn't have templates.
  • A list box doesn't delegate painting to its contained elements.
  • Cute tricks to try and modify the behavior of an existing control (oh, sorry, widget) cause trouble. What a new insight.
  • You don't know how to to proper loose coupling because you don't understand interfaces.
Conclusion: .NET is unusable.

The "interface" part is what bothers me most. Once understood, interfaces are such a powerful concept, but instead of even trying to understand, you dismiss them on the fact that you can't look up a constructor in the interface's documentation.

Graphics (none / 0) (#50)
by e8johan on Fri Jul 11, 2003 at 03:08:31 PM EST

Graphics is not an interface, then Microsoft would have named it IGraphics.

[ Parent ]
Mmm (3.50 / 2) (#67)
by The Central Committee on Fri Jul 11, 2003 at 10:13:17 PM EST

Microsoft use a lot of abstract classes for interfaces because they version better.

You personaly are the reason I cannot believe in a compassionate god, a creature of ineffable itelligence would surely know better than to let someone like you exist. - dorc
[ Parent ]

Rebuttals (4.89 / 19) (#43)
by caine on Fri Jul 11, 2003 at 12:41:30 PM EST

How did I find this? I do not remember as the formerly great MSDN has degraded into a disorganized source of shallow knowledge. No more great code examples, nor any in-depth descriptions. This is one of many examples where the win32 structure blends through the thin .Net layer

The MSDN with my VS.NET Enterprise Architect 2003 is riddled with code-examples, in-depth descriptions, special articles about not only .NET areas but programming in general. Either you have a very incomplete MSDN or you're really lousy at searching.

Another short question on the subject is: why do Collections have a Count while Arrays have a Length? This does not matter much to the language implementer, but it adds unnecessary confusion for the end developer.

Because they are diffrent things? An array may have length L but only contain C objects. A collection on the other hand is always as long as the number of items it contains. Therefore they represent diffrent things and so are called diffrent things.

When designing a completely new language, why wasn't templates introduced at once?

Because templates are the bane of all good? :-) If they do plan on putting them in, I weep.

Rapid innovation of the C# language? I want my language to be as static as possible, to avoid incompatibilities and yet another versioning factor to pay attention to. All this proves is that they released the language too early.

C++ seems to have managed just fine without even a proper specification and constantly changing language and compilers.

Now, as the drawing and scaling is located in the ListBox, this leaves me with two options: 1) put a huge switch-statement in the event handlers or 2) define an interface with the methods Draw and Measure and call these for each event.

You can inherit from most controls' inner controls (for example a listbox item) and override their OnPaint to do whatever special drawing you want.

I would go so far as to call .Net a marketing trick. It does not bring anything new to the programmers. The only thing that I can like is that Visual Basic fails to be backwards compatible, so perhaps some developers try a real programming language.

I've done considerable real programming in .NET and I must say I love it. It's powerful, easy to use and comes with a great set of documentation. Application development, especially buisness applications with SQL-bindings, can be done extremly quickly.

Also, the ability to share most of the code between a normal application and an ASP.NET application is a nice bonus.


Yes, yes (3.50 / 4) (#46)
by kjb on Fri Jul 11, 2003 at 01:27:36 PM EST

very interesting, but, hey, the article says negative things about Microsoft, so it must be good!

Now watch this drive.
[ Parent ]

Rebuttals reloaded. (none / 0) (#104)
by UnknownReference on Mon Jul 14, 2003 at 02:07:24 AM EST

I really can't understand on why people dont appreciate a quality product of such magnanimity with around 5 million lines of code in its first release has so many people working on it..

I perfectly agree with Caine in his remarks on .NET and would like to add some more to his comments.

.Net Windows.Forms is really just a thin layer over win32

You must understand that .NET is just an abstraction provided so that all object creations, event handling, message handling and remoting infrastructure are provided to the end developer to be done at a greater ease. Internally what the framework does to get the job done shouldn't be any of the end user's concern unless he;s really interested in modifying the behaviour of a control itself or somethign like that. Well it makes perfect sense to use the base win32 api's to create control handles and take care of rendering mechanisms to be more effective in terms of speed and reliability since this is the api that the windows itself relies on ! right ?

About generics, its importance was not very much felt in the first release. I guess MS wasn't sure how .NET will catch up with the developer mass and so waited for the results to be evident before announcing what more can be done using C# and .NET in general. And this is the first step !

If you want to realise the power of .NET in whole try out some of the awesome features of the framework like ADO.NET, ASP.NET, XML support and the distributed computing ( Remoting and Web Services ) which are basically unbeatable as compared to the support provided by any other technology.

I would go so far as to call .Net a marketing trick. Let the author work on all these and then decide whether .NET is a trick or an initiative to make the life of developers easier.

I've been working in .NET for almost a year now and frankly apart from a few cribs here and there, this has been absolutely fantastic to work on ! Coming from a C++ background i find C# really comfortable. The online help, msdn and other resources provide plenty of support and guide the developers in the right track for doing things according to best practices... Several forums are also available for .NET to help amateurs like the author clear their doubts.

My advice to the author is not to go around ranting 'unknown made up' facts about something that is well established and is being followed widely by many people !

[ Parent ]
Carnage4Life (3.00 / 4) (#45)
by leviramsey on Fri Jul 11, 2003 at 12:47:49 PM EST

I'd be kind of interested to know what Carnage4Life's views on this article are. So, Dare, if you post anything to this article, please reply to this. Thanks in advance.

Sigh, post to slashdot (2.57 / 14) (#47)
by starsky on Fri Jul 11, 2003 at 01:42:03 PM EST

A side note is that the on-line version of MSDN can be real fun reading. Look for documents describing the differences between .Net and the predecessors and you will find lists of earlier design mistakes by Microsoft.

When I masturbate, I prefer pictures of women nude.

Really, I'm interested in .net, so I came into this article interested but it turns out it's just a thinly veiled attack on MS.

oh really? (4.00 / 2) (#62)
by rmg on Fri Jul 11, 2003 at 07:45:41 PM EST

it was too sympathetic to micorsoft for my taste.

_____ intellectual tiddlywinks
[ Parent ]

how infected by decimal is it? (2.00 / 4) (#49)
by Fen on Fri Jul 11, 2003 at 02:23:18 PM EST

Does decimal infect .net? Can you even do binary floats?
Infected by Data (none / 0) (#65)
by OldCoder on Fri Jul 11, 2003 at 08:38:25 PM EST

Not decimal limited at all. See this MSDN page for a description of the primitive types. This ain't COBOL.

By reading this signature, you have agreed.
Copyright © 2003 OldCoder
[ Parent ]
Try XWT (4.66 / 3) (#55)
by tzanger on Fri Jul 11, 2003 at 04:34:03 PM EST

xwt.org -- think XUL without Mozilla cruft, JavaScript without browser crap, multiplatform, client/server and fast.

The Benshaw quoting app demo is what I have led the development on, and our entire intranet is moving to this system.  The current widget set stinks but we're funding the widget audit that should be done in the next couple weeks to go along with the new engine release.

In a nutshell: design your UI using XWT: the basic unit is the box, and you group boxes into widgets, and then arrange widgets on surfaces.  (in reality you have a widget library so you just arrange the widgets how you want and hook up the traps to do what you want with them.)  Any heavy lifting is done by a server somewhere, and the only methods of communications are through XMLRPC or SOAP.  SSL is supported.  You can take widgets and extend them or write entirely new ones.  You may also dynamically theme the widgets in order to match the OS you're running on.

Security wise, the XWT app runs in a very restrictive sandbox.  You can open a new browser window (but not get data back), use platform-standard Open/Save dialog boxes, and access a server via XML-RPC or SOAP.  That's it.  The engine is written in Java1.3, which means that it'll run just fine on JME.  There are also native binaries for Win32 and Linux/X11.

I love XWT because it's fast and flexible and eliminates all the bullshit of standard CGI web apps and crap like ActiveX and DHTML.  The apps you create act and feel like "real" native applications which is a big thing in my books.  The engine's damned fast and focuses on the UI, any business logic is handled on the server, where it belongs.  I love this technology.  :-)

Qt versus .NET (4.90 / 11) (#64)
by OldCoder on Fri Jul 11, 2003 at 08:20:39 PM EST

You should provide a link to a good intro to Qt for those of us who know not what it is.

I really take exception to the idea that .NET is a thin wrapper around win32. It's quite a different package. Of course, it was inevitable that there would be some similarities, given that the people who built .NET were mostly using win32 as an implementation tool and had also been using win32 to develop apps.

I've coded win32 apps in C++ and .NET apps in C# and there is a world of difference between the API's. Dot-Net is much better organized and documented, the C# language with .NET is a more productive environment than C++ with COM and ATL for most things.

The MSDN documentation is very good to use. In just a few minutes I cranked up MSDN from my hard drive and set the filtering to "Visual C#" and put "Graphics" into the index and knowing that it used the GDI+ system clicked right on the topic "GDI+" that appeared and got to "CreateGraphics" in just a few more clicks without looking for it specifically or typing in its name. It's all about context and familiarity. Yes, it is a bit of a documentation bug that the logical place to find the constructor for a Graphics object contains no reference to CreateGraphics call, but the natural thing to do at that point is to start reading about the parent namespace, System.Drawing, learn about GDI+ and stumble upon this page which tells you what to do.

It seems more reasonable to assume that the author is simply not used to the MS way of doing things. The Linux/Unix documentation is much worse. For (my pet peeve) example, the readlink system call documentation refers to an ELOOP error return, which would lead the naive programmer to believe that the readlink call follows a chain of links all the way to the destination. This is not the case (you have to code your own little loop), and the misleading nature of this document has not been remedied in 2 decades (it's an old and useful Unix call brought forward).

Having said all that, I am more than willing to believe that there are concepts common to both .NET and the Win32 API that are different from Qt, and that in at least some of these cases Qt has a better idea. This doesn't mean that .NET is a "Thin wrapper" around win32. The major source of commonality is the underlying windows operating system. Controls (aka Widgets) useful for programming have often been invented at the application level and then migrated downward into the Windows OS. That's sort of why they call it Windows. When this is done, the way of using controls tends to be pretty similar from the different layers of the system.

A long time ago, I had the opportunity to use a C++ library for GUI programming called zApp, (last seen at Rogue Wave). It was a much better and more elegant programming model than MFC, but what did it matter?

Historically, Windows has been less modular in concept than Unix/Linux for which the GUI layer (X, Qt...) was a bolt-on accessory. This enabled MS to squeeze a GUI onto a cheaper piece of hardware than the Unix folks could, generating billions of dollars for MS and enabling millions of people to use computers who previously had to do without.

Actually, Win32 has become something of a virtual layer, implemented differently on top of different windows OS'es. I imagine parts of the .NET run-time are coded directly to the different OS-level system calls.

Virtual Machine
The .NET system does not use a "Virtual Machine" in the Java sense of that word. .NET code is compiled before it is executed. Sometimes it is compiled each time the program is run, but it is compiled.

Why Programming in C++ is A Bad Idea for Windows
With all system selection choices, you face dealing with the characteristics and limitations of the chosen system. One of the characteristics of the Windows system is the ideology and business style of the organization behind it. Microsoft simply will not give you (or even sell you) the tools to make good applications that are platform-portable. MS will bite off its own genitals and leap through it's nostrils rather than provide good cross platform tools. Any really good C++ library for writing applications is automatically a good candidate for re-implementation on other substrates (e.g. X windows/Linux). Hence, one should not have been surprised to see that MFC was bloated and just filled with win32-specific features and characteristics. You can code what you want, but you'll never get it off of Windows if you're using MS tools. See also the history of the Windows Template Library (WTL). So if you want really good tools from MS, you settle into the warm nest they provide (.NET) that is isolated from other platforms by armies, minefields and high walls. You must adapt to your location.

Other platforms have other characteristics and trade-offs.

By reading this signature, you have agreed.
Copyright © 2003 OldCoder

qt has licensing issues (3.00 / 2) (#68)
by DJ Glock on Fri Jul 11, 2003 at 11:09:19 PM EST

if i was you i would stick to things like realbasic and the codewarrior IDE by metroworks(c)

[ Parent ]

What issues? (none / 0) (#89)
by Joe9999 on Sat Jul 12, 2003 at 09:14:38 PM EST

As long as you pay for a licence, what issues are there?

[ Parent ]
It's too bad (none / 0) (#125)
by Jarda z Pisku on Mon Aug 11, 2003 at 05:36:01 PM EST

that you cannot in fact create and distribute multiplatform OSS / FS programs. And you can get one developer one platform licence for $1500 - that's too much. But Qt is perfect. And I like PyQt as well.

[ Parent ]
ZooLib and wxWindows seem better solution than Qt (none / 0) (#81)
by it certainly is on Sat Jul 12, 2003 at 09:35:07 AM EST

for a C++ cross-platform GUI/application framework. I'm not sure how they compare to zApp.

kur0shin.org -- it certainly is

Godwin's law [...] is impossible to violate except with an infinitely long thread that doesn't mention nazis.
[ Parent ]

virtual machines (5.00 / 1) (#88)
by sesquiped on Sat Jul 12, 2003 at 07:45:45 PM EST

The .NET system does not use a "Virtual Machine" in the Java sense of that word. .NET code is compiled before it is executed. Sometimes it is compiled each time the program is run, but it is compiled.

Actually, it does use a virtual machine, in precisely the Java sense of the word. .NET code in any language is compiled into MSIL (Microsoft Intermediate Language), the same way that Java source is compiled into Java bytecodes. That can either get run by a VM, or JIT-compiled to native code that runs at runtime. Just like Java bytecodes. Your implication that Java is not compiled is entirely wrong: Java code is most often compiled twice: once to bytecode, and then to native code with a JIT compiler when it's run.

Now, .NET does provide one more option, which is to compile the MSIL into native code with an optimizing compiler, and store it in a file. But there are also Java compilers which do the same thing, so that isn't unique to .NET either.

[ Parent ]

VM (3.50 / 2) (#99)
by OldCoder on Sun Jul 13, 2003 at 05:42:29 PM EST

We agree on the facts. The Java VM and its role plays a similar but not identical role than the IL and the Common Language Runtime. We could look up the phrase "Virtual Machine" in some computer dictionary but it's doubtful that the lexicographers know more about it than we do.

By reading this signature, you have agreed.
Copyright © 2003 OldCoder
[ Parent ]
No you don't agree on facts... (none / 0) (#124)
by israfil on Sat Jul 19, 2003 at 11:46:34 AM EST

The Java VM performs exactly the same function as the Common Language Runtime. Specifically, the Java VM is often even called the Java Runtime.

Specifically they are both converters from a common platform-neutral binary language, or intermediary language, and they are responsible for providing low-level OS-style services and final compilation services. Same differences. They do have some different features, but these are not fundamental differences.

i. - this sig provided by /dev/arandom and an infinite number of monkeys with keyboards.
[ Parent ]
usless use of pet peeve (1.00 / 2) (#94)
by sholden on Sun Jul 13, 2003 at 08:37:58 AM EST

For (my pet peeve) example, the readlink system call documentation refers to an ELOOP error return, which would lead the naive programmer to believe that the readlink call follows a chain of links all the way to the destination. This is not the case (you have to code your own little loop), and the misleading nature of this document has not been remedied in 2 decades (it's an old and useful Unix call brought forward).

A naive programmer would do no such thing, "the contents of the symbolic link" means one obvious thing and that one thing only.

The documentation says it might set errno to ELOOP, because it might. Just like every bloody other system call that operates on paths (open, unlink, etc) can and does.

How do you propose to remedy this "misleading" description (which I have never seen anyone find misleading, but I guess incredibly stupid people might)?

The world's dullest web page

[ Parent ]
I must agree (3.00 / 1) (#98)
by bafungu on Sun Jul 13, 2003 at 01:40:03 PM EST

If the readlink(2) documentation is being held up as an example of bad documentation, then I'd say Unix documentation is in remarkably good shape.

I would be appalled if readlink() resolved the entire path, because that would mean there was no programmatic way of resolving the components involved in a path! And ELOOP occurs not because the path you give is looped, but because a loop is encountered in resolving the path you gave, i.e.:

ln -s x x
ls -l x/foo

Here, ls cannot resolve foo because it cannot get past x. readlink will have the same problem.

Finally, it is better to light a candle than curse the darkness. The Unix man pages are all ours to use and improve: any suggestions for improvements can be submitted to the current maintainer.

[ Parent ]

Good arguments (none / 0) (#101)
by OldCoder on Sun Jul 13, 2003 at 06:18:33 PM EST

You are of course right that readlink had better not go all the way. However, your example of a file linked to itself should be the following, which gives a better analogy to readlink:
$ ln -s x x
$ ls -lt x
lrwxrwxrwx 1 OldCoder None 82 Jul 13 14:50 x -> x
This is what readlink does, it gets back the same link. If you give readlink a genuine symlink you don't get the loop. The CreateGraphics vs readlink docs are rather different and further comparison is not too useful.

I think my basic point that the MS docs are pretty good still stands.

By reading this signature, you have agreed.
Copyright © 2003 OldCoder
[ Parent ]

"genuine" symlink (none / 0) (#103)
by sholden on Sun Jul 13, 2003 at 08:02:00 PM EST

MS docs are often pretty good - with a few exceptions.

Unix docs are often very bad - with a few exceptions.

You won't get any argument from me on that. However, MS docs are worse than the docs of some vendors, and unix docs are better than the docs of some vendors.

Solaris man pages are much better than Debian man pages, in my opinion - hence unix docs are better than linux docs...

I still don't undertsand how ELOOP can be a problem with readlink. It's mentioned in the long list of error codes, and I guess it would be possible to confuse the two types of symlinks involved (the one that is the last component of the path and is not resolved, and the ones that are in other places in the path and are resolved), but 30 seconds of thinking would clear it up.

Anyone who needs readlink has almost cetainly already used calls like open(2), unlink(2), etc, and hence will have come across ELOOP before.

Personally I don't know anyone who actually reads the possible error codes when working out what a function does.

And you can get a loop with a "genuine" symlink. Something like:

; ln -s b a
; ln -s c b
; ln -s d c
; ln -s e d
; ln -s f e
; ln -s g f
; mkdir g
; ln -s ladeda g/link
; ls a/link
ls: a/link: Too many levels of symbolic links
; ls b/link

readlink(2) on a/link will give ELOOP, even though a/link is in fact a "genuine" symlink.

The world's dullest web page

[ Parent ]
Incredibly Stupid People (none / 0) (#100)
by OldCoder on Sun Jul 13, 2003 at 05:48:40 PM EST

I know of three perfectly rational new-to-Unix programmers who agreed on the wrong interpretation from reading the docs. Anyway, it's just one little example. A lot of the MS documentation is quite good. I don't think it's the case that the overall level of docs for programming apps to the linux "API" is better than that of .NET. That's all I was trying to express.

By reading this signature, you have agreed.
Copyright © 2003 OldCoder
[ Parent ]
hmmm (1.94 / 18) (#66)
by DJ Glock on Fri Jul 11, 2003 at 09:36:07 PM EST

is this a serious article or did you just want to flaunt your programming skills in the face of those of us who are not so technically inclined?


what skills? nt (3.50 / 2) (#69)
by Work on Fri Jul 11, 2003 at 11:21:50 PM EST


[ Parent ]
If you've got it... (2.80 / 5) (#71)
by it certainly is on Fri Jul 11, 2003 at 11:43:36 PM EST

My sarcasm detector is bleeping like crazy, but there's a nagging thought in the back of my mind that you might be serious.

e8johan just looks like a regular programmer to me. Perhaps you have some sort of envy of programmers? You shouldn't, the terrible smell and complete lack of social ability is enough to put anyone off.

kur0shin.org -- it certainly is

Godwin's law [...] is impossible to violate except with an infinitely long thread that doesn't mention nazis.
[ Parent ]

ok well (3.00 / 6) (#72)
by DJ Glock on Fri Jul 11, 2003 at 11:47:47 PM EST

if by regular you mean elitist and pedantic i guess your right.

[ Parent ]

They're all like that. (3.66 / 3) (#73)
by it certainly is on Fri Jul 11, 2003 at 11:53:05 PM EST

Elitism means they can recognise and adapt to superior technology. Pedantry means they are adept at tracking down errors and bugs in code inspections.

kur0shin.org -- it certainly is

Godwin's law [...] is impossible to violate except with an infinitely long thread that doesn't mention nazis.
[ Parent ]

i'm not sure what dictionary you use (5.00 / 3) (#77)
by DJ Glock on Sat Jul 12, 2003 at 04:13:22 AM EST

these definitions are certainly not in mine. you are one zany fella it certainly is. and your comment is quite zany, it certainly is! thank you for taking the time to reply to my comment, i have given you a 5 in return for your kindness.

[ Parent ]

You have to be ruthless, (none / 0) (#80)
by it certainly is on Sat Jul 12, 2003 at 09:16:38 AM EST

and realise the lucrative potential of peoples' personality defects.

kur0shin.org -- it certainly is

Godwin's law [...] is impossible to violate except with an infinitely long thread that doesn't mention nazis.
[ Parent ]

That's not a regular programmer... (4.00 / 1) (#111)
by ethereal on Mon Jul 14, 2003 at 02:38:20 PM EST

...that's just the good ones :) Especially the pedantic part.


Stand up for your right to not believe: Americans United for Separation of Church and State
[ Parent ]

By 'elitist' and 'pedantic' you mean (4.00 / 1) (#119)
by Will Sargent on Tue Jul 15, 2003 at 12:15:26 AM EST

'good.'  There are many, many programmers who are not elitist and pedantic, because they don't have the luxury of knowing that they're right.
I'm pickle. I'm stealing your pregnant.
[ Parent ]
If you are not technically inclined... (4.25 / 4) (#87)
by joto on Sat Jul 12, 2003 at 06:33:09 PM EST

If you are not technically inclined, then why read it?

Do you think that we should confine kuro5hin to children fiction, so that everyone will have the ability to understand every story? Maybe you could tell me the point of writing a technical article, if everybody already knows the content?

Now, I haven't worked much with either .net or qt, but I certainly don't think the article is over the head of anyone that has.

[ Parent ]

thoughts on C# (5.00 / 1) (#75)
by NFW on Sat Jul 12, 2003 at 12:43:49 AM EST

"const" is only halfway implemented. I miss being able to return a const object, and knowing that the compiler would (try to) prevent me (and, especially, my coworkers) from calling anything but const methods on it.

That said, I've been doing C++ on Windows since Win3.0 and the thing that bothers me most about C# and .Net is that I never bothered to switch Java back when I had the opportunity. It finally made me understand what everyone was so excited about back in '95 or '96.

That, and the fact that I get an exception when I call "propertyGrid.SelectedObject = Activator.GetObject (blah blah blah)" This bugs me (and I fear that might be a pun).

That, and alsoCamelCasing (which I findReallyUgly and hateToUse but feelCompelled).

Oh, and the lack of multiple implementation inheritance. Boy is that ever annoying. Cut-and-paste is not an acceptable substitute. The wrong language bigots won that argument, dammit. :-)

But still, I wish I'd taken more interest in Java back in the day. Mostly, but not entirely, because of garbage collection. It's ever so relaxing to just forget all about putting deletes in all the right places.

Got birds?

deletes (5.00 / 1) (#78)
by Chep on Sat Jul 12, 2003 at 07:45:51 AM EST

It's ever so relaxing to just forget all about putting deletes in all the right places

Sure, you just have to use smart pointers instead...

As a bonus, you get predictible object lifetime, and with the appropriate amount of RAII, you just don't have to think that much about finalisation.

Well, Windows 3.0 was such a long time ago; I guess all of this was new eons ago anyway.


Our Constitution ... is called a democracy because power is in the hands not of a minority but of the greatest number.
Thucydide II, 37

[ Parent ]

Smart Pointers have problems (4.00 / 2) (#112)
by Vulcannis on Mon Jul 14, 2003 at 04:04:14 PM EST

Smart pointers are hardly predictable.  You get the guarantee that the last smart pointer for a particular pointer will clean up, but no knowledge of where this will be.  In simple cases you can tell where this happens, but then you could have just done the delete manually.  In more complicated cases, this becomes nondeterministic.  I believe there's a research paper that talks about this, but I wasn't able to find a link.

And as a bonus, you lose nice language features like polymorphism (A subtype of B, sp of A is not subtype of sp of B) and covariant return-type overrides.

RAII is a great concept, but is really inelegant to implement with destructor-less languages like C# and Java.  Avoiding finalizers at all times is just plain good advice, as they have many subtle gotchas and limitations.

If it's not black and white, you're not looking close enough.
[ Parent ]

Const in C#... (none / 0) (#95)
by jhannes on Sun Jul 13, 2003 at 11:52:50 AM EST

... is just an unfortunate name clash with the C++ const keyword. Const in C# is designed to replace Java's 'final' in 'public static final' members, i.e. constants.

Like you, I miss const in C# (and also in Java), but I realised that only about 10% of C++ programmers understand it, and it is hopeless to use it only halfway though in a project.

[ Parent ]

C++'s const is a deadend (none / 0) (#113)
by Vulcannis on Mon Jul 14, 2003 at 04:28:27 PM EST

While I don't know the reason why const was dropped by Java's designers, I've come to believe it was the correct decision. While C++'s const is a useful abstraction, it imposes far too many limitations and is especially unnecessary given that C++ fully supports the other natural way of expressing the concept.

Consider what const does in a class. By marking methods with the const qualifier, you're expressing the concept that there are two interfaces to the class, one of which is a subset of the other. OOP languages already have a feature to do this, subclassing. Now, marking a method as const has the effect of preventing write access to any fields, calling non-const methods, etc.. For simple cases, this is great and is simpler (initial coding time-wise) than creating two classes. But this approach is not sufficient for all classes. You can see this with the introduction of the mutable keyword. But even with mutable, the const approach remains strictly less powerful than the two class approach.

For this reason I like that the Java designers didn't bring const into the language; unfortunately they also left out full multiple inheritance, which makes implementing the concept a bit tricky at times.

Also, final is far more useful than in just public static constants. What I'd really like to see is every variable declaration default to final, much like how Nice treats variables and null behaviour.

If it's not black and white, you're not looking close enough.
[ Parent ]

What (none / 0) (#114)
by newellm on Mon Jul 14, 2003 at 05:40:43 PM EST

The most important reason for using const is that you can pass objects by const &.  This allows the compiler to produce much more efficient code.  The same result can be accomplished using pointers, or a non-const reference, but that leads to less readable, more error-prone code.

[ Parent ]
You're either an idiot or a troll (1.00 / 1) (#115)
by Vulcannis on Mon Jul 14, 2003 at 09:22:16 PM EST

And in either case, go away.

const in C++ exists so the developer can better express constraints upon variables and types. Performance is usually a convenient side-effect and in some cases can even be achieved by a sufficiently smart compiler without explicit annotation by the developer. I sure as hell would not want to deal with any code or applications written by a developer that placed performance effects of const above all else.

Further, the performance gain you alude to is achieved solely by the use of a reference (or pointer) for passing class instances. The presence of const is irrelevent from a function-call performance standpoint. More importantly, the difference between passing a class instance to a function by value or by reference is far greater than some simple performance measure.

If it's not black and white, you're not looking close enough.
[ Parent ]

Huh (none / 0) (#116)
by newellm on Mon Jul 14, 2003 at 09:51:08 PM EST

I was beginning to write a response to tell you how full of shit you are.  But instead, why don't you pick up a copy of "The C++ Programming Language" by Bjarne Stroustrup and figure it out for yourself.  Then look through the Qt library and notice how every single function that doesn't logically modify a class is declared as const.  And notice how they pass const references everywhere.  I don't know what you do, but I program using C++ and Qt 40+ hours a week, and I get paid well doing it.  

[ Parent ]
Hierarchy-based approaches (5.00 / 1) (#118)
by jacob on Tue Jul 15, 2003 at 12:06:03 AM EST

Could you give a concrete example of this technique in code? I'm not seeing how it works. Say I want to create a class of Counter objects that have increment() and getCount() methods, where of course the increment() method mutates the object and getCount() doesn't. Are you saying I should do the following (untested Java code):

class Counter {
  int count;
  int getCount() { return count; }

class MutableCounter extends Counter {
  void increment() { ++count; }

? If this is the technique you're advocating, I don't agree this is a better way to do things than an explicit declaration that getCount is constant (or alternately that increment performs an update) because it "breaks the inheritance tree": there's no class here you could subclass to get an enhanced Counter class that also had a constant getCount() and an updating increment() method.

If you're using Java or you're willing to use the appropriate tricks in C++, interfaces seem to work a little better to my way of thinking:

interface ICounter {
  int getCount();

interface IMutableCounter extends ICounter {
  void increment();

class Counter implements IMutableCounter {
  int count;
  int getCount() { return count; }
  void increment() { ++count; }

This way Counter can be extended and still preserve its two interfaces. However, this still isn't as powerful as the const keyword because const provides a guaranteed that's checked by the compiler that constant functions never update variables; the interface approach provides only a convention. For instance, if I extended Counter like so:

class MyCounter extends Counter {
  int getCount() { ++count; return count; }

there's nothing that would stop me. This example is contrived, but it's easy to imagine more realistic situations in which the same problem could arise. It comes down to the same basic principle we see over and over again in bug detection: the more you tell the compiler about your intentions, the more help your compiler can be at finding places where you didn't do what you intended.

"it's not rocket science" right right insofar as rocket science is boring


[ Parent ]

Well (none / 0) (#120)
by Vulcannis on Tue Jul 15, 2003 at 01:24:42 PM EST

I'd say that both are examples of what I'm advocating, but you're right about their drawbacks. Java has limitations (including lack of MI, as I mentioned) that prevent the technique from providing all the benefits that C++'s const does. It's nicely ironic that C++ could probably do a better job implementing this technique than Java could, though I still don't think it would be perfect. But then neither is const and mutable.

I'm not completely sure what you mean by the "breaks the inheritance tree" part; judging from your interface example I assume it's about Java's lack of MI.

Hrm, I didn't say it explicitly in my original post but I don't really believe that current languages (that I'm familiar with) can actually duplicate all of const's guarantee's using this technique, nor that the technique as described is complete. I was approaching const more from a language-design point of view; for example I would rather see Java get MI and any other features it needs to implement this technique than to just get a const equivalent (which I don't even think could be made to work given Java's object model). MI at the very least seems to be a requirement, and the problem you point out of guaranteeing access indicates something further would also be needed.

Incidentally, you could "solve" the last problem by declaring getCount as final. But that would still be less powerful than the const approach, just in a different way.

I completely agree with you about better expressing intentions in the code, hence my desire that Java variables be final by default. One interesting concept that I've considered is the inverse of const: passing a const variable says to a function, "I can mess with this if I like, but you can't." What about a feature whose effect says: "You can mess with this all you like, but I promise I won't." Aliasing seems to be the real killer in such a case though.

If it's not black and white, you're not looking close enough.
[ Parent ]

Misses the point (3.71 / 7) (#91)
by blackpaw on Sun Jul 13, 2003 at 02:44:05 AM EST

As others have posted you are bringing the wrong attitude to the subject altogether and misunderstand critical subjects such as interfaces. Also you skip important parts of .net such as dll versioning and signing, automatic object bindings in any language, cross language compatibility etc ...

Why compare it to QT ? that is just weird

Basically you appear to be unwilling to make the effort to stretch yourself and learn new concepts or ways of doing things. You'd better change that or like many other developers in five years time you'll find yourself completely obsolete - overtaken by tecnology, wether it be .net or something else altogether.

before this discussion continues any further, (1.13 / 23) (#93)
by rmg on Sun Jul 13, 2003 at 03:48:34 AM EST

consider this:

F1R57 P120zz77333333zzzzz0rz!!!

thank you.

_____ intellectual tiddlywinks

Wrong (none / 0) (#108)
by daragh on Mon Jul 14, 2003 at 09:45:04 AM EST

You missed an 11 towards the end. And the colour is just hideous.

No work.
[ Parent ]

Perspectives (4.33 / 3) (#97)
by jhannes on Sun Jul 13, 2003 at 12:09:34 PM EST

When commenting on C# it is important to notice the immediate motivation behind creating it. My perception was that MS was bleeding developers to Java, and needed to get them back. Almost every design decission in C# can be explained by comparing it to Java. Templates is just a case in point. C# did not need templates to fight Java, as Java does not have templates. Comparing C#/.NET to Qt does not make too much sense, and Qt developers are not who MS are trying to woo.

I agree with the posters comments on Windows Forms not being particularly well designed. The sad bottom line, however, is that for most developers out there, it is the easiest way of creating native look-and-feel windows apps.

To provide some balance, I would urge the author to look at ASP.NET and especially ADO.NET. I find the latter to be much more well-designed for its purpose than any competing library I have worked with.

PS. Ruby rules.

Why not templates (none / 0) (#105)
by p3d0 on Mon Jul 14, 2003 at 08:09:55 AM EST

Templates are not the best genericity mechanism out there. They are powerful in some ways, but weak in others, and are verbose to the point of madness.

While theoretical, I think structural virtual types is the best genericity mechanism, and that's the one I'd like to see in new Java-like languages.

But, above all, the fact that there is no agreement on this issue is why they aren't "introduced at once".
Patrick Doyle
My comments do not reflect the opinions of my employer.

Only Tangentially Related (none / 0) (#121)
by ewhac on Tue Jul 15, 2003 at 02:43:01 PM EST

I've been trying to port a macro from Visual Studio 6 to Visual Studio .NET, and failing. Since there are a number of .NET users visiting, perhaps someone here can confirm or deny the futility of this exercise.

I wrote a VS6 macro that, among other things, sets the TAB size and indent size for the currently active document (TextDocument.TabSize and TextDocument.IndentSize). It is important that only the current document be affected, and that the editor's global settings be left alone.

So after a weekend of poking around through the atrocious .NET documentation and just bashing on the thing, I believe I have learned:

  • TextDocument does have a TabSize and IndentSize property,
  • They are not documented anywhere (I found them almost accidentally in the class browser),
  • They are read-only.

Doing a search for "TabSize" and "IndentSize" revealed only one meaningful hit: The global settings in the editor -- exactly the thing I don't want to mess with (the user's defaults must not be changed). I cannot find any per-window or per-document settings for TAB size or indent size.

So, does this sound correct? 'Cause if it is, it was a fscking stupid thing of them to do.

Editor, A1-AAA AmeriCaptions. Priest, Internet Oracle.

From an IT guy's view (not bad) (none / 0) (#122)
by Silent Chris on Wed Jul 16, 2003 at 06:27:57 PM EST

I don't do professional Windows programming, so take what I say with a grain of salt.

I do administration (network, Windows 2000 and otherwise) for a small not-for-profit.  My entire college experience was C, C++, etc (etc being SML, a little tiny bit of Java, a little tiny bit of Scheme) on *NIX.  In the lab, this was FreeBSD.  In the dorm, this was Linux (RedHat 6 at the time).  Today I have both a Windows XP desktop and Linux server running at home, along with a host of other toys (convering an old Xbox into a media server).

Anyhow, our shop at work is entirely Windows.  For the most part, it just works with our staff.  However, I didn't really know a lick of GUI code this year.

Situation: a program originally written for Win95 using Borland (a program that prints labels to a legacy label printer) doesn't work right in XP.  Solution: fire up Visual Studio .NET (I have a cheap academic copy).  I used VB in this case, and came up with a workable solution after writing 15 lines of code.  We had it deployed by the following day.

I know there's better stuff than .NET out there, but for me, it's worked very well when I need a quick and simple solution.

Another example: I wrote a "Dialectizer" program as a test of web services.  It goes out on the net and uses a SOAP function (on Borland's site no less) to translate text strings to l33t, cowboy drawl, etc.  Silly, but it's a good test as any of a simple web service.

I was able to get that code done and polished in about 2 hours (this time in Managed C++).  More interestingly, I was able to convert the program to a version that runs on Windows CE with no altering of the lines of code.  The .NET Compact Framework makes the transition for me.

Again, I'm not saying .NET totally rocks.  Some parts (constantly __box'ing variables in Managed C++ royally sucks).  But for quick and dirty Windows apps, it's served me fine.

a summary of your article (3.66 / 3) (#123)
by lvogel on Thu Jul 17, 2003 at 12:43:22 PM EST

"I was forced to switch to sdk b from sdk a because of a management decision at work. Here are some things that sdk b does that are different from sdk a, which I think is stupid."
-- ----------------------
"When you're on the internet, nobody knows you're a dog!"

-a dog
Mr Darl McBride /. (none / 0) (#127)
by muirhead on Mon Sep 08, 2003 at 02:59:23 AM EST

The top post to this slashdot article links back to this story.

.Net Oddities | 127 comments (91 topical, 36 editorial, 1 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!