Visualizing the .NET Framework

eldavojohn writes "If you're a Web developer, you should check out a quick post about the number of types, methods, & fields in the .NET framework. This was done using NDepend. The numbers are quite large — e.g. 39,509 types. The blogger went on to generate tree maps and a dependency matrix."

Comments

Answer: No Thanks

[LiquidCoooled]

I am torn by .shit, it should be good but it just misses something.

Re:Answer: No Thanks

[Naughty Bob]

it should be good but it just misses something.

Simplicity? Internal logic?

Seriously, will MSFT never learn? They are setting themselves up for *4 more years* of poor implementation, and all because they have not learned that 100x the workforce doesn't equal 100x the product, but rather a bloated monster.

But it will keep us in jokes.

Re:Answer: No Thanks

[linumax]

And what exactly makes you think .NET lacks simplicity and/or internal logic?
IANADND, so just asking...

Re:Answer: No Thanks

[Naughty Bob]

Did you read TFA... oh, sorry, I forgot.

I'd rather work with Mono any day...

Re:Answer: No Thanks

[Anonymous Coward]

Let me get this straight.

1. You argue that .NET lacks "internal logic" and "simplicity" after pointing to the article. Never mind that the article merely only reported statistics about the .NET framework instead of asserting that it, does, in fact, support your arguments. So this claim remains baseless, unless you're trying to say lots of types somehow means it lacks internal logic and simplicity. We are waiting for your keen insight on this point.

2. Another user questions your assumption rather innocently.

3. You imply that they did not read the article (which is rather hilarious considering the previous point) and then, to add the icing to the cake, indicate you'd much rather work on Mono. Mono is a version of .NET that runs on non-MS platforms and is compatible at the bytecode level. What sort of examination have you done on the source code of it to determine that it has "simplicity" and "internal logic?" How does it meet those goals, yet have the same external API of .NET? How does it not suffer from "bloatedness" if it has at least as many publically available classes as .NET?

We await your answers, mighty Naughty Bob.

Re:Answer: No Thanks

[diamondmagic]

Did you bother clicking the link to "Mono?" It links to this URL:
http://en.wikipedia.org/wiki/Infectious_mononucleosis

Re:Answer: No Thanks

[RobertM1968]

I hate to say it, but whether "Naughty Bob" is normally a troll or not, I suspect he is correct.

MS has yet to show the type of design innovation that foregoes bloated code. Instead, when something doesnt work, or wasnt planned out correctly, they just add a bunch more stuff, then a bunch more, then a bunch more... then pat themselves on the back for the "innovation" which they equate with the number of things added.

Writing an extensible framework - and then extensions (or example extensions) would have been smarter, smaller, faster, and easier for true developers to implement.

The "Everything - including the kitchen sink" attitude does not work well in the computer world - the fact that their programs and apps are getting far more bloated, barely gain additional functionality (regardless of their claims) and getting far more resource hungry (while not adding significant functionality) is a perfect example - and one I think they are following with .Net

To me, it looks more like they are trying to prove that they can compete with, and surpass, all their .Net competition by sheer number of "features"/"capabilities" - which does not make it better. Their .Net framework already scaled horrendously to many types of implementations (like the Service/Customer tracking unit CompUSA used to use - as any of you who worked in Tech or Business Sales can attest to - from fond memories of running a rather simple report, going out for coffee and a quick breakfast, coming back, and still having 10 minutes to wait (of a total 30-40 minutes) - nor were the data sets that big, or the front end complex).

I'm far happier with using ________________ (pick almost anything else used in the non-Windows world), and far happier extending base classes and functions, over using pre-written bloatware versions.

But then again, besides the competition aspect, I think they are also trying to woo companies that can hire even less expensive "developers" since sooooooooooo many more things have been added making development a matter of point and click (and requiring even less actual development skills)... it seems more like a two prong attack against their competition.

Great, that's fine... nothing wrong with that - if it's not at the sacrifice of security, performance, and interoperability. But of course, it does sacrifice all of those... and really doesnt seem to do much at all.

So many of the new methods and classes are all stuff that the originals should have allowed the extensibility for to begin with. And so many should be variants on the same method (SOM anyone? Compare the SOM/DSOM design to just the first few lines listed in the article).

...so tell me again, how is "Naughty Bob's" post flamebait? No one who has responded to him has yet said why.

Feel free to mod this anything you want... doing so wont change reality.

Re:Answer: No Thanks

[random0xff]

Writing an extensible framework - and then extensions (or example extensions) would have been smarter, smaller, faster, and easier for true developers to implement. .NET 4 will have an extensibility framework.

Re:Answer: No Thanks

[setagllib]

...on top of everything accumulated since .NET 1.0, making it even more bloated. It'll be fun watching them spin that as a feature. That's what I like about projects like Python 3000 - learn from the previous generations, don't absorb them.

Re:Answer: No Thanks

[sheldon]

But then again, besides the competition aspect, I think they are also trying to woo companies that can hire even less expensive "developers" since sooooooooooo many more things have been added making development a matter of point and click (and requiring even less actual development skills)... it seems more like a two prong attack against their competition.

Given an experienced C# developer makes six figures, I'm not sure that is inexpensive.

Microsoft seems to focus on getting things done, rather than elegance. That's what you mean, I think.

Re:Answer: No Thanks

[metallic]

To me, it looks more like they are trying to prove that they can compete with, and surpass, all their .Net competition by sheer number of "features"/"capabilities" - which does not make it better. Their .Net framework already scaled horrendously to many types of implementations (like the Service/Customer tracking unit CompUSA used to use - as any of you who worked in Tech or Business Sales can attest to - from fond memories of running a rather simple report, going out for coffee and a quick breakfast, coming back, and still having 10 minutes to wait (of a total 30-40 minutes) - nor were the data sets that big, or the front end complex). Did it ever occur to you that the software in question was probably crap? I've done reporting using .NET and SQL Server over a moderate data set (a few gigabytes) and always had the report generate in a few seconds. The .NET framework would be the last thing I would look at for performance problems.

Re:Answer: No Thanks

[RobertM1968]

Did it ever occur to you that the software in question was probably crap? I've done reporting using .NET and SQL Server over a moderate data set (a few gigabytes) and always had the report generate in a few seconds. The .NET framework would be the last thing I would look at for performance problems.

If I still worked at CompUSA (if there was even still one around), I'd be sure to let Microsoft who had a big part in writing it, know. Part of the software was Siebel's (ie: Siebel/MS joint project) and the other part was Microsoft's (ie: Microsoft's).

http://www.microsoft.com/presspass/press/2005/oct05/10-17SiebelAssemblyNETPR.mspx

Your experiences do not jive with numerous complaints about .Net/MsSQL's poor performance - nor with my experiences. But don't take that the wrong way - I am not saying your experiences are untrue. You probably have a setup that works under different load conditions... ours (CompUSA's) worked under conditions where 229 stores were connected to the database - a scenario where the MS products do not seem to scale up to very well (while oddly, Postgres, MySQL and DB/2 handle with ease).

Other situations I have compared with are custom EMS database engines... I have compared (using the exact same data) results on two different locally run with local data MSSQL setups with a MySQL setup through a network with an interpreted REXX engine generating the same reports).

MSSQL: 4min 37sec.

MySQL: 14 seconds (including network time and an 80,000 line HTML report being sent).

The report reads a LOT of data and generates MANY pages of output - hence the 80,000 lines of HTML.

The results were not even remotely close. Both MSSQL based software were written and compiled using MS's Tools, accessing local data via the local, compiled program... (while the REXX engine is just interpreted - through a web server no less - over a network from the client to the database and report engine). Now it is possible BOTH companies just did a very poor job in writing their software - while I did a better job (I wont claim to be great at db stuff, but I do like optimization planning when creating a table or search query). One of the competitor's software used a database structure very similar to ours (but who knows what weird stuff was being done in the query) - while the other one uses 126 tables for the same data (compared to mine and the other's 9 tables)... and all 3 (mine and theirs) required "sorting", loading, and calculating the reports from the entire data set (ie: it's not like they were grabbing too much data - they and I both have to grab all of the data to generate the report).

Your experiences apparently vary... but those are two of mine (one where there are a couple hundred users, the other with one user at a time, and an identical data set).

Re:Answer: No Thanks

[try_anything]

Good DB admins make the money they make for a reason -- administration makes a HUGE difference in the performance of databases, and many of the techniques used to tune database performance are nonstandard and nonportable. Even if you had "exactly the same setup" on both databases, one would have been configured in an inferior way, because each database requires its own brand of trickery. 4m37s vs. 14s could, potentially, be merely the difference between skillful and unskillful database administration.

Worse, it seems you're talking about drastically different data models. Did .NET create the bad data model, or did it merely enable morons (or bright yet ignorant people) to create a product? There's nothing wrong with enabling morons (or bright yet ignorant people) to get a little bit of work done, even if it doesn't result in blazing performance. Even allowing for that difference, it's obvious that a 126-table model was solving a larger problem than your 9-table model. A design that doesn't scale is a crappy solution for *any* problem, but you have no evidence that you could have solved the larger problem well -- you solved a different one. You probably solved exactly the problem your company needed solved, which is possible for an insider to do, but a difficult thing for an outsider, even when creating bespoke software. How can you expect us to believe that .NET was the problem when the business analysis behind the .NET implementation was clearly drastically wrong?

In any case, the massive difference in performance is a common-sense giveaway that you aren't looking at a meaningful comparison between platforms or database engines. I'm a Linux guy, and I personally hate Visual Studio and its code generators, but your comparison is exactly the kind of thing that gives upper management an excuse to cut engineers out of the loop on technology platform decisions. There's no evidence that .NET had anything to do with the performance differences you saw. Alternative explanations (bad data modeling, bad requirements analysis) are screaming in your face, and you have no way of ruling out the possibility that the MSSQL database was poorly administered. Yet you are eager to implicate .NET (though you have now introduced MSSQL into the mix as well -- what exactly does its performance have to do with .NET?) The engineers are just anti-M$ whiners, right? Well, I guess sometimes they are. And that's a big part of the reason why CTOs end up wrapped around a M$ salesman's finger, floating in fantasies of systems that scale effortlessly and internal tools that magically integrate when you need them, while their engineers scream, "No! Wake up! Wake up!"

Re:Answer: No Thanks

[try_anything]

Given an experienced C# developer makes six figures, I'm not sure that is inexpensive.

For some definition of "experienced" that excludes the vast majority of working C# developers, I guess. There are forces in my company pushing for more .NET development, and one of the advantages that has been touted for .NET is that it's supposedly too expensive to hire good Linux developers. Of course, our current .NET development effort is pretty sad. I don't think that's a coincidence. Good development managers go for quality over quantity, so it's natural that in a given company the perception that one platform is superior goes hand-in-hand with the perception that developers for that platform are expensive -- all the results are coming from the team that hired a handful of good developers instead of a herd of lightweights.

Microsoft seems to focus on getting things done, rather than elegance. That's what you mean, I think.

Microsoft focuses on marketable, saleable products. Their pitch is always amazing. They promise miracles. Often, the products are just an honest attempt to live up to a pitch that got way out of hand. When you ask why something in Visual Studio is done a certain way, the answer too often is that it sounds better that way, or it works better in the best-case scenario (i.e., the demo scenario).

The biggest villain in this way is Visual Studio integration. It sounds good to have every single Microsoft code generator and development tool integrated into Visual Studio. Everything is right there under your hands. The downside is that EVERY bug fix to EVERY tool you use has to be released as a patch to Visual Studio. You may not get the bug fix you need when you need it, simply because it's too tightly integrated into Visual Studio to fix easily or it's just the wrong time in Visual Studio's patch/release cycle. Hmmm, maybe it would have been better if it hadn't been integrated quite so "well."

The second biggest villain is invisibility vs. transparency. Visual Studio often makes it difficult to see what's going on behind the code generators and development tools. Then, when you finally find the guts, it's not nearly as nice as it would be if they knew you'd be looking at it. It's like sneaking into your host's private bathroom and finding out how messy they REALLY are when they aren't expecting guests. For the sake of making things super-easy and super-amazing in the optimistic case, all of the troublesome cases (bugs in the code generator, need to get to the bottom of an ambiguous or misleading error message, need to parameterize the code generation in a way that Microsoft did not and could not predict) are made nearly intractable. Why? It isn't because the optimistic case is the predominant one. Murphy's Law still holds, even when using Microsoft development tools. It's because the optimistic case is what matters for sales and marketing. The optimistic case is what you sell . The imperfect case is what developers live with. It's clear which one Microsoft cares about more.

[P.S. To top this off with an intemperate rant: The real biggest Microsoft villain is not Microsoft software, but it is a Microsoft product in a sense: blinkered Microsoft-only developers. You know who I'm talking about, the ones who never program on anything but Microsoft platforms and treat Microsoft "educational" marketing materials as if they were impartial advice from God. They never see the messy failures of Visual Studio because they dogmatically follow the optimistic case completely disregarding business requirements, performance requirements, and interoperability requirements. "Oh, we had to do it this way, because...." NO! You "had" to do it that way because that was the only straightforward way to do it using Microsoft tools, and it never occurred to you to push back against the tools instead of throwing the project

Re:Answer: No Thanks

[RobertM1968]

Good DB admins make the money they make for a reason -- administration makes a HUGE difference in the performance of databases, and many of the techniques used to tune database performance are nonstandard and nonportable. Even if you had "exactly the same setup" on both databases, one would have been configured in an inferior way, because each database requires its own brand of trickery. 4m37s vs. 14s could, potentially, be merely the difference between skillful and unskillful database administration.

It could be... but I admitted that was a possibility. :-)

Worse, it seems you're talking about drastically different data models. Did .NET create the bad data model, or did it merely enable morons (or bright yet ignorant people) to create a product? There's nothing wrong with enabling morons (or bright yet ignorant people) to get a little bit of work done, even if it doesn't result in blazing performance. Even allowing for that difference, it's obvious that a 126-table model was solving a larger problem than your 9-table model. A design that doesn't scale is a crappy solution for *any* problem, but you have no evidence that you could have solved the larger problem well -- you solved a different one. You probably solved exactly the problem your company needed solved, which is possible for an insider to do, but a difficult thing for an outsider, even when creating bespoke software. How can you expect us to believe that .NET was the problem when the business analysis behind the .NET implementation was clearly drastically wrong?

You would think that was the case - but in actuality, my tables store more than twice the info as the 126 table model... and leave out absolutely nothing that is contained in the 126 table model. That one is poor design. The other one (the other competitor's 9 table model) is pretty identical in layout.

All three solve the same problem (ie: the report in question) which MUST (by law) utilize the same data, calculate it the exact same way, come up with the exact same results... so no, there is no difference there. Some of each tables are not needed for the report - and arent called at all. The others (which are called) require the same exact data...

In any case, the massive difference in performance is a common-sense giveaway that you aren't looking at a meaningful comparison between platforms or database engines. I'm a Linux guy, and I personally hate Visual Studio and its code generators, but your comparison is exactly the kind of thing that gives upper management an excuse to cut engineers out of the loop on technology platform decisions. There's no evidence that .NET had anything to do with the performance differences you saw. Alternative explanations (bad data modeling, bad requirements analysis) are screaming in your face, and you have no way of ruling out the possibility that the MSSQL database was poorly administered. Yet you are eager to implicate .NET (though you have now introduced MSSQL into the mix as well -- what exactly does its performance have to do with .NET?) The engineers are just anti-M$ whiners, right? Well, I guess sometimes they are. And that's a big part of the reason why CTOs end up wrapped around a M$ salesman's finger, floating in fantasies of systems that scale effortlessly and internal tools that magically integrate when you need them, while their engineers scream, "No! Wake up! Wake up!"

Perhaps... the REXX implementation is running on eComStation and MySQL v5... the Windows .NET implementation is running on a considerably more powerful machine (2 faster cores, compared to one for eComStation - 2GB RAM compared to 1GB for eComStation) and MSSQL. I have found (well, so has IBM for that matter) that for things like that, OS/2 outperforms Windows by a large margin - and XP uses a lot more resources

Re:Answer: No Thanks

[try_anything]

4m37s vs. 14s could, potentially, be merely the difference between skillful and unskillful database administration.

It could be... but I admitted that was a possibility. :-)

You admitted there could be a difference in programming skill and database design, but those are a little bit different. I don't know much about database administration myself, but I know that our db admins don't do any programming or database design, and when there's a performance problem they often fix it before we (the developers) hear anything about it. They rebuild indexes, instantiate views, and do other mysterious things that I don't know anything about and probably am not using the right words for.

All three solve the same problem (ie: the report in question) which MUST (by law) utilize the same data, calculate it the exact same way, come up with the exact same results... so no, there is no difference there. Some of each tables are not needed for the report - and arent called at all. The others (which are called) require the same exact data...

That doesn't mean all three products were designed to solve only that one problem. From this page you linked, it appears that the .NET solution was built using a generic toolkit for building complete CMR systems. I think there may have been some excess baggage there :-) And you didn't mention who did the job of assembling the components of this toolkit to create the program that produced the report.

not like .NET plugs right into MySQL or Postgres.

As far as I can tell from Googling around, all you need to plug a database into the .NET environment is a sufficiently up-to-date ADO.NET connector for it. Of course, Microsoft is going to keep the requirements moving as quickly as possible so that their products have an advantage, but there is at least one MySQL ADO.NET connector available.

Re:Answer: No Thanks

[larry bagina]

This morning, I tweaked a complex (longer than your post) DB query to run in 20 seconds instead of 20 minutes. Database design makes a huge difference (and knowing what's indexed, but form should follow function).

Wow, that's a big fat ASS^H^HPI

[NewbieProgrammerMan]

Seeing that I have no personal experience with .Net, and seeing that this is Slashdot, I feel totally qualified to poke fun at its stupendous complexity with a quote:

Any third-rate engineer or researcher can increase complexity; but it takes a certain flair of real insight to make things simple. -E. F. Schumacher

Re:Wow, that's a big fat ASS^H^HPI

[AKAImBatman]

Any third-rate engineer or researcher can increase complexity; but it takes a certain flair of real insight to make things simple. -E. F. Schumacher

May I just say... AMEN! :-)

Re:Wow, that's a big fat ASS^H^HPI

[nmb3000]

Any third-rate engineer or researcher can increase complexity; but it takes a certain flair of real insight to make things simple. -E. F. Schumacher

And a stripped-down non-existent API is a way to make things simple? Pretty much all modern languages have very detailed and complete API/framework, and all for the same reason: Why should a programmer have to re-write common routines and data structures for every program? Why bother using a big external library (which can just becomes another dependency) when it can be built into the runtime?

Horse and buggy carriages were much simpler than complex modern cars. We should probably go back to those.

Re:Wow, that's a big fat ASS^H^HPI

[PPH]

Any third-rate engineer or researcher can increase complexity; but it takes a certain flair of real insight to make things simple.
-E. F. Schumacher

Rube Goldberg is alive and working for Microsoft.

Re:Wow, that's a big fat ASS^H^HPI

[CastrTroy]

Yeah, let's compare .Net to PHP. .Net has a very extensive API. PHP also has a very extensive framework. The .Net framework was very well thought out and is very well organized. The PHP framework is cobbled together piece-meal, with everything in the same namespace (Yes, I'm aware that it still doesn't have namespaces, and won't until PHP6 is out, but that's yet another disadvantage of PHP), and separate functions for each database they support, where all are very similarly named, but not exactly the same.

Re:Wow, that's a big fat ASS^H^HPI

[IdeaMan]

"Any idiot can make something complicated. It takes a genius to make something simple" - F.O. Stanley

Say It!

Re:Wow, that's a big fat ASS^H^HPI

[NewbieProgrammerMan]

And a stripped-down non-existent API is a way to make things simple? Pretty much all modern languages have very detailed and complete API/framework, and all for the same reason: Why should a programmer have to re-write common routines and data structures for every program? Why bother using a big external library (which can just becomes another dependency) when it can be built into the runtime?

Horse and buggy carriages were much simpler than complex modern cars. We should probably go back to those. Actually, I was just trying to be funny; apparently I failed. I know there are applications that need all that complexity sometimes. But since you brought it up, when I was growing up, my family owned a horse. Maintaining a horse (without a buggy) is *far* more complex and inconvenient than my car. My car doesn't die if I fail to feed it regularly. I don't have to clean out my parking spot every few weeks. I can let my car sit in my driveway for weeks with no attention and it still works when I need it. I only have to actually worry about maintaining it a handful of times per year, and the total cost (in terms of cash and opportunity cost) is far lower.

Re:Wow, that's a big fat ASS^H^HPI

[AKAImBatman]

And a stripped-down non-existent API is a way to make things simple?

Nope. Einstein said it best, I think:

"Everything should be made as simple as possible, but not simpler."

It's a given that new features will increase complexity. (Which, surprisingly, is not always true. But stick with me for a moment.) The key is to increase the complexity only as much as necessary. If you increase the complexity any farther, you have failed.

I can't count how many times I have seen code that is overly complex. e.g. Someone piled up layer upon redundant layer of code, hoping to get simplicity out of each one. Instead, they create more maintenance, more points of failure, and more bugs. Probably one of the most egregious examples was a company that wanted me to use a go-between piece of software on another server to make a real-time request for XML. They had a lot of weak excuses for this decision, not one of which held water. After peeling back the layers of nonsense, I found out that the reason why they wanted it used is because they had already sunk $10,000 into it.

While not all examples I've seen are motivated by money or CYA, I have certainly seen a lot of examples that were motivated by blind adherence to company standards or existing technologies. Never mind that this particular module doesn't need any of the features of Struts, the company policy says use it, so we use it. Never mind that ADO isn't a good API. We have it, so we should wrap it. Never mind that we could just plug in a lib to do the secure transfer directly, we need to Rube Goldberg it through 5 different machines, protocols, and scripts written in 7 different languages!

There's a reason why engineers harp on the KISS principle. KISS is all about engineering a solution that will last for a long time to come. A solution that can be understood by others, maintained, is reliable, and exceeds the specs wherever reasonable. As Einstein said, make it as simple as possible and no simpler.

Re:Wow, that's a big fat ASS^H^HPI

[MrSteveSD]

I'm not saying that .NET isn't too complex, but having a large number of types does not necessarily increase complexity. In fact having less types often leads to more complexity.

Creating a new type abstracts away complexity and makes code easier to read. For example, you will often find that business software does a lot of comparing of dates. e.g. Checking whether a date is within a given range. More often than not you will find that programmers have just written things like...

If (EnteredDate >= StartDate) and (EnteredDate <= EndDate)
{
//Do stuff
}
else
{
//Tell the user they have entered an invalid date.
}

The logic of checking that dates are in a range is repeated all over the place and the more you have to type, the more likely it is that you will make mistakes. This is where adding a new type, a "Range" type will help. With a Range type you can just say something like...

If (AllowedRange.Contains(EnteredDate))
//blah blah

So adding a Range class actually reduces complexity rather than increasing it. There are plenty of examples of this sort of thing. Imagine writing a car ordering system without having a Car class to abstract away details about cars. You could do it, but the code would probably be a lot more sprawling and complex.

Re:Wow, that's a big fat ASS^H^HPI

[daveime]

It is this level of function (mis)use that makes me cringe.

So instead of being able to see both the variable AND the range it is being tested against IN THE SAME LINE, I now have to go trawling back through the code looking for the place where you created the Range object to find the low and high boundaries of it.

So yet more jumping all over the place hunting for stuff, when the original version was completely fit for purpose, clear, and most importantly, IN ONE BLOODY PLACE.

Of course, it get's even "better" ... not all range checking will use the same ranges ... so then some bright spark will create Range2, Range3, Range4 objects with different ranges in each one. You see how this function does nothing for either readability or speed of debugging, but simply hides information that a programmer NEEDS to know in the context of the line he is looking at ?

You can keep your Range object thanks.

Re:Wow, that's a big fat ASS^H^HPI

[mikael]

From what I have seen of .NET, most of it is wrappers around the existing Win32 widgets. On the blog, there is a comment about cyclic dependencies between different class libraries. This doesn't seem too good - surely it would be possible to split those modules up until the dependencies are removed?

Re:Wow, that's a big fat ASS^H^HPI

[peektwice]

My car doesn't die if I fail to feed it regularly. I don't have to clean out my parking spot every few weeks. My old unsightly Pontiac would die quickly if not fed gasoline, and routinely shit in the driveway, as does .Net. It dies if not fed huge amounts of memory, and pukes regularly.

Re:Wow, that's a big fat ASS^H^HPI

[Anonymous Coward]

Thing with software is that all your laziness eventually gets executed on millions of PCs, the CPUs of which have to run your millions of cycles of meandering code just to display a colored icon. Isn't wasting energy a sin? I think it is.

Re:Wow, that's a big fat ASS^H^HPI

[Gutboy]

Yeah, because right clicking on the code and selecting "Go to definition" from the pop-up menu is so difficult and takes so long to do.

You don't need to know the ranges to know if your code will work. By creating a range tester, you can test that code once, and use it everywhere. You seem to be advocating recreating a range test everywhere you need it, adding to the complexity of your code, making it harder to read and maintain.

Re:Wow, that's a big fat ASS^H^HPI

[iluvcapra]

Monorails are efficient and sparkly shiny but are almost universally inappropriate except for certain very limited transportation scenarios (airport people-movers, theme parks, etc). They require alot of service and very expensive infrastructure. The old honda just needs a road, works on your schedule and is comparatively inexpensive to maintain on a per capita basis.

Just sayin.

Re:Wow, that's a big fat ASS^H^HPI

[MrSteveSD]

So instead of being able to see both the variable AND the range it is being tested against IN THE SAME LINE, I now have to go trawling back through the code looking for the place where you created the Range object to find the low and high boundaries of it.

You seem to be assuming that there would be a hard coded range. The allowable range may be defined in a database or elsewhere. Checking against the same range may occur in many different places, so you certainly would not want to have the range hard-coded in every routine you need to do such checking.

Imagine that the Date range object was intended to check the date of birth of new employees (e.g. You want prevent mistakes like they were born 200 years ago or 50 years in the future). If you are smart you will have created some kind of Employee class, and this Date Range checking object could just be a static variable of the class itself. It would be pretty easy to see where it was set.

So yet more jumping all over the place hunting for stuff, when the original version was completely fit for purpose, clear, and most importantly, IN ONE BLOODY PLACE.

The whole point is to reduce the unnecessary repetition of logic. Imagine if you wanted to do something more complex like check if one date range was contained within another. Suddenly you start repeating quite a lot of logic without a Range object.

Of course, it get's even "better" ... not all range checking will use the same ranges ... so then some bright spark will create Range2, Range3, Range4 objects with different ranges in each one.

Of course there will be different ranges. What does that have to do with anything? If anyone names variables "Range1, Range2" etc, they need some quick re-education.

You see how this function does nothing for either readability or speed of debugging, but simply hides information that a programmer NEEDS to know in the context of the line he is looking at ?

It's interesting that you think information is being hidden. This would only be the case if you compare it to the situation of hard coding things everywhere, which is generally a very bad practice. The information in a Range object is no more hidden that the case where your limits are two separate variables called "StartDate" and "EndDate" (Variables which might be initialized when the application first starts). What is really being hidden is logic. That's what object oriented programming is really all about, i.e. trying to abstract away complexity into new types.

You can keep your Range object thanks.

It's not really mine. Martin Fowler wrote about it in Analysis Patterns, although I'm quite sure it was being used long before it occurred to him.

Re:Wow, that's a big fat ASS^H^HPI

[Anonymous Coward]

> so then some bright spark will create Range2, Range3, Range4 objects with different ranges in each one...

Not really.

allowedRange = new Range(startDate, endDate);
...
if (allowedRange.Contains(enteredDate)) // blah blah

Simple enough to follow. Much nicer than stuff like the gp's first example.

Re:Wow, that's a big fat ASS^H^HPI

[daveime]

Yes, I mean don't get me wrong, there are a lot of useful types out there.

The danger is "type overload", the obsession with using types for every sundry purpose, i.e. the same logic the parent displayed when automatically thinking that using the Range type was helping him or anyone else.

Anything that abstracts out the conditional tests you are doing, so that one or even both halves of the tests have to be looked up elsewhere, is a bad thing. But you give someone too many types to play with, and he'll feel obliged to use them whenever the can.

Give a man a hammer, and watch him build. Give a man 100 hammers, and watch him hit himself on the thumb.

Re:Wow, that's a big fat ASS^H^HPI

[MrSteveSD]

I do agree that over abstraction can be a hindrance to code maintainability and efficiency

I'm not sure I've seen many cases of "over abstraction". Can you think of a good example you have seen? Normally what I see is under-abstraction. People repeating the same logic again and again all over the place and failing to see that it can be abstracted away.

Re:Wow, that's a big fat ASS^H^HPI

[daveime]

allowedRange = new Range(startDate, endDate);
if (allowedRange.Contains(enteredDate)) // blah blah

So that's not abstracted at all ... you have merely created an unneccessary object for use in this one situation and forced the inclusion of whatever type library the Range object belongs to, resulting in bloated code.

Youe implication is that your range is created solely for the purpose of making the test in the following line ... ergo that makes it redundant, as it's not reusable in that situation, it has been created solely for that one purpose.

So how is creating a Range object any better than using >= and <= in that situation ?

Re:Wow, that's a big fat ASS^H^HPI

[ozmanjusri]

Yeah, let's compare .Net to PHP.

Why?

They're not remotely similar, or did you just want to pick the low-hanging fruit?

Re:Wow, that's a big fat ASS^H^HPI

[daveime]

And if, when I'm later looking at your source in notepad, vi or whatever, the only way I can understand all your abstracted pieces is by hunting them down one by one.

You make the assumption that source for a specific language should only ever be developed / later viewed using some fancy IDE that came bundled with the language.

As someone who regularly has to go in and fix other peoples code, armed with nothing more than a simple text editor, I can't afford to install a 2GB IDE with all the fancy whizzbangs and whatnots that would allow me to right click and view from a menu what should have been in clear view all the time.

Re:Wow, that's a big fat ASS^H^HPI

[Gutboy]

I love the term 'bloated code'. C# doesn't include stuff that isn't used, unlike some other languages. The only code from the library that would be included is the Range object.

As for how it's simpler, it's easier to read, and less prone to errors. And, as the original poster said, he's not talking about one time use, he's talking about multiple uses. So your strawman argument doesn't hold water.

Re:Wow, that's a big fat ASS^H^HPI

[Anpheus]

Whew! I thought you were going to say "well," but you cleared that up!

Re:Wow, that's a big fat ASS^H^HPI

[Anonymous Coward]

> forced the inclusion of whatever type library the Range object belongs to, resulting in bloated code.

Why would you need to base it on anything? All you'd need to do is create a simple class.

> Youe implication is that your range is created solely for the purpose of making the test in the following line ... ergo that makes it redundant, as it's not reusable in that situation, it has been created solely for that one purpose.
> So how is creating a Range object any better than using >= and = in that situation ?

If you're only doing that test in a few places, you're right. It probably is a waste. But if you're testing against that range in many different locations, then that might be another matter. Or not. It's just a trivial example. My point was more that wrapping it in a new type doesn't necessarily make the code harder to follow.

Re:Wow, that's a big fat ASS^H^HPI

[daveime]

How about any of these ... all spawned into existence by giving a novice too many tools to play with :-(

http://thedailywtf.com/Articles/The-Enterprisey-Null-Test.aspx
http://thedailywtf.com/Articles/His-Own-Way-to-Newline.aspx
http://thedailywtf.com/Articles/OurBoolean.aspx

I could go on ...

Re:Wow, that's a big fat ASS^H^HPI

[Azh Nazg]

So, rather than a fairly simple, clean bit of code, you have decided to create a brand new object and some logic for it. . . You know, this abstraction seems purely insane. You are turning a simple if statement into (psuedocode follows):

Object Range {
int startrange, endrange;

Contains(int num)
{
return ((num >= startrange) && (num <=endrange));
}
}
Range AllowedRange = (Range){startrange = foo, endrange = bar};
if(AllowedRange.Contains(EnteredDate)) ... ;

This is just great if you're paid by the line, but if you actually like programmers being able to read your code, then I'd recommend against it. Really, reading that feels almost like reading COBOL. Also, I'd recommend against this behavior if you actually want a sane, small binary, and sane, small memory usage. Excessive usage of objects where it's neither needed nor helpful is nothing but a waste.

Really, your example was exactly what insane usage of object-orientation is: pointless, meaningless abstraction, obsessive bloat, and just an insanely high level of complexity for what should be a single line of code. I'd hate to have to maintain your code. . .

Re:Wow, that's a big fat ASS^H^HPI

[Gutboy]

Why wouldn't you use the tool that makes your life easier? A free tool, at that. And it installs easily on a thumb drive, but I suppose that would be too heavy for you to carry around.

As for hunting them down one by one, I assume you've memorized all the libraries, functions and options in your language of choice, so you never have to refer to documentation.

Re:Wow, that's a big fat ASS^H^HPI

[Mad Merlin]

And a stripped-down non-existent API is a way to make things simple?

No, quality != quantity, let's compare the C++ STL to the standard Java libraries. The STL is quite succinct, the standard Java libraries are outrageously bloated. Arguably, the standard Java libraries can do more, but god forbid if you ever actually want to use part of it that you're not already familiar with, as there'll be at least half a dozen slightly different ways to do what you want to do, 90% of which are obtuse and half of which are deprecated. In the time you spent searching for something suitable to use in the standard Java libraries, you could have written the same functionality yourself twice, taken a nap, gone grocery shopping and played 36 holes of golf. To add fuel to the fire, because the standard Java libraries are so bloated, it's not even feasible to actually know more than perhaps 5-10% of them, at most. In sharp contrast, the STL can be learned in it's entirety within a few hours.

The STL has the map container, the standard Java libraries have approximately a dozen map implementations, each of which is subtly different, but in ways that don't matter 95% of the time. Of course, for the other 5% of the time when you find out that you've picked the wrong map implementation, %s/Hashtable/HashMap/g will probably break things anyways, despite the fact that they're essentially the same.

The STL has the pair container, the standard Java libraries (as far as I can tell) do not have a pair implementation. How they managed to write approximately a trillion and one standard classes without thinking "Hey, a pair class could be useful!" is beyond me.

The STL has the list container, the standard Java libraries have at least a dozen different lists that can't easily be converted between one another, and classes will randomly only use a small (and inconsistent) subset of these lists.

Why should a programmer have to re-write common routines and data structures for every program?

They shouldn't, they also shouldn't spend more time scouring through documentation than coding.

Re:Wow, that's a big fat ASS^H^HPI

[daveime]

Really, your example was exactly what insane usage of object-orientation is: pointless, meaningless abstraction, obsessive bloat, and just an insanely high level of complexity for what should be a single line of code. I'd hate to have to maintain your code. . .

Amen to that, good to know I'm not the only one who thinks like this.

Let me guess, you ALSO have to maintain code that other people have written ;-)

Re:Wow, that's a big fat ASS^H^HPI

[tjstork]

So that's not abstracted at all ... you have merely created an unneccessary object for use in this one situation

It's also not clear what the range means. Is it inclusive of the end datetime, or exclusive?

Re:Wow, that's a big fat ASS^H^HPI

[Azh Nazg]

Nope, just a high school student with a mind for sanity in code (most of the time). ;)

Re:Wow, that's a big fat ASS^H^HPI

[Siberwulf]

My two bits:

With .NET 3.0/3.5, you can create something called an extension method.  This would probably be better than creating a range class, or even the inline code the grandparent of this used... Lets look!

public static class DateExtensions
{
     public static bool IsBetween(this DateTime tested, DateTime start, DateTime end)
     {
          return (tested >= start && tested <= end);
     }
}

That leads to a great implementation that doesn't hide any variables or values and still allows for easy readability

DateTime Signup = (Fetch some value here);

if(Signup.IsBetween(DateTime.Now.AddDays(-1), DateTime.Now)))
.......

You get the jist... I know thats picky, but you don't have to give up anything these days, if you try hard enough.

Re:Wow, that's a big fat ASS^H^HPI

[daveime]

Why wouldn't you use the tool that makes your life easier? A free tool, at that. And it installs easily on a thumb drive, but I suppose that would be too heavy for you to carry around.

Yes, because having a magic bag 'o tricks with a dozen or more thumbdrives for all the different languages I am forced to work on is so much more convenient that notepad.

Last time I checked, the .NET installation set was 7 CD's ... not sure if that includes all the MSDN docs also or not.

As for hunting them down one by one, I assume you've memorized all the libraries, functions and options in your language of choice, so you never have to refer to documentation.

Funniliy enough not very often, as I tend to use languages that have perhaps 10 or 12 types rather than 35,000.

In any case, by your logic, as well as having to lookup the documentation for an unknown function or library call, you will "help" me by turning even the simplest IF statement into yet another function.

In the real world, debugging some dodgy perl will usually take me 10 minutes ... debugging some dodgy .NET will never take less than 2 hours.

Of course, while you are whacking out bloat and presumably getting paid a fortune for using all those types your company invested in, I'm the poor sod who'll have to come back in 5 years and try to work out what is wrong with it.

Re:Wow, that's a big fat ASS^H^HPI

[TheLink]

How about when people in effect write Lisp-like interpreters in Java, and then proceed to write Lisp-like programs in XML configuration files?

I'm kidding. Kind of I think :).

Re:Wow, that's a big fat ASS^H^HPI

[raddan]

Fortunately for us, making a thing simpler than "as simple as possible" is actually impossible ;^)

Re:Wow, that's a big fat ASS^H^HPI

[grumbel]

The idea behind the Range object is the right one, when there is a common task the language should support it. For example having to type:

for(int i = 0; i < length; ++i)
    do_stuff(arr[i])

in C is pretty annoying, because it simply expresses:

foreach(v in arr)
    do_stuff(v)

in a complicated way. Where the Range object however fails is in syntax, the abstracted concept of a Range should make the task easier, but in the given case it makes it harder. Instead of checking a value against a Range, you are forced to take care of allocating a Range object first. Introducing another point of failure where there wasn't one before. In Ruby the problem is solved better, since a Range object has syntax support, so you write

if (startDate..endDate).includes?(entered_date) then

Another alternative that might be nice would be:

if (startDate <= enteredDate <= endDate)

but that of course clashes with the normal use of the "=" operator and also has the disadvantage that you no longer have an obvious way to store a Range object in a varibale.

Anyway, the idea to simplify common task itself is a good one, because it allows to remove possible points of failure, i.e. in the simple version:

if (EnteredDate >= StartDate) and (EnteredDate <= EndDate)

you have to type EnteredDate twice, not a big thing, but a little annoying and also a possible cause of failure that would be preferable to avoid if possible.

Re:Wow, that's a big fat ASS^H^HPI

[AKAImBatman]

Have a chip on your shoulder much? Most of what you're saying is simply incorrect. e.g. Java does not have half-a-dozen containers. Yes, the switch from the STL-inspired Vector to the more Java-ish ArrayList was annoying. Same with HashTable to HashMap. But beyond that, all those different containers you think you see are actually interfaces for wiring up complex functionality. Either that or completely different data structures with different performance characteristics. (Remember your CompSci courses?) The Java Collections package (which seems to be the only thing in Java you're remotely familiar with) provides enough functionality to write a complete database engine. Which, as a matter of fact, has been done quite a few times. (Sorry, ran out of words to link. Doh! Still more. Ah, to hell with it.)

The rest of the Java API is also not bloat. There are libraries for printing, crytography, sound, graphics, DOM, file I/O, text parsing, text formatting, text display, mathematics, directory interfaces (e.g. LDAP), distributed object systems, reflection, security, SQL database interface, logging, cross-platform preferences, regular expressions, ZIP/GZip support, accessibility, networking, the compiler, scripting engines, etc., etc., etc. Very little of the core API is redundant, with most of the (few!) redundancies being a result of the early days of Java before they moved away from the C++ style objects.

Nearly all of the post-1.0 APIs were done correctly the first time. Which means that the core Java API is actually quite slim for the amount of functionality it provides. And even then, there is a HUGE number of official expansion APIs for mail, multimedia codecs, network request/response handlers (e.g. servlets), 3D graphics, 3D sound, text-to-speech, speech recognition, telephony, SOAP, REST, USB, Bluetooth, scientific units, cross-platform desktop integration, Instant Messaging, P2P, and quite a bit more. And that's just the official JSR-approved expansions! The OSS and (bleh) commercial worlds are full of unofficial libraries to deal with nearly any problem you can come up with.

If you want bloat, stop looking at Java. Try compiling a few Linux apps sometime and tell me how many redundant libraries you come across. If you know what they all do (which is a miracle in of itself), compiling just ONE of those programs is enough to make a person blush with embarrassment. Not to mention that when a platform IS solidified (e.g. GNOME), it suffers from versionitis. (i.e. The constant need to upgrade your version of the libraries because this latest program no longer targets the version you just compiled. Or even worse, it requires a specific minor release, thus requiring you to have multiple minor releases of the library compiled and installed.) I won't even go into Microsoft's practice of inventing a new API for the same technology over, and over, and over again. (ODBC, DAO, ADO, JET, anyone?)

Now I happen to think that a lot of the choice that Linux offers is good. But don't point fingers at other platforms when there are more than enough examples of far worse situations close to home.

Re:Wow, that's a big fat ASS^H^HPI

[Gutboy]

dozen or more thumbdrives for all the different languages I am forced to work on is so much more convenient that notepad

And how do you compile after you find the bugs?

debugging some dodgy .NET will never take less than 2 hours.

Your poor debuging skills are not a reason to not use a language.

Of course, while you are whacking out bloat

What bloat? C# (and other .NET languages) have very good compilers.

I'm the poor sod who'll have to come back in 5 years and try to work out what is wrong with it.

Yeah, because all software is bug free, except that written in .NET.

Re:Wow, that's a big fat ASS^H^HPI

[Moridineas]

Well, I can't directly comment as my knowledge of .net is minimal. However, I would just like to add that you ARE missing one point of the abstraction here--that is, you easily and clearly centralize what the ranges are (by defining the range in one place).

Of course this is possible in every type of language, be it as a variable, constant, enum, #define, whatever (anything BUT a literal!).

is

if(event >= EVENT1_START_DATE && event <= EVENT1_END_DATE)

really that much better?

Of course, when you do this, you have exactly the same issue when you say

"So instead of being able to see both the variable AND the range it is being tested against IN THE SAME LINE, I now have to go trawling back through the code looking for the place where you created the Range object to find the low and high boundaries of it." You're not really advocating littering your source code with lots of random magic numbers, are you?

Re:Wow, that's a big fat ASS^H^HPI

[Anonymous Coward]

In fact, in most cases, in Visual Studio, you can right click a variable and have it take you to its point of declaration. Whee!

Re:Wow, that's a big fat ASS^H^HPI

[Anonymous Coward]

(Disclaimer: I've never been into the "everything is an object" hype, and I occasionally pepper OO code with procedural stuff. I know nothing about design patterns except that I don't want to know about them.)

What's wrong with creating a ("static") function that takes a start date, end date and the allowed range (as two separate dates)? It's probably fundamentally the same as your approach except with a procedural twist, but you don't have to create an "AllowRanged" object which is merely an instance of something like "DateRange"...

Usually my assessment of whether to create new types/objects/functions is a balancing exercise between these two factors: how much code and (more importantly) logic duplication do I avoid, and how many more places do I have to look to maintain the code?

That means, I usually tear down classes which do nothing substantial and are no more than trivial wrappers.

Re:Wow, that's a big fat ASS^H^HPI

[Anonymous Coward]

.Net has a very extensive API. PHP also has a very extensive framework Having some thousands of functions in the global namespace doesn't mean it has a very extensible framework.

Since PHP seems to use simple functions and primitive types for almost everything, and the number of such functions are in the order of thousands (only! ;-p), 39,509 types in .NET probably beats it by a huge margin...

I don't see the point of making the comparison though :-/ The funny sibling comment might be the more appropriate response ;-p

Re:Wow, that's a big fat ASS^H^HPI

[Moridineas]

So how is creating a Range object any better than using >= and

I still don't get it--are you REALLY saying that people should be hardcoding constants scattered throughout source files?

Re:Wow, that's a big fat ASS^H^HPI

[TLLOTS]

Just a small correction. PHP will actually get namespaces in 5.3 which is due out soon-ish I believe.

Re:Wow, that's a big fat ASS^H^HPI

[sapphire wyvern]

Monorails?

Is that a port of a Ruby web application framework to an open-source reimplementation of a (possibly patent-encumbered) proprietary common language runtime?

No wonder it sucks compared to a Honda! ;)

Re:Wow, that's a big fat ASS^H^HPI

[91degrees]

There's something to be said for a "InRange(x, min, max)" function. If rather than date you have a more complex construct that's calculated. Say "Date_of_birth+age_in_martian_years*earth_year_length/Mars_year_length". It's easier if you only have to type that once. Of course an InRange is quite a low level function and would make sense in a ranges library. It probably doesn't belong in a higher level library, especially if that means reimplementing it several times.

Re:Wow, that's a big fat ASS^H^HPI

[Anonymous Coward]

Having a pile of stuff avaialable is not complexity.
Having a pile of stuff, trying to use one class and finding that it drags four other classes along with it, etc; that would be unnecessary complexity.

However, having done a fair amount of .net coding, that is not the case. The namespaces are quite well partitioned. If you want to do something simple, you can just use the simple tools. If you want to do integration work, the tools are there, in one or other of those namespaces.

Re:Wow, that's a big fat ASS^H^HPI

[CastrTroy]

And when will it get an API organized using those namespaces.

Re:Wow, that's a big fat ASS^H^HPI

[StrawberryFrog]

So instead of being able to see both the variable AND the range it is being tested against IN THE SAME LINE, I now have to go trawling back through the code looking for the place where you created the Range object to find the low and high boundaries of it.

By this logic, date objects are a bad idea, since instead of being able to see the day, month and year in the same line, now have to go trawling back through the code looking for the place where you created the date object. Absurd.

Abstraction is good, repetitive code is bad, you are wrong.

PS: Hover your mouse over a Date object. Or inspect it in the debugger. You get a String repeentation of it from the ToString() method showing the day, month and year.
You can *gasp* overide ToString() in your own classes, and you know, show the details of the range without any trawling.

Re:Wow, that's a big fat ASS^H^HPI

[StrawberryFrog]

Monorails?

Is that a port of a Ruby web application framework to an open-source reimplementation of a (possibly patent-encumbered) proprietary common language runtime?

Yes, but that's a rather negative way of looking at it'

What, you thought you were joking?

Re:Wow, that's a big fat ASS^H^HPI

[Siberwulf]

If we're still assuming .NET here... No those aren't the same. For simple read-only iteration of list/arry it's lovely. If you want to say, remove an item from an enumerated collection, you're going to blow up using a for-each statement. You can't modify a collection while iterating through it in that fashion, and a good ol' for loop is what you have to use.

Re:Wow, that's a big fat ASS^H^HPI

[daveime]

You're not really advocating littering your source code with lots of random magic numbers, are you?

They are called literals. (I know you OO guys were never taught about them, nothing to be scared of though).

You know there's many articles on DailyWTF that describe so called programmers who want to express every statement as a function, who want every literal value to be a constant etc ... how long before we see some of your code on there I wonder ?

So a literal "2008-03-13" within a conditional test is a random magic number ?

And should be a constant described in some header / include file hidden away somewhere ?

That's great until someone decides that in 1 script out of 1000 we should use a DIFFERENT value.

Or worse still until some asshat decides to play with the constants file, and brings down not just 1 script but all 1000 at the same time :-(

I suppose with that logic we'd better make constants out of booleans too ?

CONST MYBOOLEANTRUE = true;
CONST MYBOOLEANFALSE = false;

... and let's not forget the integers ...

CONST MYONE = 1;
CONST MYTWO = 2;
CONST MYTHREE = 3;

... and then we don't have messy "random magic numbers" messing up our "clean code"

if (Result == MYBOOLEANTRUE) {
do something

(Oh, wait, that one's already been on DailyWTF) ... you see what I mean ?

Bloody nonsense ... now repeat after me ...
A LITERAL IS NOT AUTOMATICALLY A CONSTANT
A LITERAL IS NOT AUTOMATICALLY A CONSTANT
100 times please.

Re:Wow, that's a big fat ASS^H^HPI

[Anonymous Coward]

now that's some serious linkage! >grin

just how many mugs of java was that?

Re:Wow, that's a big fat ASS^H^HPI

[Anonymous Coward]

No comparison; productivity using .NET is massivly higher then any flavor of JAVA or LAMP. End2End Integration, Visual Studio, Well thought out frameworks, and massive support by companies that have a financial stake in the products...

Re:Wow, that's a big fat ASS^H^HPI

[mweather]

I can only choose to not use them if I'm the sole maintainer of the code I'm working on. If someone else wrote some or all of it, which is the case 99% of the time, I'm SOL.

Re:Wow, that's a big fat ASS^H^HPI

[Moridineas]

They are called literals. (I know you OO guys were never taught about them, nothing to be scared of though). Thanks for the poorly attempted ad hominem--I mostly program in C (or scripting languages, but that's another story). You also seem to have misread my post, as I mentioned literals. Thanks though, you really brought the conversation to a new level.

You know there's many articles on DailyWTF that describe so called programmers who want to express every statement as a function There's actually a school of programming thought--taught in some colleges even zomg!--that any group of say 10 lines or more should be its own function. No something I agree with, but it's out there. Thanks for the attempted ad hominem again. I hope you didn't take my original message the wrong way--it was not a personal attack on you, and I don't think you should take disagreement over programming style so personally (jmho though)

So a literal "2008-03-13" within a conditional test is a random magic number ? Sure, I have no idea what 2008-08-13 is from your post, not a clue. I don't know what the event is, and most importantly, is this an event that changes? Is my program going to be checking 2008-08-13 for the next 10 years? How many other places in my code is this same date listed? If I need to change it, how many places am I going to have to search? What if one of them has a typo and I miss changing it in a future revision. Those are serious, and real issues with scattering literals throughout code. If it TRULY is a one time date and this is truly the only check for it in the program and it's not going to change, ever--of course there's no problem with putting it right in the code. Those assumptions need to be checked though!

I suppose with that logic we'd better make constants out of booleans too ? Ok, explain the allegedly "logical" steps you used to get here?

A LITERAL IS NOT AUTOMATICALLY A CONSTANT How is this relevant to the discussion at hand?

Look, it basically boils down to this--the method of programming that you seem to like, is absolutely great for small projects and personal hobby programs. Heck, it's common even in bigger ones. It becomes totally unmanageable though. Look at, for instance, the FreeBSD source code. I did a quick look in /usr/src/sys/kern. By your standards the FreeBSD kernel hackers are the equivalent of dailywtf jerks because they use define statements and macros to both INCREASE readability and IMPROVE maintainability. I really am not sure why you are arguing so hard against this? Of all the points from my original post, you picked a very odd one (and one which has nothing to do with OOP/functional/procedural/whatever language choice) to argue!

Re:Wow, that's a big fat ASS^H^HPI

[Scaba]

Yes, because having a magic bag 'o tricks with a dozen or more thumbdrives for all the different languages I am forced to work on is so much more convenient that notepad.

No line numbering, no syntax highlighting, no ability to compile or even check the syntax of your code from the editor. Sounds like you've never really done any significant software development, else you'd realize just how unproductive doing all but the smallest and most trivial scripts in Notepad really is.

Last time I checked, the .NET installation set was 7 CD's ... not sure if that includes all the MSDN docs also or not.

So? You only install it once.

In any case, by your logic, as well as having to lookup the documentation for an unknown function or library call, you will "help" me by turning even the simplest IF statement into yet another function.

No, that was your logic. Don't be disingenuous.

Funniliy enough not very often, as I tend to use languages that have perhaps 10 or 12 types rather than 35,000.

Sounds like you re-invent the wheel a lot with those languages. Why not skip even the abstractions they offer and go straight to assembly? Oh, because you've never had deadlines, because you've never developed in the real world.

In the real world, debugging some dodgy perl will usually take me 10 minutes ... debugging some dodgy .NET will never take less than 2 hours.

In the real world, all Perl is dodgy.

Of course, while you are whacking out bloat and presumably getting paid a fortune for using all those types your company invested in, I'm the poor sod who'll have to come back in 5 years and try to work out what is wrong with it.

Now I know you've never done any significant development work, because you used the word "bloat" in relation to software, which is a word only angry young basement dwellers in their anti-MS phase use. And if you were a better developer, you wouldn't be stuck always fixing someone else's code - you'd be the guy developing the stuff in the first place.

Re:Wow, that's a big fat ASS^H^HPI

[WNight]

2008-03-13 is indeed a magic number.

Instead of:

if date > "2008...."

write:

GoLiveDate = "2008..."
if date > GoLiveDate

Then it's self-documenting AND you can use it elsewhere. Also, if you delay shipping you merely change the date in one place.

Similarly, if you write:

if ((a == b) == true) ...

or:

if ((a == b) == MyBooleanTrue) ...

that's redundant (and more redundant).

But if you write:

ExpectedResult = true // library in dev, this may change
if (a == ExpectedResult) ...

it's a good thing.

Variable and constant names are your first line of documentation. A date (2008...) looks much like any other. GoLiveDate does not look like Christmas, even if they are on the same day.

Re:Wow, that's a big fat ASS^H^HPI

[Anonymous Coward]

You can keep your Range object thanks.

Software isn't really your strong suit, is it?

Re:Wow, that's a big fat ASS^H^HPI

[$1uck]

Why is parent modded insightful?

I fail to see how
            if(startDate enteredDate && enteredDate endDate){...}
Is any more readable than
            if(AllowedRange.contains(enteredDate){...}

If you rewrite both using Domain specific variable names that have some meaning like:
            if(birthDate enteredDate && deathDate endDate){...}
            if(LifeTime.contains(enteredDate){...}

I think the second one is much more readable.

Re:Wow, that's a big fat ASS^H^HPI

[slapout]

"They're not remotely similar"

They are both used to serve web pages. That is probably what they were referring to.

Re:Wow, that's a big fat ASS^H^HPI

[hesaigo999ca]

I have to agree with you, I have worked for many companies that have had in house built apps, that wasted a lot of time and their money into, and when approached about simply replacing the defective code with new apps etc...their stand was, well we already invested into this, so we are stuck now. You are never stuck...if this was the case we would all still be using assembler. At some point someone sees the advantage of upgrading to a new language or a new way of doing things...and then the reward is later with fewer lines of code to maintain and less man power to do it.

I will also not name names, but this particular company in charge of massive amounts of personal data in the french speaking Canadian section... were very vulnerable to attack, and a quick redraw using asp.net technology to replace aging less secure asp technology with third party add ons everywhere could not bring themselves to see the light.

Re:Wow, that's a big fat ASS^H^HPI

[gbjbaanb]

Yeah, because right clicking on the code and selecting "Go to definition" from the pop-up menu is so difficult and takes so long to do. No, that's fine and dandy (assuming you are using a bloated IDE to code in), the problem comes when you want to go back where you came from.

Context switching is a bad thing for human brains, we're not good at it and developers who hold a lot of current-contextual data in their heads find having to stop and go look elsewhere ruins the train of concentration required. Once you see that the really good devs don't use tools like that, you'll understand the way they're coding.

Re:Wow, that's a big fat ASS^H^HPI

[MrSteveSD]

I really don't like the idea of slapping methods onto a class using these new Extension Methods, but that is a whole other argument for another day. To me it looks more confusing because people don't expect DateTime to have this new method you have created.

Anyway, the other issue is that whenever you want to check whether a date is within range, you have to pass in both boundary dates. This is unnecessary with a range type. The more you have to type, the more mistakes you are going to make. This whole "hiding variables" argument is spurious because they are only hidden compared to the case of using hard coded values (generally a poor idea). As soon as your boundary dates are variables rather than hard-coded values, there is really no difference between a range class and the separate variables. If you want to know what the range is at runtime, you can just inspect the range class and use Range.StartDate and Range.EndDate.

The other issue, which I didn't talk about before is that identifying the concept of a range leads you in new and interesting directions. For example, you may suddenly realise that aside from a Date Range, a double range or Integer range would be really useful. The code for all these different kinds of range is pretty much the same and it's easy to implement using Generics.

Re:Wow, that's a big fat ASS^H^HPI

[Siberwulf]

I hear what you're saying, but I kinda disagree with the "people don't expect it". For me, and I'm sure a few others...half the joy of coding is finding out new things. "Oh, I didn't know you could do that!"

For me, when you have comparison operators, I like to knwo what its doing, at the comparison line. I don't see it fitting to have to sort through objects to figure out that we're really doing a glorfied "between" check.

On a side note, creating a class that has two properties, and a method for comparison is by most standards "bad design" as all classes should try to achieve a 2:1 ratio of methods to properties. When you are setting more properties than methods, you really just creating a container class with a function.

I took my example from the T-SQL "BETWEEN" word, it makes logical sense and I personally think its more readable that way.

Re:Wow, that's a big fat ASS^H^HPI

[cromar]

There's nothing wrong really with using static methods in OO code... it depends on the situation. An OO range object is nicer in this situation because it's more readable, clearer, and more powerful. On the other hand, there are examples where a static method would be more readable and clearer especially with methods that take no arguments. That's my 2p anyway.

Re:Wow, that's a big fat ASS^H^HPI

[MrSteveSD]

I hear what you're saying, but I kinda disagree with the "people don't expect it". For me, and I'm sure a few others...half the joy of coding is finding out new things. "Oh, I didn't know you could do that!"

I haven't really looked at it a great deal, but it's just one of those features that sets alarms bells ringing in my head.

For me, when you have comparison operators, I like to knwo what its doing, at the comparison line. I don't see it fitting to have to sort through objects to figure out that we're really doing a glorfied "between" check.

I think "Range.IsWithin(EnteredDate)" has a pretty clear meaning. The whole point of object oriented design is to identify concepts and encapsulate logic. Granted, a comparison between a couple of dates is fairly simple logic, but it's still logic than can be very well encapsulated. I mean imagine you had a vector class and you wanted to do a cross product between two instances. You could just do the cross product by accessing properties, then you would be able to see exactly what is happening. But doesn't it make a hell of a lot more sense to have a CrossProduct method that encapsulates that logic? If you wanted to see what was happening in a cross product operation, it would be quite trivial just to take a look inside the method.

On a side note, creating a class that has two properties, and a method for comparison is by most standards "bad design" as all classes should try to achieve a 2:1 ratio of methods to properties. When you are setting more properties than methods, you really just creating a container class with a function.

That's kind of an arbitrary rule, but I'm sure that given a moments thought you will see that there are a whole lot of possible methods for a range class. For example, it might be useful to be able to check whether one range completely contains another "Range.Contains(SomeRange) or whether a range occurs before or after another range "Range.IsBefore(SomeRange)", "Range.IsAfter(SomeRange)". There are all sorts of useful possibilities.

I took my example from the T-SQL "BETWEEN" word, it makes logical sense and I personally think its more readable that way.

Writing a specific check like you have done misses the general concept of a range which of course goes far beyond dates. You should always be trying to identify reusable concepts. For example, imagine that in most of your application you need to be doing certain checks on the strings that users enter. You might generally have to check a few things e.g.

• That the string is not zero length
• That the string is not too long (this will vary of course)
• That the string does not contain certain characters (e.g. question marks etc)

So in in your Employee Class, you could just perform all of these checks in your FirstName property, and your LastName property and in all of the other string properties of dozens of other classes. If you did this you would be repeating lots of the same logic all over the place. An alternative would be to create a general function that can be called from anywhere, and you would have to pass all of the restrictions (lists of allowable characters, min length, Max length etc) as parameters when you call it. So you would have data (the restrictions) and logic (the rules using the restrictions). In the days before object oriented languages, you would probably do something very much like that but in modern object oriented languages doesn't this seem like a good time to consider putting this stuff together in some new class? You could easily create a StringValidator class to help you with all of this. You set it's properties and it does all of the checking logic for you. The FirstName and LastName properties would probably just use the same StringValidator instance, so you have already saved on coding just in one class in your project!

Re:Wow, that's a big fat ASS^H^HPI

[try_anything]

You do have a point about the unnecessary "allowedRange" variable. Some people love the documentation provided by variable names and encourage the creation of extra variables expressly for that purpose. I'm less enthusiastic about that style of programming, and here, I would probably write something like:

if (new Range(startDate, endDate).Contains(enteredDate))

The need for "new" is a language wart here, held over in Java and C# because C/C++ programmers would have a heart attack if you were "hiding" memory allocation. In this case there would be no heap allocation; escape analysis would show that the Range object can be allocated on the stack, and you would be able to compile the code down to exactly the same instructions as the code you described above. (I wasn't a CS major and only took the equivalent of half a traditional undergraduate compilers class, but even by that point we could do this kind of optimization, at least on paper.)

It seems like a small difference, but given enough code, the clarity of Range(startDate, endDate).Contains(enteredDate) becomes a big advantage. The only downside is that you have to remember whether Range represents an open, closed, or half-open interval.

But we shouldn't argue; we should just wait for Fortress. Then we can all write enteredDate [ startDate, endDate ) and everyone will be happy :-) (There's an "element of" symbol between enteredDate and the interval, but I can't see it when I preview... I hope it's just my browser.)

Re:Wow, that's a big fat ASS^H^HPI

[Anonymous Coward]

Indeed. Further, why use a linked list class? Every time you need to manipulate a list, you can just dig through pointers inline! Much clearer.

[/sarcasm]

I actually worked on the expansion set for a fairly popular PC title where this is exactly what the somewhat well-known programmer did.

Re:Wow, that's a big fat ASS^H^HPI

[nmg196]

> I now have to go trawling back through the code looking for the
> place where you created the Range object to find the low and high boundaries of it.

Because right-clicking on "Range" and selecting "go to definition" is just SO HARD.
You've clearly never actually used Visual Studio. You NEVER have to trawl though anything using VS.NET it's all done for you with context menu commands or IntelliSense. If you want to cripple yourself by writing .NET code in some other way, then that's your personal choice.

> IN ONE BLOODY PLACE.

Er, you've just said exactly the opposite of that - that you'd prefer it if it was all over the place rather than in a single function. Make your mind up!

.NET is OOP gone stupid.

[Anonymous Coward]

.NET and Java are both prime examples of object-oriented programming gone stupid. Their class libraries have become so utterly huge that it becomes damn near impossible for an individual developer to suitably grasp anything more than a small portion of them.

Although they supposedly give more flexibility, something as essential as reading from and writing to a file becomes a hassle with .NET or Java. It's easy to get lost in whether we need a FileInputStream, or whether we should wrap a FileInputReader in a TextInputBuffer, and so forth. Give me fopen() any day.

OO was supposed to solve the problems of writing applications in languages like C, Pascal and Fortran. All it has done is brought in a new level of complexity that results in monstrosities like the Java and .NET standard class libraries. Meanwhile, the POSIX API offers just as much flexibility, but is far easier to work with. Not to mention that programs using it are far more efficient.

Re:.NET is OOP gone stupid.

[NewbieProgrammerMan]

Although they supposedly give more flexibility, something as essential as reading from and writing to a file becomes a hassle with .NET or Java. It's easy to get lost in whether we need a FileInputStream, or whether we should wrap a FileInputReader in a TextInputBuffer, and so forth. Give me fopen() any day.

The first time I saw what you (supposedly) have to do to read from a file in Java, it pegged my OMGWTF meter. I'm sure there's totally valid reasons for making such simple (and common) tasks so complicated, but apparently I'm not smart enough to understand them. IMHO it's one thing to have the complexity available if it's needed, but it's another to make me endure all that complexity if I don't need it.

Re:.NET is OOP gone stupid.

[grahamsz]

There are a number of advantages to a comprehensive type library, it does do a decent job of defining interfaces that external libraries can use.

One example I came across recently was that I was able to couple one visualization library (that rendered to an on screen canvas) to a pdf library (that implemented the standard Graphics2D interface). With little more than a few lines of code, the full vector-based visualization appeared in a pdf file. Granted, I'm not a C++ programmer, but I doubt you could have glued together two libraries at that level.

The .Net framework does seem worse than the Java one, if only because it's documentation seems poorer than suns.

Re:.NET is OOP gone stupid.

[free space]

I kinda disagree.
To talk about your example: fopen( ) might be nice and simple, but the capabilities provided by .net and Java are much bigger in scope.

You can use them to read and write files with different encodings, you can treat a lot of other things as files, and combined with formatters you could serialize your data to binary files or XML almost without writing code.

Even more, the different classes are orthogonal, so you can mix and match different encodings, formattings, and file operations without the combinatoric explosion of having a separate function for every possible operation. It's an elegant design in my opinion.

Furthermore, the libraries of Java and .net provide standard interfaces and hooks to link your own code. Want arrays of your new data type to have automatic sorting capabilities? just implement IComparable. A little bit of work would let your new collection class bind automatically to Winforms' data grid control. And many more examples.

If you remove .net's huge libraries, you get a situation like C++ where there are half a dozen pseudo-standard libraries for encryption, networking, GUI and stuff. You have projects with incompatible dependencies and a lot of wasted effort writing, debugging and maintaining all those libraries. Microsoft may have a lot of problems with their products but .net is one of the most well designed things they've produced.

To be fair, .net inherited a lot of this from Java, but they improved on it. Java, in turn, adapted/improved the Smalltalk libraries that have helped pave the way for the "language with everything included" paradigm.

Re:.NET is OOP gone stupid.

[LaskoVortex]

The first time I saw what you (supposedly) have to do to read from a file in Java, it pegged my OMGWTF meter.

The idea is that you could encapsulate all that complexity inside a method inside a class--instantiate that class inside a class that has a "main()" and then put the whole thing in a module. You call all of that method with the correct parameters in an instance of another class created and instantiated the same way. You then jar it up as bytecode and then run it on the JVM--making sure your users are running the right versions of the JVM.

On second thought, OMGWTF?

Re:.NET is OOP gone stupid.

[Watson Ladd]

I just use parametric types. To make a sortable data type I define the type and a comparison, and my sort function uses any comparator passed to it. If I want to sort backwards one time, no problem. I just use lambda to make a quick reversed comparison operator. Want to access a different file encoding? No problem, just supply the functions as an argument. Threadsafe? I have immutable variables, so nothing bad can happen. What language do I use? Standard ML.

Re:.NET is OOP gone stupid.

[cbart387]

... and by the time you're done hope that the sections of API you're using hasn't been deprecated.

Re:.NET is OOP gone stupid.

[Anonymous Coward]

The reason for this complexity is that you can't just open a binary file and read it as text, because in Java, binary data (byte[]) is not text (char[] or String). An InputStreamReader is something that reads raw binary data from an InputStream and converts it into characters that can be read as a string, taking care of all the messy encoding issues (i.e. UTF-8, or ISO-8859-1, or whatever).

The fact that C allows you to just read data into a char[] and call it a string is completely wrong, because you don't know what kind of string you're dealing with.

Re:.NET is OOP gone stupid.

[Anonymous Coward]

IMHO it's one thing to have the complexity available if it's needed, but it's another to make me endure all that complexity if I don't need it.

Well, you don't! Ruby and Python are right here.

Amazingly, every project I've worked on since 2002 has said "we'll write a prototype in (python|ruby), and then rewrite the slow parts in (Java|C)", and every one has just gone and shipped the "prototype".

It's like these system architects don't realize that when your language is only responsible for hooking your GUI toolkit to an RDBMS in a different city, the (Python|Ruby) VM is not going to be your bottleneck.

The complexity of Java (or C, or x86 assembly) is there if we ever need it; I doubt we ever will.

Re:.NET is OOP gone stupid.

[free space]

Yeah. ML and it's descendants are awesome.
Incidently, I thought you were talking about C# 3.0 when I was reading the beginning of your post. In my opinion this is one of the reasons Microsoft has succeeded: They shamelessly steal the best features of other good products.

While Java fan's were complaining that .net "stole" from Java like this was a bad thing, MS was busy ripping off features from functional languages and improving their platform.

Re:.NET is OOP gone stupid.

[Anonymous Coward]

Whatever, moron. Do you actually write real software?? Yes, .NET and Java are big. They are also very comprehensive. To say that POSIX is better because it offers more flexibility is stupid. If you need to write an application that parses some xml, is POSIX going to help you? What if you want to write a web based application? Sure, you could use 3rd party libraries for every specific little niche functionality that you require, but then you'll need to learn the patterns and quirks of each of those libraries, maybe worry about licensing, and probably end up with a less than elegant solution overall.

You go ahead and fopen that xml file and write your super-efficient, super-flexible parser. I'll just use System.Xml and be done in a few minutes instead of a few days.

Re:.NET is OOP gone stupid.

[MrSteveSD]

Their class libraries have become so utterly huge that it becomes damn near impossible for an individual developer to suitably grasp anything more than a small portion of them.

The funny thing is, they (and unfortunately some employers) think it is great to try to learn it all rather than look it up when needed. They call it Microsoft Certification. You can never learn it all in any sufficient depth and even if you could, by the time you did, they would have changed everything anyway.

I think the reason it's so big is because they have tried to address so much. They haven't necessarily done it stupidly, but they have addressed a huge problem domain so there are huge numbers of classes.

Re:.NET is OOP gone stupid.

[Anonymous Coward]

like System.IO.File.ReadAllLines() or
like System.IO.File.ReadAllText() or
like System.IO.File.ReadAllBytes() ?

Re:.NET is OOP gone stupid.

[n dot l]

My experiences with Java were painful, but they are out of date, so I'm only going to talk about .NET, which I actually use in my day-to-day work because it's actually the best tool for many of the jobs I do.

.NET and Java are both prime examples of object-oriented programming gone stupid. Their class libraries have become so utterly huge that it becomes damn near impossible for an individual developer to suitably grasp anything more than a small portion of them. Interestingly enough, an individual developer does not need to grasp anything more than a small portion of them. An individual developer needs to know the basics of the core class library and whatever else he needs to get his job done. The vastness of the ASP.NET (or whatever) libraries is not an impediment to one who does not use them.

Also, there is documentation, and Intellisense (freely available, now), and a naming convention that actually makes sense after a while. F1 isn't that hard to press.

Although they supposedly give more flexibility, something as essential as reading from and writing to a file becomes a hassle with .NET or Java. It's easy to get lost in whether we need a FileInputStream, or whether we should wrap a FileInputReader in a TextInputBuffer, and so forth. Give me fopen() any day Seriously? You actually found string[] lines = File.ReadAllLines( string path ); to be difficult? Or are you just talking out your ass?

Of course, there are more complicated examples, but that's usually because they're either years out of date (.NET 1.0), or just plain doing more.

OO was supposed to solve the problems of writing applications in languages like C, Pascal and Fortran. All it has done is brought in a new level of complexity that results in monstrosities like the Java and .NET standard class libraries. Meanwhile, the POSIX API offers just as much flexibility, but is far easier to work with. Not to mention that programs using it are far more efficient. Yeah? I find typing File[dot] and hunting through the fairly short list of methods easier than remembering what the valid values were for fopen's mode parameter are, and whether there was a platform-specific one I should be using to get the file-locking behavior I want. And file.Read( ... ) is a lot neater than fread( ..., file ). You can go on all you want about how I'm being lazy, but I have more important things to commit to memory than API entry points and the quirks of their parameters (like, say, the overall structure of my app, or the problem it's being written to solve). YMMV, of course.

As for plain C applications being more efficient, well, what exactly does that have to do with what methods are named and what namespaces they do (or do not) reside in? Second, that's not the point. Getting a quick GUI app up and running in a hurry is more what you'd use .NET for, something you can't even begin to do in C until you've sat around for a while thinking about fun things like memory management for shared resources.

Yes, C is valuable and it's still pretty much the best choice for writing tight, high-performance loops that do lots of pointer-manipulating, bit-twiddling evil - that's what I and every other sane programmer I know uses it for. But it's also a damn waste of my time to be using it to write Win32 GUIs for art tools. My time is more valuable than a few CPU cycles.

Re:.NET is OOP gone stupid.

[Dilly Bar]

You may be right, but try another example for .NET. Here are some .NET APIs you can use to read a file:

byte[] File.ReadAllBytes(string path)
string[] File.ReadAllLines(string path)
string FileReadAllText(string path)

and write to one:

File.WriteAllBytes(string path, byte[] bytes)
File.WriteAllLines(string path, string[] contents)
File.WriteAllText(string path, string contents)

Oh, and you can still compose types for more complex scenarios.

Full disclosure - I work for MS on Visual Studio

Re:.NET is OOP gone stupid.

[NewbieProgrammerMan]

Well, you don't! Ruby and Python are right here.

Amazingly, every project I've worked on since 2002 has said "we'll write a prototype in (python|ruby), and then rewrite the slow parts in (Java|C)", and every one has just gone and shipped the "prototype".

It's like these system architects don't realize that when your language is only responsible for hooking your GUI toolkit to an RDBMS in a different city, the (Python|Ruby) VM is not going to be your bottleneck.

The complexity of Java (or C, or x86 assembly) is there if we ever need it; I doubt we ever will. My experience sounds similar to yours, and I generally default to writing most everything in Python and dropping out to C if necessary for optimization. The only drawback so far has been that languages like Ruby and Python make people with pointy hair uncomfortable because they're not backed by a Real Company (TM). YMMV of course; I don't work on enterprisey apps that need all the complexity that the Java/.NET people say is so important, so my approach is probably only appropriate for certain niches.

Re:.NET is OOP gone stupid.

[Jester998]

To talk about your example: fopen( ) might be nice and simple, but the capabilities provided by .net and Java are much bigger in scope.

Yup, I agree -- sometimes encapsulating and abstracting the problem is the right approach. Key word there? Sometimes.

If you have a simple, well defined problem (e.g. 'write these 8 bytes to a file'), a 'nice and simple' solution often does the trick. Less code means less complexity and more clarity. With C++, for example, you could use a simple fopen() -- or you could write an encapsulation class/function. Java (and .NET, I hear, never used it myself) give you no choice but to use the encapsulated methods.

Engineers solve hard problems. Great engineers solve hard problems through simplicity. Always remember Occam's Razor!

Re:.NET is OOP gone stupid.

[Anonymous Coward]

The .NET framework in almost all parts is designed to be a "multi-level API", with simple high-level types built on top of more detailed lower-level API's.

Basically when deciding between flexibility and simplicity the .NET framework choses "both". This increases the apparent complexity of the framework when measured by the number of types and methods, but doesn't make the framework more difficult for the average programmer.

I really appreciate, for instance, having an HTTP library that provides access to protocol details when necessary, and has a super-simple wrapper for common scenarios. By contrast in Java, I often had to use Apache's HTTP library or use raw sockets.

Re:.NET is OOP gone stupid.

[batkiwi]

In .NET:

byte[] fileContents = System.IO.File.ReadAllBytes("myBinary.blah");
string fileText = System.IO.File.ReadAllText("myText.txt");

That's if you want to read it all in as quickly as possible (no buffering). What's tough about that?

Obviously if you need buffering you have to do some REALLY complex work:

while (s.Position < s.Length)
{ //process your stream... read one byte at a time out of it
    int oneLittleByte = s.ReadByte(); //or chunk 50 bytes out of it, don't hardcode like this kids!
    byte[] someBytes = new byte[50];
    int bytesRead = s.Read(someBytes, s.Position, someBytes.Length);
}

That is both tough and complex. I don't know how I can cope.

Re:.NET is OOP gone stupid.

[jesterzog]

Although they supposedly give more flexibility, something as essential as reading from and writing to a file becomes a hassle with .NET or Java. It's easy to get lost in whether we need a FileInputStream, or whether we should wrap a FileInputReader in a TextInputBuffer, and so forth. Give me fopen() any day.

I've been writing code in a Windows shop using .NET for a couple of years now. I like coding in C at times and still do for some things, but when I'm writing .NET apps I don't really have much of an issue with it. That's what documentation is for, and MSDN's pretty good and up to date. Personally I find the following a lot easier to use than something like fopen():

using(Stream fs = new FileStream("somefile.txt")) { // Do stuff... }

It opens the file, lets you do stuff, and makes absolutely sure it's closed when you're finished irrespective of what happens. When I've tried to write something similar in C it's more direct, but there's a lot more need to think about error conditions rather than what I'm actually trying to do.

I agree with you that sometimes it gets a bit confusing discerning between all the different helper and wrapper classes, but I've usually found there are good reasons for them once I get into using them, and it for me it does make it easier to manage all kinds of potential input without having to care too much. Trying to keep track of all the exceptions that might potentially pop up from within all the wrappers is a real pain, though.

Re:.NET is OOP gone stupid.

[free space]

Sometimes a balance has to be striked between "make everything simple" and "application complexity keeps growing".

Many languages start with the goal of making everything simple and keep bolting on features gradually until the language becomes a mess and everyone complains about the inconsistencies and (ironically) excessive complexity. PHP is such an example.

Sometimes it pays to design for complexity up-front. I don't mean anticipating every possible feature and bundling it in (like, say J2EE) but to be ready for things like Unicode, file streams or built in collection classes. Unless your language is very specialized, you'll certainly need these features anyway.

Re:.NET is OOP gone stupid.

[cheeseboy001]

Python does most of that and it's easy.

Re:.NET is OOP gone stupid.

[Breakfast Pants]

So the takeaway from your post is that files are easy to read in .net, as long as you read the entire thing into memory at once? I guess you only ever deal with text files that are a few KB or something.

Re:.NET is OOP gone stupid.

[Oddster]

It is not just the class libraries which are a problem. The idea of using a garbage collected language in a production environment for a large project is just plain silly, for the simple fact that garbage collection does not scale well and it introduces nondeterminism in your code - two things which are fundamentally opposed to the proper operation of a large software system. Not to mention all the bad programming practices it encourages. It's great if you're trying to teach some concepts to students or whip up a small program quickly, but it just plain sucks beyond that.

Seriously, what's wrong with smart pointers? Are the managed-code monkeys really that afraid of how to work with class and function templates? Garbage collection in both Java and C# strikes me more as a feature to keep inexperienced programmers (read: those who don't understand memory management) from hurting themselves, but in any non-trivial software, does a whole lot more harm than good (I'm speaking from significant experience). What we need are better software engineers, not a tool to enable the proliferation of crappy software engineers. Garbage collection is a band-aid solution to the problems that a well written program would not have in the first place.

Re:.NET is OOP gone stupid.

[Breakfast Pants]

One of the primary properties of a file is that you can gradually stream things to/from it. If files become "one shot serialize/deserialize a blob to disk," they quickly become useless in many scenarios.

Re:.NET is OOP gone stupid.

[Mongoose Disciple]

The funny thing is, they (and unfortunately some employers) think it is great to try to learn it all rather than look it up when needed. They call it Microsoft Certification. You can never learn it all in any sufficient depth and even if you could, by the time you did, they would have changed everything anyway.

Honestly, I think 90% of the actual value of a .NET cert is that you're at least exposed to all the major features of the framework. Honestly, you'd never need more than half of them on almost any project.

Sure, you'll forget all the specifics about (for example) the globalization features/classes after you pass the cert test, during the years in which you're writing apps that don't need them -- but when you do have to eventually work on an app that could benefit from those features, at least you'll know that it's out there somewhere for you to look up, and you'll save reinventing the wheel.

The glory of .NET, such as it is, to me, is that I spend much, much less time than with any other language/environment dicking around with plumbing (Struts and half the other things that grew up around Java, I'm looking right at you) or reinventing the wheel, and more time working on the code that's really interesting.

Granted, most of my experience has been working on monolithic business/enterprise apps, so YMMV.

Re:.NET is OOP gone stupid.

[Mongoose Disciple]

So the takeaway from your post is that files are easy to read in .net, as long as you read the entire thing into memory at once? I guess you only ever deal with text files that are a few KB or something.

It's slightly less straightforward in .NET for massive files, but still generally easier and produces much more readable code (to me) than doing it in C/C++/Java.

I worked on a .NET project a little over a year ago that had to routinely process flat files 3-4 gig in size, so I have some idea of what I'm talking about there. Don't even ask me why that company was storing that volume of data in flat files.

Re:.NET is OOP gone stupid.

[Dilly Bar]

You can stream files as well in .NET. I wanted to point out that .NET typically has a level of API that makes simple scenarios easy and more complex scenarios possible (as easy as possible :-)) as in this case.

Re:.NET is OOP gone stupid.

[giminy]

I started as a unix developer and switched recently to programming in windows, and use .NET quite a bit (it was the job that was available at the time ;-)). .NET and Java are both prime examples of object-oriented programming gone stupid. Their class libraries have become so utterly huge that it becomes damn near impossible for an individual developer to suitably grasp anything more than a small portion of them.

Give me fopen() any day.

There are a lot of things that I don't like about .NET (and particularly visual studio :)), but I think these arguments are invalid. fopen() is fine and good, but opening a file is a lot more complicated than just one posix function -- you have race conditions, concurrency issues, etc, if you're working on anything bigger than an academic project. You can develop your own libraries for safely doing things if you want, but going from job to job that becomes difficult legally (who owns the library?). And, of course, using some extra library to wrap your posix is kind of an argument against posix being the be-all-end-all uncomplicated solution.

Programmers often have areas of specialization, and not knowing more than a small portion of a gigantic library isn't necessarily a bad thing. I know the '.NET methodology' (and it is quite consistent) well enough that I could use other parts of the library. Quite frankly for my line of work I don't anticipate ever having to, as it's fairly niche.

Reid

Re:.NET is OOP gone stupid.

[Mongoose Disciple]

The idea of using a garbage collected language in a production environment for a large project is just plain silly, for the simple fact that garbage collection does not scale well and it introduces nondeterminism in your code - two things which are fundamentally opposed to the proper operation of a large software system.

Define does not scale well. I worked on an enterprise .NET project a year or two ago that managed a variety of transactions amounting to millions of dollars worth of business every day for a Fortune 100 company. It required a lot less hardware than you'd guess to run. Garbage collection wasn't a problem at all.

The reality is that for every 100 developers that think they can write non-trivial, say, C++ code that does not leak memory, there's probably around 1-2 that can actually do it. Those people are hard to find and generally not cheap. For most applications, it does not make economic sense to insist on having the "better" software engineers. It's just not cost effective to pay more expensive people to take more time to write the app in the majority of cases where garbage collection vs. manual memory management just doesn't matter.

Further: the union of the set of developers that can reliably write code with good memory management in a language like that, and the set of developers that can make good architecture decisions for an enterprise-level app approaches the empty set. That second set of skills is ultimately much more important to the success or failure of most sizeable applications.

You can hate on GC if you want, but the business world moved on more than a decade ago.

Re:.NET is OOP gone stupid.

[Anonymous Coward]

> Getting a quick GUI app up and running in a hurry is more what you'd use .NET for, something you can't even begin to do in C until you've sat around for a while thinking about fun things like memory management for shared resources.

Did you just compare a language C with a framework .NET?
A quick way to get a GUI up and running in a hurry is to either use GTK+, wxWidget or QT4 for those who want to use c++

Re:.NET is OOP gone stupid.

[ignavus]

"You can use them ..."

No, you *have* to use them, and that is the problem.

"Keep the simple things simple, and make the complex things achievable" is the goal of a good programming language.

Not: "whatever your transport needs, a Boeing 747 is always the answer." Sometimes a pair of roller skates would be more practical.

Re:.NET is OOP gone stupid.

[MrSteveSD]

Honestly, I think 90% of the actual value of a .NET cert is that you're at least exposed to all the major features of the framework.

I've never really been a big fan of trying to learn absolutely everything, especially when the things you are trying to learn are as transient as those of a particular Microsoft technology. If Microsoft kept completely changing physics every few years, I really wouldn't have bothered doing a physics degree. These Certification courses tend to be quite expensive and I know that the companies that do the training promise students (who fork over thousands) the Earth.

Re:.NET is OOP gone stupid.

[Mongoose Disciple]

The .Net framework does seem worse than the Java one, if only because it's documentation seems poorer than suns.

I go back and forth on this.

On one hand, Sun's javadocs for the base Java API are generally superior to MS's for the base .NET API.

On the other hand, a lot of things effectively fall into the .NET framework, that the closest Java equivalent isn't a core Sun creation or generally just isn't documented as well. Something like a Struts or the Struts-successor of your choice, for example. In an awful lot of those cases, the .NET API is a lot better.

So you've got some brilliant and some moderate to terrible on the Java side, whereas on the .NET side you've more got documentation that is consistently good, but not great.

Re:.NET is OOP gone stupid.

[Gutboy]

String text;
using (StreamReader sr = new StreamReader("SomeFile.txt")) {
while ((text = sr.ReadLIne()) != null) {
// do your text stuff here
}
}

Yep, real hard. 2 whole lines to open and read a file.

Re:.NET is OOP gone stupid.

[Mongoose Disciple]

These Certification courses tend to be quite expensive and I know that the companies that do the training promise students (who fork over thousands) the Earth.

Well, that's true. Someone who's working with .NET day to day doesn't really need a course like that, though, in my experience and the experience of developers that I've worked with. A couple $50 books is plenty, and I know people that have done 100% of their studying for cert tests through free online sources.

Re:.NET is OOP gone stupid.

[bar-agent]

You can stream files as well in .NET.

Not as easily as fopen + fscanf in a loop.

Re:.NET is OOP gone stupid.

[bar-agent]

Nitpick: You mean "the intersection of the set of developers that can reliably write code with good memory management in a language like that, and the set of developers that can make good architecture decisions..."

Re:.NET is OOP gone stupid.

[chromatic]

Garbage collection is a band-aid solution to the problems that a well written program would not have in the first place.

Function calls are a band-aid solution to the problems that a well-written program would not have in the first place.

Re:.NET is OOP gone stupid.

[bar-agent]

fopen() is fine and good, but opening a file is a lot more complicated than just one posix function -- you have race conditions, concurrency issues, etc, if you're working on anything bigger than an academic project.

This is true, but .NET I/O libraries don't help with this. They try to help by introducing two kinds of asynchronous I/O, but both kinds are too complex and poorly documented. Does readAll block? I dunno. The asynchronous I/O stuff is a false trail that impedes learning.

Re:.NET is OOP gone stupid.

[lyml]

What exactly is so hard with? File.WriteAllBytes(path, bytes); Do you know the meaning of abstraction?

Re:.NET is OOP gone stupid.

[Anonymous Coward]

Umm; FileStream?

http://msdn2.microsoft.com/en-us/library/system.io.filestream.aspx

It is just as easy (if not easier) as the f* methods of C.

I still prefer Perl though; I have yet to figure out how to open a pipe to stdin or stdout of some other app in another language.

Re:.NET is OOP gone stupid.

[lyml]

Oh really?

string s;
using(StreamReader sr = new StreamReader(path)) {
while((s = sr.ReadLine()) != null) {
//do stuff here
}
}

While I am aware that you probably shave of a couple of bytes using fopen and fscanf the difference is hardly there.

Re:.NET is OOP gone stupid.

[n dot l]

Did you just compare a language C with a framework .NET? I was comparing the programming environment embodied by the language C with that of .NET. I thought the end of my sentence (the one you quoted) made that clear.

A quick way to get a GUI up and running in a hurry is to either use GTK+, wxWidget or QT4 for those who want to use c++ Don't know about QT4, but I've tried working with wxWidgets and GTK+, and it was nothing but pain. I ended up wasting too much time on the following:

• digging into their code to get at unexposed Win32 features (behavior flags on some controls, lack of support for some features introduced in XP, etc)
• chasing down memory leaks and dangling pointers (all sorts of corner cases involving widget ownership and lifetimes)
• writing memory management code for the app's internals
• sitting around waiting around for things to compile (a big C/C++ lib takes longer to link to than a big .NET assembly)

For the stuff I deal with, .NET addresses all of the above. Maybe that's all changed in the last year and a half, I don't know, I honestly haven't looked at them since switching to WinForms. I probably won't bother checking them out again unless our artists start using Linux, which is unlikely in the extreme.

Look, I'm not saying it's the One Solution to Rule Them All or anything, but I find the API to be clean and simple, and for what I do it is ideal.

Re:.NET is OOP gone stupid.

[Gumbytwo]

Their class libraries have become so utterly huge that it becomes damn near impossible for an individual developer to suitably grasp anything more than a small portion of them. Your implicit argument is that the class libraries for a language should be small enough to have "more than a small portion" "grasped" by the average (I assume) "individual developer." This argument is fundamentally flawed for several reasons:

1. You haven't shown that the language(s) in question don't already have core features and APIs that already allow you to develop what you need without using the extended APIs.
2. Your proposition of limiting the size of class libraries is an artificial limitation on the functionality that can be exposed in said libraries.
3. You haven't produced any arguments as to why it is necessary that the class libraries need to be small enough for an individual developer to grasp.
4. No one is forcing you to use the extended APIs (see bullet #1).

One basic reason large class libraries exist is because they make certain tasks much easier to accomplish rather than having thousands of "individual developers" reinvent the wheel. No one expects you to know the whole of the available APIs for a particular enterprise software language. And what about all the third-party libraries? But I'm sure you know a few websites where you can begin your search.

Perhaps more relevantly, in an enterprise software development environment, developers naturally have different areas of familiarity, both within the language's APIs and third-party APIs. On a team of professional programmers you can often find another developer who has worked in a particular area before and may be familiar with APIs that deal with that area.

Anyway, part of being a professional software developer, and just having a lifetime-learning attitude, is not letting your brain and skills grow stale. Rather than complain about the plethora of APIs from which you can freely pick if you so choose, why not celebrate the possibility of letting someone else making your life easier?

Re:.NET is OOP gone stupid.

[Anonymous Coward]

What we need are better software engineers, not a tool to enable the proliferation of crappy software engineers.

Then you don't have a new boss who has a goal on his review that says 65% of his department's development must be done offshore, and an insane set of corporate development standards of process documentation to be met.

I scream on the inside every time he mentions how this software will have to be developed or maintained by this offshore battalion of "green programmers"; meanwhile we have something like 50 business analysts feeding them mountains of specs to produce milligrams of functioning code. Much of what we get back fails outright, some of it seems to work but has significant performance issues, and most of it suffers the worst forms of bad coding skills, like dependencies shooting out like alien tendrils and latching on to everything in sight, monster methods filled with hundreds of lines of code, and pointers statically cast every which way like so many fishing lures stuck in the weeds. Our technical people patch what they can, reject as much of the crap as they can get away with, and pray over what's left.

And he thinks everything is working, because at the end of six months of flailing about the software mostly does perform what he was paid to make it do in front of the users. Not that the bug list is empty, not that there aren't memory leaks, not that we used roughly an order of magnitude more people than we should have, not that what's left over is maintainable, not that it slows down more with every release, but hey, it's "working", so if I tell him the system doesn't work he points at it and says "yes it does!" So far I'm having little luck getting him to consider changing the system.

And by this I'm not trying to say that all overseas programmers are crappy -- they're not. We've had good luck with several, and I would define a couple that we've had as brilliant. But in our crappy environment the smart ones run quickly away to work for other companies. The not-so-good-but-still-smart ones churn out random quality code, but they don't complain, and they keep their jobs. Overall, we've definitely had worse luck than better. Not helping them is our bloated process which doesn't work for sh!t; our code base is getting smellier by the day, and the boss' answer to all these problems is to add more checklists and processes to doublecheck the previous processes are being followed more closely, and to add more green programmers because we all know that's the way to get more stuff done quickly.

Re:.NET is OOP gone stupid.

[ADRA]

Streams are the concept used most often to work with java file I/O. Java didn't invent it, but there is a good rationale for using them. Its a combination of High cohesion, simplification, and efficiency.

Lets say you want to compress, encrypt, then save object data to disk.

ObjectOutputStream crazyFileSaver = new ObjectOutputStream(new ZipOutputStream(new CipherOutputStream(new FileOutputStream(new File("test.txt")),myCipher)));
crazyFileSaver.writeObject(myData);
crazyFileSaver.close();

While this technique may be ugly and most likely, nobody in their right mind would actually write the output stream like demonstrated, it does show the amazing versatility of the API.

Re:.NET is OOP gone stupid.

[bladesjester]

Anyway, part of being a professional software developer, and just having a lifetime-learning attitude, is not letting your brain and skills grow stale. Rather than complain about the plethora of APIs from which you can freely pick if you so choose, why not celebrate the possibility of letting someone else making your life easier?

But that kills their arguments that everything Microsoft does is garbage and not worth looking at.

They have the view of, at best, a first or second year undergrad CS student whose longest project has taken them a day or two tops and never has to be touched again.

Re:.NET is OOP gone stupid.

[TheLink]

Don't forget the XML config file part...

Some XML config files for programs have more lines of code than an equivalent program written in popular higher level languages.

If it's easier to figure out how to modify a server written in Lisp/Python/Perl to do what you want than to modify some fancy config file for a similar server, then something is wrong somewhere.

A sufficiently "advanced" XML config file resembles Lisp after you convert tags to parentheses :).

Re:.NET is OOP gone stupid.

[Anonymous Coward]

The only drawback so far has been that languages like Ruby and Python make people with pointy hair uncomfortable because they're not backed by a Real Company (TM).

What company backs C or C++? Microsoft?

ActiveState, among many other companies, provides commercial Python and Ruby support. And based on my experiences with both, ActiveState provides far better support.

Re:.NET is OOP gone stupid.

[TheLink]

A good design for complexity does NOT require _exposing_ the complexity by default.

In my opinion programming is a form of compression. Decision compression- rather than zillions of if-then-else, you compress that to recursion, functions, classes etc. A good programmer knows which bits to keep uncompressed and which bits to compress so that the overall behaviour is easy to change when the Boss wants it changed AND more importantly so that compressed result is compatible with other decent programmers.

A good programming language has good defaults in its "huffman codebook" for the expected problem domains, to make it easier for the programmer to achieve good compression with less "human CPU" time :).

IMO, saying there is one perfect language is like saying there is one perfect compression algorithm.

But a programming language that has "poor compression" (need to write a lot) or "very high brain power or memory requirements" (need to think/remember a lot for stuff trivial in other languages) is crap, unless it has redeeming features like extremely high runtime performance.

Re:.NET is OOP gone stupid.

[sydneyfong]

Even more, the different classes are orthogonal, so you can mix and match different encodings, formattings, and file operations without the combinatoric explosion of having a separate function for every possible operation. It's an elegant design in my opinion. The problem is that instead of having a separate function for every possible operation, you have separate classes for every possible operation....

OOP is just convenient syntactic sugar. I'm not against it, but going all the way OO introduces problems as the old ones are seemingly solved.

To say a bit more on the matter. I do agree there is a rationale for the Java way of reading files, and in some sense it's superior and provides greater flexibility. But sometimes you just don't need that flexibility and just want to read a damn string from the file... why couldn't there be a "read everything from file into string" method? Admittedly such things are normally not commonly used in large "corporate" projects, but given the huge size of the standard library might as well add that too.

Re:.NET is OOP gone stupid.

[NewbieProgrammerMan]

The only drawback so far has been that languages like Ruby and Python make people with pointy hair uncomfortable because they're not backed by a Real Company (TM).

What company backs C or C++? Microsoft?
ActiveState, among many other companies, provides commercial Python and Ruby support. And based on my experiences with both, ActiveState provides far better support. Please note the "pointy hair" reference; I'm not saying that such an argument has any merit, just that it's an argument that gets made. :)

Re:.NET is OOP gone stupid.

[trezor]

You expect PHP programmers of all people to understand the benefits of a thorough and consistent API with standarized interfaces and object-nesting?

Good luck with that.

Re:.NET is OOP gone stupid.

[chthon]

For Perl, Python and Tcl, you can go to ActiveState.

Re:.NET is OOP gone stupid.

[lahi]

And of course the uglyness is all in the syntax:

echo $myData|zip|encrypt >test.txt ... but perhaps that was your point?

-Lasse

Re:.NET is OOP gone stupid.

[Mongoose Disciple]

You're correct. It's been too long since college.

Re:.NET is OOP gone stupid.

[Nurgled]

A better analog for C's fopen would probably be System.IO.File.Open. It even has essentially the same signature as fopen, and returns the moral equivalent of a fileno.

Re:.NET is OOP gone stupid.

[Anonymous Coward]

java.io.BufferedReader br = new java.io.BufferedReader(new java.io.FileReader(FILENAME));
while(br.ready()){
      String curLine = br.readLine();
      [YOUR CODE HERE]
}
br.close();

VS

#include ...

      FILE * pFile;
      pFile = fopen ("myfile.txt","r");
      size_t bufferSize = 1024;
      char buffer[bufferSize + 1];
      buffer[bufferSize] = '/0'; // make sure we don't read past the end of our buffer.
      if (pFile!=NULL)
      {
            while((int chunkRead = fread(buffer, 1, bufferSize, pFile)) > 0){
                  buffer[chunkRead] = '/0';
                  std::string someBlob = buffer;
                  [YOUR CODE HERE]
            }
            fclose (pFile);
      }

Yep, fopen is the much simpler paradigm. FYI, you can use a FileReader just like fopen. It's just simpler to embed it in a BufferedReader.

Re:.NET is OOP gone stupid.

[metamatic]

If you think Java's file handling is OMGWTF, try working out the code to generate and parse dates in RFC 2822 format.

Re:.NET is OOP gone stupid.

[DerWulf]

Compared to what? I hope you don't mean C. Like fopen() is all there is to reading a file ...

Re:.NET is OOP gone stupid.

[gbjbaanb]

yes, but that's not quite what we're talking about - you're describing what I'd call a 'module', not an OO framework library. (yeah, I know, hardly any difference).

If you could get text from a file by writing (say)

String file_contents = FileReader.Open("filename.txt");

then we're all be very happy, even if you had 3 methods for reading chunks of the file. That'd be a good library, and everyone would be glad to use it. The trick is, as you said, "little more than a few lines of code".

Re:.NET is OOP gone stupid.

[Laxori666]

I have to say that this looks neater:

with file("SomeFile.txt") as f:
for line in f:
#do stuff here

Conceptually, they are the same. But I don't have to remember any class names or function names or check for any null pointers, fewer parentheses, fewer ugly symbols.

Re:.NET is OOP gone stupid.

[Anonymous Coward]

Like this:

string file_contents = (new StreamReader("filename.txt")).ReadToEnd();

But, don't let the reality stand in the way of your ignorance...

Re:.NET is OOP gone stupid.

[dcam]

Also, there is documentation, and Intellisense (freely available, now), and a naming convention that actually makes sense after a while. F1 isn't that hard to press.

Actually when it comes to Microsoft, it is. I seriously think there is a conspiracy at Microsoft to make help files as useless as possible. Pointers to that theory:
1. multi-gig installs, I know space is cheap these days but still. (Re)installing Visual Studio is rather painful exercise for this reason alone
2. Often you don't end up going to the right place in the help file. I've found googling the specific class or method is generally more accurate
3. Online lookups for everything. Tell me how this is smart. I've installed gigabytes of documentation (see 1), which is largely static, and the first place is checks is online. This ensures several seconds of waiting while it tries to connect and down the documentation. Then there is the wait while it installs it. Then half the time it *doesn't work* and has roll it back (more waiting). I've had VS.Net (2005) lock up for *minutes* after accidentally hitting F1. This is on Core Duo machines with 2Gb of RAM and 10K RPM Raptors with a 2M+ net connection.

Incidentally the look up online meme seems to have been introduced in Office 2003. Stupidity seems to have transferred through.

Re:.NET is OOP gone stupid.

[n dot l]

I seriously think there is a conspiracy at Microsoft to make help files as useless as possible. It works fine for me, my colleagues, and other programmers I know. Maybe the installer got interrupted or something on your machine or your settings are messed up.

1. multi-gig installs, I know space is cheap these days but still. (Re)installing Visual Studio is rather painful exercise for this reason alone Uncheck the stuff you don't need or won't frequently access, like all the bundled MSDN articles, and the samples, and the "enterprise" tools, or whatever. Once you trim the install down to the languages you intend to use and the basic F1 documentation you can trim that down a fair bit.

I've got the VC# and VC++ 2008 Express editions (compilers, headers, static libraries, IDEs and documentation) installed on my system, and they take roughly 900 MB in total. It would probably be around 1GB if I had the Professional edition installed with the x64 stuff, the CRT source, and all the ATL headers (I'd give you the numbers off my 2005 Pro install, but it's bloated because I was lazy and just clicked "install everything" before going out to see a movie).

2. Often you don't end up going to the right place in the help file. I've found googling the specific class or method is generally more accurate I run into this problem very rarely, and almost all of times it happens it's because I hit F1 with my cursor in the middle of some macro/template heavy C/C++ code that the IDE just can't parse. Check that you haven't set the documentation filter (found above at the top of the contents and index tabs) to something that excludes the stuff you're looking for.

3. Online lookups for everything. The first time you hit F1 it asks you if you want it to search online before offline, offline before online, or offline only. The default is online before offline, and that's stupid, I agree. You can change it in Tools|Options. If it still does online searches all the time then make sure your documentation is correctly installed. And maybe check that you don't have the filter set to something silly that excludes whatever you F1'd.

Re:.NET is OOP gone stupid.

[free space]

I like the "Huffman's compression" analogy :)
It is true that languages like Java & C# can have verbose syntax at times, but I think that this verbosity is only skin deep, and that the libraries themselves are well designed. Having to type more!= having a library being inherently bad.

These languages have an "everything should be in a class" mentality to them and got to avoid things like plain functions and closures and that makes things sometimes look more complex than they should be.

If you program in a simpler language like python on top of the .net framework or JVM, your experience with the libraries might be significantly different.

Also, the Java/C# designers are learning their lessons and C# already has closures and closures in Java are being discussed. Java also has static imports which allow you to create something that "looks like" normal C function calls.

Re:.NET is OOP gone stupid.

[TheLink]

I like the analogy too - but I'm biased since I thought of it :).

I don't know about the Java libraries now, but years ago (Java 1.2?) I seem to recall that doing _common_ things that would be simple in other languages or language libraries are often more complicated in Java. I wasn't using Java then either but my colleagues were and they seemed to have to do a lot more work :).

For example - finding out how many rows a DB query just returned. Years ago it was more work in JDBC - something like move to last row of result set and get row counter value.

It's trivial in other language libs (e.g. perl DBI). Sure some databases don't support it, but I can choose to not support those databases. Java made you "pay" even if you weren't going to use those DBs.

Back then apparently http cookie handling in java was really crap - my colleague was struggling when trying to _make_ http requests and deal with cookies read/write etc.

Whereas that sort of thing was easy with perl LWP and HTTP::Cookies.

IIRC they had lots of other probs too, but I can't remember the details - was not my prob - I was using perl for my stuff. Looking at them, I sure wasn't going to switch my stuff to java.

I guess it helps java programmers feel like they deserve their pay because of all the work they are doing ;).

I must say Java sure runs a lot faster now.

Re:.NET is OOP gone stupid.

[free space]

I certainly see where you're coming from. I haven't done much DB or network programming in Java but I remember trying to read a string from the console and realizing I need to combine instances of multiple classes with scary names (like BufferedInputReader) to do it, so the responses to my post and the OP I replied to do have a point.

(The C# library is much cleaner than Java, IMO. Java suffered a lot from early design mistakes, with each incremental version adding more code to compensate for bad decisions made in the earlier versions. C# had the benefit of hindsight and learned from Java's mistakes).

Anyway, my original point was that a huge object oriented library isn't in itself a bad thing, and that a well designed OO library can be insanely useful and help push a language/VM/platform forward. See how many new languages are directly made to target the JVM/CLR, for example. The "kitchen sink" approach to their libraries probably helped!

Re:.NET is OOP gone stupid.

[Anonymous Coward]

I'm guessing it's easier to read a string from the console in C# than in Java? ;)

Some of the early Java library looks like it was written by "average" people who were told by an above average top level designer to "build these classes", and not written by people who were actually intending to use them daily. If the top level designer didn't spec the details of something, the people implementing it chose "easy to implement" rather than "easy to use".

I'm fine with "kitchen sink" approach, but when I want water I just want to be able to turn the tap and there should be a sane default flow rate for a typical turn. I don't want to end up wading through layers of abstractions.

"See how many new languages are directly made to target the JVM/CLR, for example"

That's good because a few people think Java is a pain and this allows them to replace it module by module in "Enterprise class business apps" ;).

The horror!

[agent0range_]

I am having flashbacks to my days as a .NET developer. Never again! The documentation is just terrible. What do those 240,070 fields do? I don't know, here is what 6 of them do, figure out the rest by trial and error.

Re:The horror!

[Lux]

Hallelujah, brother!

What bugs the snot out of me is that a lot of that stuff is documented really well, but only on developers' blogs. What the hell kind of insulting documentation non-strategy is that? And of course, there's no cross-referencing between msdn and "the blogosphere." So you get to churn away at a search engine until you find a blog entry that's kind of addressing what you want to know.

That said, I do like a lot of stuff about C#. Delegates, for example rank high on that list. And C# 3.5 offers some pretty cool new stuff as well. I likey the lambda expressions, inferred typing, and LINQ.

But the documentation does make me cry at night, sometimes. Sometimes.

Re:The horror!

[DeadlyBattleRobot]

I have mod points, but this deserves about 10 of them so I reply in solidarity.
The msdn docs are not enough, there are too many useless empty API pages. If it weren't for Google I couldn't do any .net programming work. It's ironic that their worst enemy is essential to working with their system.

Often the most useful documentation and samples are scattered over a zillion forums (all requiring logins!), newsgroups, blogs, 3rd party books, etc.

This has always been the case with microsoft development libraries, but it's getting worse because early on (internet time) it was mostly just usenet.

Re:The horror!

[Anonymous Coward]

You two are making this shit up...I've been developing with .NET and C# since 1.0 and rarely, if ever, do I need anything more than what the SDK offers.

Re:The horror!

[johannesg]

Serious question: I have been programming to the WIN32 API for about 10 years now, and I *still* don't know how I am supposed to find information on how to do certain things. For example, let's say I want to delete a file by moving it to the trashcan. At this point I don't know what the correct way to do this is, but I know the possibility exists.

So how do I search for it?

I can Google until I see blue in the face, and maybe find the correct answer. But this does not seem like a good strategy; basically I just expect far, far better from the biggest software maker on the planet.

Or I can read through MSDN - but there is so much there that I can read for years without finding what I need.

So what is the "correct" way to figure out how to do stuff on Windows? Do I need to get a certificate or something? A special developer login maybe? Do I need to read specific newsgroups?

Re:The horror!

[Anonymous Coward]

Intellisense is great - but it unfortunately accounts for 90% of the documentation.

Re:The horror!

[Anonymous Coward]

Hmm, I usually use Google to find .net info too, simply because the search function is better, and the site is a lot cleaner. However, the top results are 9 times out of 10 MSDN pages. The other 10% of the time, I'm either doing something very obscure, or doing something the "wrong way" (the actual wrong way, not a way that MS didn't consider), and trying to force the wrong class to do something another class is much better suited for.

Re:The horror!

[Anonymous Coward]

MSDN documentation for .Net(I've worked up to v2) is great.

In my last job(until the beginning of this year) I've worked in a sensitive data environment with no connection to the web at all.
I've almost never went to the web-station(a few offices away) for gathering data about .net api.
In the worst case scenario I've had to browse the framework using lutz reflector.

Re:The horror!

[Enuratique]

I know I'm late to the party and this probably won't get seen let alone modded up. However, this is a legitimate criticism of the .NET support system. Fortunately there is a search engine (which uses google) to search a subset of .NET-specific sites.

Search .NET

I use it alot and helps separate the wheat from the chaff with regards to Google results.

Re:The horror!

[Lux]

Thank you. This is pure Goodness.

Re:The horror!

[ShakaUVM]

I liked C# 3.5 all right, but 4th Edition has already made it obsolete.

.NET

[The Aethereal]

.NET really is an amazing framework on which to build software. It just needs more OS support and I would use it for programming other than what I do for a living. All those types are there, but they will not be loaded in to memory unless your software needs them.

Re:.NET

[mmell]

Uh, beyond Microsoft, how do you propose to get more OS support?

Just askin'.

Re:.NET

[Constantine XVI]

I'm betting GP meant "open source", not "operating system" Usually, people use OSS(oftware) instead, for that reason

Re:.NET

[The Aethereal]

I am sorry for the confusion. I did indeed mean "operating system". The Mono project for Linux is great and will let you run some .NET apps, but it is incomplete, and they are struggling to keep up with Microsoft's releases. Microsoft has released 3.5 and Mono is just about finished 2.0 (with a few 3.0 features functional, as I understand it). Hopefully .NET will allow for a true "write once, run anywhere" platform, but until then, I will be hesitant to use it for my personal programming projects.

Of course, it isn't Microsoft's fault that Linux has not adopted the platform. I'd like to see them due more to help, though. Certainly opening the source code up for people to use would go a long way.

Re:.NET

[Nurgled]

I think Java's proven that "write once, run anywhere" is a non-starter for desktop apps because no-one has managed to design a sufficiently abstract UI API that allows applications to "feel at home" across Windows, Mac and Linux while still remaining flexible. Most abstraction layers work only at the widget level, so they get caught out by such issues as the fact that Windows tends to prefer MDI -- at least traditionally -- while MacOS prefers lots of top-level windows that are grouped by application in the z-order. Or even something as simple as MacOS's separate menu bar.

The only realistic goal right now is to write your core application logic with the subset of the .NET Framework supported by both Mono and Microsoft's implementation, and then implement a separate frontend for each platform. You can ease the pain here by writing an abstraction layer with knowledge of your application so that only absolute minimum code is different across platforms.

If you're writing non-GUI apps then there's little technical reason not to go ahead and do this now. Since you're talking about your own projects you can easily just stick to the 2.0 API subset that Mono already supports and have cross-platform compatibilty. No-one's forcing you to use WCF and all of that other crazy stuff. Implementation bugs notwithstanding, any app that sticks to the stuff that's common between Mono and Windows -- which is quite a lot -- should work just fine across both implementations.

hmmm...

[Anonymous Coward]

...and with all that we still ended up with vista.

This is News?

[Dragonshed]

Although interesting, because I'm now exposed to the NDepend tool, how is this News? It just begs the slashdot elite to post yet again how much .NET sucks cause it's made by MS, ripped off from Java, etc etc.

Re:This is News?

[megaditto]

It doesn't suck because it's made by MS or ripped off from something. It sucks because the documentation is piss-poor. And there isn't a single working (i.e. cut-and-paste) example for a single API (someone told me they break them on purpose so that newbies don't cut-paste themselves into security holes without understanding exactly how the thing works, but hell!)

I noticed the same thing when Apple released their Cocoa framework (with over half of help pages saying "TODO: descrition, example"). Some Quicktime documentation is still that way today!

How anyone expects the undocumented API stuff to be useful is beyond me.

Re:This is News?

[Anonymous Coward]

http://msdn2.microsoft.com/en-us/library/1k20k614.aspx

I googled for ".net convert string to int" and that came up. The official documentation on Microsoft's site. Anyone who knows anything about developing on .NET knows to check MSDN for stuff. They have TOO much in the way of examples: one for every target .NET language! So you can have a C#, VB.NET, Managed C++, JScript.NET, J#, and XAML examples on some of this stuff.

You really can't be serious here.

Re:This is News?

[mingot]

Huh?

Are you kidding?

http://msdn2.microsoft.com/en-us/library/xfhwa508.aspx

And that's just me randomly hitting a particular class. Most of them have examples.

Re:This is News?

[megaditto]

I checked your ref. There are exactly two examples: for Visual Basic and for C#. I guess all the others are SOL.

Re:This is News?

[thePowerOfGrayskull]

I don't know which is worse - the thought that you're making this comment without having read any of the extensive, working examples on the msdn site; or that you did read them and somehow still feel this way. .Net has plenty of flaws, but lack of documentation ain't one of 'em.

Re:This is News?

[megaditto]

I am not seeing a C++ example in your link. Generic syntax is there, example? not really.

Or do 90% of .NET developers stick with Visual Basic/C# ?

Re:This is News?

[naasking]

I am not seeing a C++ example in your link. Generic syntax is there, example? not really.

Personally, I'm glad the MS docs don't cater to the program-by-copy-paste crowd.

Re:This is News?

[marc.andrysco]

Working my first programming job, I had to take over a project written in C#.NET without any experience in the language. The goal was to communicate through an RS-232 port for sending and receiving some data, including text and numbers. Looking at the previous code, I saw some really long, confusing method of converting a string to ASCII and sending it through. I really took me by surprise since I had never seen anything like it, and I proceeded by looking through documentation. I was hoping for something real nice with fwrite, but I instead I had to jump through some hoops to figure it out. The problem wasn't so much finding documentation, but figuring out what methods I needed to use. I felt overwhelmed with the number of options that were so similar, some of which appeared like they would work but some contained a small caveat that prevented it from working.

On another note, I was perplexed when I used a switch structure and attempted to let the code fall through to another label. The compiler complained and forced me to write a goto statement (is there a more elegant want to do that?). A little later, a senior programmer was reviewing my code an criticized me harshly for putting in a goto where it should simply fall through. I literally had to show him that it would not compile otherwise in order for him to believe me.

Re:This is News?

[omibus]

Yes, because in .Net C++ is a waist of time.

You don't get a speed advantage with C++, C++ is much harder to read and much easier to screw up.

Plus you can just write the code much faster in C# and VB.Net.

Re:This is News?

[Gutboy]

String myString = "this is a string";
Char[] myChar = myString.ToCharArray();


Yeah, I can see why you'd have a problem converting a string to ascii.

As for the switch/case statement, it's part of the design. Fallthrough is a big source of bugs, so in C# they decided not to allow it. As for your use of goto's (and and senior programmer that believed you), that's just plain ignorance and lack of ability.

Re:This is News?

[kaens]

No offense, but if you can't take an example in VB and C# and figure out how to write the approximate version of it in just about any language (especially a .net language), you probably need a bit more in the way of programming language experience.

It's not hard, and the last thing we want is lots of copy-pasting going on.

Re:This is News?

[tekiegreg]

I'm partial to agree on this, if you're sticking in a managed framework, why bother with C++.NET when you'd get along fine in C#. However .NET does allow you to work unmanaged, compiling to native C++ if you feel like it (with decent support using Marshalers translating safe to unsafe and vice-versa). In fact the C++ native compiler in .NET is supposed to be one of the closest to the ANSI C++ standard if I'm not mistaken (I can't remember where I heard that one, don't hold me to it).

Re:This is News?

[Anonymous Coward]

Wrong. It also has J# and C++ (scroll bars are great). Of course, any C++ developer worth their salt can effortlessly figure out the C++ equivilant from a C# sample.

Re:This is News?

[Anonymous Coward]

Actually that's just converting a string to a char array, char being 16-bit in .NET. If you want ASCII you have to use the significantly more verbose and complex:

string s = "Hello World";
byte[] b = Encoding.ASCII.GetBytes(s);

Re:This is News?

[Mongoose Disciple]

Or do 90% of .NET developers stick with Visual Basic/C# ?

Probably more than that. I've worked on a lot of .NET projects at probably 10-20 different companies, and 100% of the .NET developers I've encountered used VB or C# (most using C#).

Re:This is News?

[ErikZ]

Does "Working my first programming job..." ring a bell?

Of course he doesn't have a lot of programming experience.

Re:This is News?

[nobodyman]

It doesn't suck because it's made by MS or ripped off from something. It sucks because the documentation is piss-poor.

I'm not the biggest fan of Microsoft, I gotta disagree with you here . I also work with PHP and Java, and the thing that is most refreshing to me is how good the documentation is by comparison. MSDN is is order of magnitude more robust than the docs coming from Sun, Apple, or the PHP community.

One notable exception that I'll grant you is in their Vista Platform SDK docs. Especially the gadget API. But I tend to attribute it to the general train wreck that is Vista ;-)

Re:This is News?

[Gutboy]

Try printing the char array as integers, it's the ascii values.

Re:This is News?

[Anonymous Coward]

C++ isn't a .NET language.

Re:This is News?

[Anonymous Coward]

Read the source-code!

Oh, wait...

Re:This is News?

[Anonymous Coward]

Maybe it's assumed that if you're using C++/CLI that you are bright enough to know how to take the C# version and make the syntax appropriate for C++/CLI? I also don't see F#, IronPython, IronRuby, PowerShell, C, Boo or any other of the dozens of languages that work on the .NET framework.

String^ s = Convert::ToString((Int64)Int32::MaxValue + 1, 16);
int i = Convert::ToInt32(s, 16);

If you need to see the exact syntax and you need to be able to copy & paste it into your source then you are in the wrong line of work. You need to be wearing a paper hat and mopping up. Maybe in a few years you can be trusted to work the fryer, that is if you don't need someone pushing the button for you each time.

Re:This is News?

[Anonymous Coward]

C++.Net is though. What's your point?

Re:This is News?

[dens]

Yet another example of poor moderation. This is a +5 Insightful when it is complete BS. The .Net doc is actually quite good and chock full of samples, most in multile languages. Thre aren't many development tools that can compete in this area.

Both the poster and moderator should really do their homework!

Re:This is News?

[thePowerOfGrayskull]

In the installable documentation that comes with Visual Studio, examples for every language are provided in almost every case. But you're changing the focus of your argument - now you're saying they /do/ provide examples, but not in the language you want to see it in. Frankly, if you're not able to look at one language and do a translation into another, perhaps programming isn't the right line of work for you. The documentation isn't about the languages, it's about the framework and how to use it.

(Bah. Can't believe I'm defending .net, but I just want to see it crucified for the right reasons (like Properties).)

Re:This is News?

[slashtivus]

Fall through in a case statement in C# works like this: switch (test) { case "1": //do something break; } case "2": case "3": { //both will do something else here break; } } This should compile. Hope I understood your question.

Re:This is News?

[slashtivus]

My reply got mangled, That will teach me to use 'preview'

Fall through in a case statement in C# works like this:

switch (test)
{ case "1":
   //do something break;
}
case "2":
case "3":
{
  //both will do something else here
  break;
}

This should compile. Hope I understood your question.

Re:This is News?

[kaens]

Oh, I must have missed that.

I also forgot that one can get a programming job without much in the way of programming experience.

Re:This is News?

[CopaceticOpus]

Seriously? MSDN, when it finally loads, does have documentation for the simplest use cases of various methods. However, there is little not much of a community of people discussing things and helping each other solve problems anywhere. So once you go past the simplest use cases, you're out of luck. In PHP, ugly though it may be, most times when I have a problem I can Google and find someone else who's already solved it. Also, php.net not only has solid language documentation, it has many helpful contributions from other coders because it allows them to add follow up comments.

My experience is that in real-world cases of solving problems and providing robust examples, PHP's online resources are far superior. I develop in both languages, and I'd love to have better resources for .NET. Generally, once I have the final code for a .NET program, it is simpler and shorter than the PHP equivalent. However, to get there I have to waste time trying to find my way to some obscure setting. .NET makes many hard things easy, and many easy things hard.

goatse

[Nimey]

That's what I first thought of for visualizing .NET.

The goggles, etc.

ughh.. what happened to programming...

[nawcom]

For some reason this reminds me of walking into a Starbucks and asking for a cup of coffee. I don't care about choices, levels, integration. I just want a motherfucking cup of coffee!! dammit!!! If this was supposed to oogle the eyes of unix programmers, it just pushed me further away. I'll use my unix languages and cross-compatible frontends like wx or Qt if I need to have it run on Windows, thank you.

Re:ughh.. what happened to programming...

[flyingfsck]

Heh, I do that all the time: Regular black coffee please! and then I turn half away and talk to someone else forcing the barista to use his imagination and they usually manage just fine.

No bite.

[corychristison]

I want to see a comparison to PHP with all extensions/modules enabled... I have a feeling PHP will have many, many more.

Sadly, that is not a good thing. I love PHP, but it's a mess and desperately needs an overhaul.

(please note: This is my opinion... not out to start a pissing war.)
p.s. - who the hell uses .NET anyway? This is Slashdot. ;-)

Kind of like seeing an STD-map of all of my...

[xoundmind]

1980s classmates. Interesting, on the face, but not something I'd like to revisit.
I enjoyed you as youngster dear Bill Gates, but please don't even think about calling me up after all these years because you're down on your luck.

That's absurd.

[Anonymous Coward]

640 types should be enough for anyone.

If more types is bad, then Java is equally bad.

[Anonymous Coward]

Before you impugn Microsoft with your short-sided emotional appeals against the sheer number of classes, use a hint of logic and realize that since MS copied Java shamelessly and ruthlessly (improving on some debacles in the Java classes, such as the crap IO classes that had to be redone from scratch), you'd be blasting Java, KDE, Python, and most any other class library as well.

Look, in a class library that purports to help most everyone, there's going to be an awful lot of code. Class library implies that classes are used to organize the abstractions provided by the library. Proper OO design favors designing more types with smaller number of features rather than God-objects that do many things. Fine-grained objects are simpler to unit test and are much easier to reuse. The downside is the propagation of types and the verbosity level of the code generally goes up. But that is a fair trade-off in my opinion, since the most important work on the code happens in the maintenance phase, when someone else can come along and at least get a vague idea of what is going on.

I've used the class libraries in Java, KDE, MFC, and Python, and the .NET class library beats them all easily. It is obvious that the designers did their homework and stole from each library what worked well, while dropping what didn't. If they were smart they'd take Java's excellent concurrency constructs such as the BlockingQueue and put them in (they may already have, I don't program much in .NET lately). Most of my beefs with the class library are the fact that it is huge (footprint size), and I don't agree with some of the modeling. But that is minor.

There's a reason Miguel wanted to make this happen on Linux. It is close to making programming fun again, instead of squinting at hyper-abbreviated function names like sprintf and mucking around with idiotic string representations such as C's.

Re:If more types is bad, then Java is equally bad.

[moderatorrater]

Java is equally bad I agree.

Re:If more types is bad, then Java is equally bad.

[Anonymous Coward]

I recommend looking at the QT library - right now I think it's the single best C++ library out there. It greatly simplifies threading, networking, string manipulation, common data structures, native GUI toolkit, internationalization and all with very straightforward code and an amazing build system. It's also cross-platform cross-licensed with GPLv2, GPLv3 & their proprietary license for commercial code.

Re:If more types is bad, then Java is equally bad.

[alanmusician]

My experience concurs with this completely. Being an open-source fan and often contributor, I hated to give in to something like .NET, but honestly it is the most complete development library I've encountered. I've used KDE and MFC also, and find them lacking in both design and power. Visual Studio is also an outstanding IDE.

I have my criticisms (documentation and extensibility), but before using .NET I would have not believed that a proprietary language could grow as actively and efficiently as .NET.

Re:If more types is bad, then Java is equally bad.

[Tim C]

Proper OO design favors designing more types with smaller number of features rather than God-objects that do many things.

Ah, lots of small classes that do one thing and do it well... seems to me I've heard something similar to that about an operating system or something.

Correction

[TheSpoom]

If you're a Web developer, you should ignore .NET and use something much less bloated.

There, fixed that for you.

Bloatware

[Anonymous Coward]

Bloatware

I love every single one of those lines of code.

[rice_burners_suck]

I remember JLG (the fearless leader of BeOS fame) once saying something to the effect that Windows has five billion lines of code in it and that he "loves every single one of those lines." I also seem to recall Bill Gates once saying that IBM liked software to be measured in k-locs, while he debated that it should be measured by what it does. He said something that I don't quite remember, but the jist was, "why would we do something in thousands of lines of code if it could be done in just a few?" How ironic. Hmmm... if JLG's comment was made a decade ago, and our dance teacher has 30,000 monkeys adding a k-loc or two to those five billion lines every day, then there are now about 21,500,000,000 lines of code to love, which seems about right, given how many different "please wait" messages there are.

Re:I love every single one of those lines of code.

[master_p]

The Be FileSystem that supported journaling, meta-data and 64-bit files was around 10,000 lines of code. It's creator made a comment that "he did not understand how the WinFS filesystem was much larger but with half the capabilities".

If you ever browse the Windows source code (I have, out of curiosity, back then when it was leaked), you'll notice huge kloc numbers. For example, the Microsoft's basic list box control was 11,000 lines of code.

Are all these lines of code needed? it depends. The Microsoft style API is "put everything in one big pile of code and let's hope it works". Win32 is a testament to that. It certainly is not elegant...

Hehe ok but you're a bit off.

[DigitalisAkujin]

lol

You're fanboyism of PHP is much appreciated (as I am myself a PHP developer) but PHP is actually smaller. Don't be deceived. This is a GOOD thing. Less bloat = more performance. PHP + *SQL + Memcache will always pack more punch in a smaller package then the .NET Framework. Wikipedia is my primary example. :-)

Also I do have to point out that comparing PHP to .NET is really PHP vs ASP.NET and ASP.NET is actually a framework around the suite of .NET languages (ASP,JSP,C#,C++,and VB). So the comparison is a bit apples to oranges BUT while it is true that .NET can scale I believe that the LAMP stack, combined with Memcache can be more easily scaled with less hardware and less people bringing down costs. Plus, you'd be hard pressed to find a Microsoft trained .NET IT professional that actually knows what he's doing and isn't just another MS certified baboon.

Re:Hehe ok but you're a bit off.

[sydneyfong]

PHP is actually smaller. Don't be deceived. This is a GOOD thing Thousands of functions in the global namespace isn't actually "smaller"...

I can't tell you how many times I've been asking myself "does this name clash with a built in function??" when writing PHP... I agree that .NET has a much larger standard library, but at least I don't have to find out whether they clash with my functions or variables...

Re:Hehe ok but you're a bit off.

[nstlgc]

And yet, compiling PHP code under .NET (Phalanger) easily gives it a 50%-100% performance boost.

Web developers?

[coppro]

Why does TFA say "If you are a web developer..."? If you are a web developer, the only reason I can think of that you might care about the .NET Framework is if you intend on using Silverlight. But if you intend on using Silverlight in conjunction with most of .NET, then you probably aren't actually a web developer, or if you are, you don't consider most of Silverlight relevant to that portion of your portfolio.

Re:Web developers?

[mingot]

You might not like asp.net very much, but saying that people who use it are not web developers is just a tad harsh, wouldn't you say? Or were you just not aware of it?

Re:Web developers?

[DAldredge]

FTN "ASP.NET is a web application framework marketed by Microsoft that programmers can use to build dynamic web sites, web applications and web services. It is part of Microsoft's .NET platform and is the successor to Microsoft's Active Server Pages (ASP) technology. ASP.NET is built on the Common Language Runtime, allowing programmers to write ASP.NET code using any Microsoft .NET language."

Re:Web developers?

[thePowerOfGrayskull]

Perhaps he was thinking of .Net as the asp.net framework; even though the asp.net-specific components are just the tip fo the iceberg (and not the focus of the FA).

Re:Web developers?

[Anonymous Coward]

Um, .NET can do server-side stuff too, like Java servlets.

Re:Web developers?

[Anonymous Coward]

FTN "ASP.NET is a web application framework marketed by Microsoft that programmers can use to build dynamic web sites, web applications and web services. It is part of Microsoft's .NET platform and is the successor to Microsoft's Active Server Pages (ASP) technology. ASP.NET is built on the Common Language Runtime, allowing programmers to write ASP.NET code using any Microsoft .NET language."

I've found mason to be more readable, usable, and extensible.

Of course I also felt that way in the face of PHP. :)

Re:Web developers?

[robogun]

He got confused by Microsoft's renaming of ASP to .NET.

For whatever reason nobody has been able to explain, Microsoft decided to hijack an existing term for a top-level domain (thus the conflation with web development) and call their language that.

Apparently at the renaming meeting, Microsoft didn't have a Scotty to tell Dr Evil or whoever the project head is, that the name already was taken and had been so for many many years.

Re:Web developers?

[_Shad0w_]

.NET is the name of the framework, not the language. The languages are called C#, VB.NET, J# and F#.

J# is pretty much dead, no serious coder works in VB.NET if they have a choice - it's the language everyone takes the piss out of at MS-centric developer conferences - and F# is the OCaml like functional language which isn't actually part of the VS collection yet, but is available as a separate download. Which leaves you with C#, which is what most people work in.

Although I agree with the fact that the name was a pretty dumb choice, but we're stuck with it now. Still doesn't make the framework itself bad. It's actually very nice to work with.

.NET warms the cockles of my heart. Mostly by putting money in my bank account at the end of each month.

Compare it to the Human Genome

[wbean]

The comparison to the human genome is interesting. The genome contains about 3 billion base pairs and 30,000 coding genes. As best I can see, .NET is quite a bit bigger: The closest thing to a gene is a method (an object that can be used, or not used, and which does something). The genome has 30,000 and .NET has 384,000. So even if it takes 10 methods to do what one gene does, they are equivalent.

It takes 3 base pairs to code for a single protein, perhaps the closest we can come to an instruction. Each gene has an average of 3,000 base pairs, equivalent to 1,000 instructions. So we are looking at 30,000 genes x 1,000 instructions/gene or about 30,000,000 instructions in the genome. .NET has 8,000,000 instructions. Given the roughness of the comparison, this is pretty close.

The point here is that we are creating programs that are roughly equal in complexity to the human genome. If we were better programers, then perhaps we'd have come up with intelligent design.

Finally, it's worth noting that the functions are unknown for over 50% of discovered genes. It may be about the same for .NET :))

Re:Compare it to the Human Genome

[Anonymous Coward]

So what percentage of .net can be compared to introns?

P.S. don't be lazy... Google or Wikipedia it. It's (UNITED STATES) high school level material, which says a lot.

Re:Compare it to the Human Genome

[ars]

3 billion vs. 30,000 - actually the function of the 2.99997billion remaining genes is not known, but it is believed to have some function. So we are not even close to having enough complexity to compare to a human.

Re:Compare it to the Human Genome

[n dot l]

There's a big difference between a gene and the following (courtesy of Lutz Roeder's .NET Reflector):

//in System.IO.File
public static string[] ReadAllLines(string path)
{
        return ReadAllLines(path, Encoding.UTF8);
}

Re:Compare it to the Human Genome

[wbean]

3 billion is the figure for base pairs, it takes three of them to code for a single amino acid. On average there are 3,000 base pairs per gene; so, even if the entire 3 billion were encoding something, there would still only be about 1 million genes. A huge part of the genomoe does not code for proteins. There are long sections of repeated blocks of G and C bases. These are belived to have a function relating to gene expression but not coding. There are other large areas repetitive sequences of "junk" DNA. I will be surprised if it turns out to have no function but it certainly doesn't appear to code for proteins. On balance I think the comparison is reasonably valid.

Re:Compare it to the Human Genome

[Ambiguous Coward]

The difference between genetic code and any human-invented language is the following: have you ever tried to debug a genome? It's friggin' ridiculous. No documentation at all.

-G

Re:Compare it to the Human Genome

[glwtta]

The closest thing to a gene is a method (an object that can be used, or not used, and which does something). The genome has 30,000 and .NET has 384,000.

Splice variants, miRNAs, etc - there are a hell of a lot more than 30,000 functional elements in the genome.

Plus, I would think that classes are a better analogy for genes: they get "instantiated" as proteins, which can combine into complexes or form interacting networks, that can perform different tasks based on context. Specific domains or active sites seem more akin to methods.

It seems kinda hard to gauge the total complexity of these things, though. In the end, the total information carried in a method is a couple hundred bytecode instructions, whereas for a protein it's the molecular properties of its constituent amino acids in a specific 3D conformation. Which, I dare say, is probably a bit more complex.

I'm probably thinking about this waaay too seriously...

Re:Compare it to the Human Genome

[megaditto]

Debugging an existing genome is hard. Forking it is easy (and fun, esp. with multiple copies).

Re:Compare it to the Human Genome

[Ambiguous Coward]

Just be sure to use some sort of version control, or your branches may become unmanageable.

-G

I agree

[grahamsz]

The biggest plus to working in Java is that the documentation Sun provide is comprehensive (and once you figure your way around it) easy to access.

Microsoft is getting better but, for a framework that's quite clearly a java rip-off, they could have ripped its documentation style too.

Re:I agree

[BotnetZombie]

I dunno how this is in .net, but another big plus for core Java is that if you find the documentation ambigious or lacking, you can just view the source code and see for yourself what happens inside whatever you're looking at.

Familiar punchline

[spaceyhackerlady]

This reminds me of an old joke:

Q: A Marketing executive and an RIAA lawyer jump off the top of a 50 story building. Who hits the ground first?

A: Who the hell cares?

laura, not a fan of .NET

I'm no M$ fanboy, but...

[R3d Jack]

What's the point? Is this any different from Java? Or is this simply a matter of throwing out some numbers and trashing M$? One poster made a good point: .NET and Java (my preferred environment) are both big and complex. On the other hand, at least in Java, an hour's research is all that's required to have a good enough grasp of file operations to write solid code. I suspect the same is true of NOT YET, er, .NYET, er, that M$ environment. On the other hand, I cringe when I hear about a Web app language doing SQL without prepared statements (that was today, BTW). Suddenly, all apostrophes are forbidden to the people entering data. Small, lightweight environments are great for small, lightweight applications. Java, and yes, .NET are necessary for large, complex applications.
Is .NET any good, compared to other full-featured environments? I don't know, but that silly article certainly didn't contribute anything useful...

Re:I'm no M$ fanboy, but...

[trezor]

I see you at least keep your mind partially open to the idea that .NET isn't total crap. This is good. .NET was basically Microsoft's attempt to replicate Java and what Java did well, and in the process improve what wasn't really optimal. Basically it is MS Java with the hindsight earned after of letting Java plow the field for a few years.

The result is neat.

I used to code Java, but when exposed to the .NET Framework, I pretty much ditched Java for C# instantly. C# is very much like Java, but with a few nice additions to make life simpler.

It has delegates (type-safe function pointers) making things like event-handling and loose coupling of code much more elegant. It has properties which is a hybrid between method and member letting you work with class-data in a more natural way, instead of constantly referencing get-methods and set-methods, in effect making the code much more readable while still retaining full control of what goes in and what goes out.

Basically, with .NET Microsoft improved Java. With the mono-project .NET-code got platform independent at a binary-portable level. Even for the anti-MS crowd, there is no reason to shit on this monumental achievement.

I used to love Java, but these days I'm all C#.

Re:I'm no M$ fanboy, but...

[R3d Jack]

Trezor-

I spent a year as development supervisor leading the transition to .NET back in 2003. In my posting, I was a bit negative about it, only to placate the hard-core M$ haters (I don't like M$ in general, either). But, after using Java first, I found .NET to be well thought out. As you said, it had a good template to follow. I haven't used it for years, so I can't make any definitive statements, but everything I've seen is that it is solid and improving. They are even bringing MVC to ASP.NET! Best wishes with your development career. Based on job postings, C# programmers won't be going without work anytime soon...

Frantic addition of new features

[nofactor]

I guess that the main reason for the problem is the frantic addition of new features to every release while trying not to break backwards compatibility. Every new release offers a "better" way to accomplish the same task, which is presumably faster and more efficient. To avoid interfering with past functionality the easiest solution is to encapsulate new functionality into a new class. This all results in an increasing fragmentation and redundancy of the framework.

Portable.NET

[Paiev]

GNU really has their work cut out for them here with their DotGNU project to provide a free implementation. Good luck rms and co; if you try hard enough, you might be able to implement it all before Duke Nukem Forever is released.

Re:Portable.NET

[Maestro485]

As much as I respect RMS and co., it is a shame that they waste any time at all trying to mimic proprietary functionality. Make something new, dammit!

(For the record, I'm generally one of those left wing GNU guys.)

Java Version

[N8F8]

I did the same thing for Java

so what?

[Petronius]

there's a lot of code. what else does this show / 'prove' ?

A surprise comeback!

[Anonymous Coward]

Aha, he is a wily one, now is he!

Though I may look like a fool now, he still needs to back up what he said with logic and arguments (making sure to distinguish why .NET's is substantially worse than the like's of Java and other class libraries) in order to claim VICTORY!

Re:A surprise comeback!

[Anonymous Coward]

Not only did you not click the link, but you didn't even hover over it in your browser before running off at the mouth. Don't be such a noob.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

The purpose of this complexity

[symbolset]

The purpose of this complexity is to ensure the tool is obsolete before it is mastered.

Since .NET platforms have an average lifespan of what, 18 months? You could spend that much time in a bootcamp drilling namespaces and methods all day and not get there before it's time to enroll in the next one. 384,000 methods? 12,324 public classes? How many of those are deprecated? How many soon will be? And of course if you use this junk to develop for windows, try to remember not to get uppity and make a market with your product. You don't have a chance because the real tools are not here. These are just toys to keep you occupied. But look! They're shiny!

Do not invest your time and money learning trash like this when the turnover is this high. It's not worth it.

Re:The purpose of this complexity

[bladesjester]

I realize that you're one of those "Anything but Microsoft at any cost" people, but I have some news for you.

1) You don't have to memorize what is in every namespace in *any* language. You just have to have a good enough overview of them to know where to look effectively for something you need. Spending all of your time trying to memorize everything in libraries is a waste of time and usually only done by undergads who think that they know it all.

2) These are just toys to keep you occupied
I hate to break it to you, but there is a great deal of business that is done on Microsoft software. There are a number of reasons for that (admittedly, not all of them are good reasons). One of them is that MS has done something Linux and the others haven't - they make software that makes it fairly simple for most businesses and people to do 80% of what they need to easily. In addition, needs which are not met by MS itself, and a number of needs which are, are covered by various 3rd parties.

As for "toys to keep you occupied", I'm one heck of a lot more productive using C# in Visual Studio for most of the things that I have to do than I was using C or C++ in xemacs. C and C++ are fine tools for doing things closer to the metal. Most applications don't need that.

In addition, dealing with deprecation in .NET isn't really any worse than when I was dealing with it in C, C++, or any other language that I've used.

You need to learn to use the right tools for the job. Instead, you want to bash tools on an idealogical basis. It's a sign that you really need to grow up.

Re:The purpose of this complexity

[symbolset]

1) You don't have to memorize what is in every namespace in *any* language. You just have to have a good enough overview of them to know where to look effectively for something you need. Spending all of your time trying to memorize everything in libraries is a waste of time and usually only done by undergads who think that they know it all.

This way lies madness. Knowing just enough about your tools to not cut yourself is not how you become a good craftsman.

2) These are just toys to keep you occupied I hate to break it to you, but there is a great deal of business that is done on Microsoft software. There are a number of reasons for that (admittedly, not all of them are good reasons). One of them is that MS has done something Linux and the others haven't - they make software that makes it fairly simple for most businesses and people to do 80% of what they need to easily. In addition, needs which are not met by MS itself, and a number of needs which are, are covered by various 3rd parties.

And one day most of those apps will be ported to .NET 2.3, .NET 3.0, reverted to .NET 2.7 and then the new stable .NET 3.1. Probably by someone with even less of a grasp of the fractal complexity the beast has grown to by then. Then Microsoft will announce the new and more powerful C$ language (pronounced ca-ching!) and associated libraries and deprecate the entire thing. Of course the next year Microsoft Update will require a service pack that doesn't support the obsolete .NET platform but by then you'll be fully committed to developing your ca-ching! apps at your new position. The poor sap who follows you where you are, however, is going to have a heck of a time figuring out how you got this beast to work when the documentation is no longer available. Everything you thought was clever will cause him to curse your name. Forgotten workarounds will be re-implemented, even if not needed, in the ca-ching platform because nobody recalls what they do. Eventually management will re-org to eliminate the broken business intelligence by deleting the entire department.

Computer science is not magic. You are not a high priest of the occult secrets. It's just a job where you wrangle the bits from one buffer to another. Get over yourself.

There is an ancient chinese adage: "in the course of a long life, a wise man will be prepared to abandon his baggage several times."

Sometimes the simplest way to ease your burden is not to pick it up. When a young programmer retires, noone will remember this .NET thing ever existed. Learning is fun, but it's important not to waste too much of your life learning ephemeral trivia if you want to contribute to real progress that will be a legacy.

Re:The purpose of this complexity

[AKAImBatman]

FWIW, he does have something of a point. Microsoft cycles its platforms at an incredible rate that just is not natural for the industry. As soon as one gets used to the existing API, Microsoft deprecates it and creates a new one. What's the advantage of the new one over the old one? In many cases, no one knows.

Why did Microsoft rearrange the VBA API from Access 97 to Access 2000? Heck if I know. Why did Microsoft make IIS extensions written in .NET 1.x incompatible with 2.0? No idea. All I know is that Microsoft does these things. Evidence suggests that Microsoft does it intentionally to lock out competitors. (source: Barbarians Led by Bill Gates) If that's true, then it certainly doesn't cast Microsoft in a good light.

That being said, you are also correct in saying that C# is a superior desktop development platform. If you're developing for Windows, I don't see any real reason not to use it. It's a fairly decent platform with tons of modern features. The only time it's really inappropriate is when your program needs to be cross platform. In which case Java might be the best choice despite the inherent difficulty in developing a good GUI in Swing. (Or SWT if you prefer. Don't even think about using Mono. Trust me, it's bad juju. Even the Mono devs will tell you that compatibility with .NET is NOT their primary goal.)

Re:The purpose of this complexity

[bladesjester]

This way lies madness. Knowing just enough about your tools to not cut yourself is not how you become a good craftsman.

You're confusing "knowing just enough about your tools to not cut yourself" and knowing the basics and overall use of a set of tools without memorizing every single nuance so that you are capable and comfortable to use them effectively, looking for more information when needed and knowing basically where to find it, without wasting your productive time on trivia.

Given your attitude, somehow I'm not surprised that you don't understand the difference. The first is being a novice (a state that some people never get out of). The second is mastery.

The rest of your post is flawed and based on your foolish view that true mastery requires knowing everything about everything rather than knowing when to look something up and remembering to document what you do.

At the risk of repeating myself, you want to bash tools on an idealogical and emotional basis. It's time to grow up and realize that the use of a tool depends on the situation instead of on $X is evil because it might change or because it comes from $Y.

Re:The purpose of this complexity

[bladesjester]

I agree that he has something of a point wrt deprecation. However, as I said, every language does that. The trick is not to obsess over knowing everything about everything - have a solid basis in the tools, know where to look to find answers that you don't have off the top of your head, and document.

Flexibility is a wonderful thing in a lot of situations.

What he's doing is arguing from an emotional standpoint and claiming that you need to know everything about every aspect of a language, it's libraries, namespaces, etc in order to be any good with it, and that just isn't true. He wants to be rigid, and, honestly, that's not a virtue most of the time.

Yes, changing the APIs for some things is a pain in the arse, and it annoys me. If they do it to lock out competitors, I wish they'd knock it off. If they do it because they honestly think that it's better, that's different. Either way, it's their sandbox to manage as they see fit. If they screw over too much of their user base, people will go elsewhere tool wise and I think that they know that.

I also agree with you about C# being good for windows (I wouldn't be using it otherwise), but not cross platform. I used to do Java for that reason. I changed because most of my clients ended up being windows shops after a while and the increase in productivity that came with not having to screw around with swing was well worth the change.

Re:The purpose of this complexity

[Anonymous Coward]

As for "toys to keep you occupied", I'm one heck of a lot more productive using C# in Visual Studio for most of the things that I have to do than I was using C or C++ in xemacs. C and C++ are fine tools for doing things closer to the metal. Most applications don't need that. C/C++ isn't in the same niche as C#. You'd want to compare C# with say Java or python. Of course both platforms have an extensive standard library, but they seem less prone to whimsical changes which another poster has mentioned.

That being said, I agree that bashing tools on an ideological basis is stupid. But there's a reasonable rationale why some people are cautious when adopting stuff from Microsoft, though that's probably not what the GP had in mind....

Re:The purpose of this complexity

[symbolset]

You're confusing "knowing just enough about your tools to not cut yourself" and knowing the basics and overall use of a set of tools without memorizing every single nuance so that you are capable and comfortable to use them effectively, looking for more information when needed and knowing basically where to find it, without wasting your productive time on trivia.

Mastering the nuances of usage is essential to security. You cannot deny that is important.

Given your attitude, somehow I'm not surprised that you don't understand the difference. The first is being a novice (a state that some people never get out of). The second is mastery.

Yeah, I'm still a novice. I am still uncomfortable about some of the side effects of operators on matrix operations in APL on the IBM 5150. Someday I hope to appreciate fully the four basic loops of C and the nuances of stdlib. If I have trouble with inheritance in C++ I know there are better people to take it up with than you.

That has little to do with the topic, which is the mystic abortion that is .NET. The simplest answer is usually best. The elegant solution expresses completely the solution eloquently. Form follows function. None of these ideals are present in .NET. .NET is complexity for the sake of incomprehensibility. It sells more bootcamps. It drives up the price of certs. Those certs are used by idiots to gain entry into the halls of business where they wreak havok with knowledge but without understanding. It's a bad thing. It's ephemeral and will be obsoleted by another, more complex, equally bad thing because that is its purpose.

Re:The purpose of this complexity

[bladesjester]

C/C++ isn't in the same niche as C#. You'd want to compare C# with say Java or python. Of course both platforms have an extensive standard library, but they seem less prone to whimsical changes which another poster has mentioned.

If you look at his postings, the changes are only part of the thing he is screaming against. He's also screaming about the libraries, claiming that they are complexity for complexity's sake when that honestly isn't the case.

That said, I agree that C and C++ tend to fill a different need than C# or Java. I even stated so earlier. However, he's going about this in an "every problem is a nail" manner and bemoaning the complexity of, say, a circular saw as opposed to a hammer.

Re:The purpose of this complexity

[bladesjester]

Mastering the nuances of usage is essential to security. You cannot deny that is important.

Mastering nuances of things you use every day is not the same thing as mastering every part of a tool created to do a great deal of other things (and allow them to be done with a fair degree of ease) as well. That's part of what you're missing, and I think you're doing it deliberately.

If I have trouble with inheritance in C++ I know there are better people to take it up with than you.

Yet you refuse to listen to me on a point where I apparently know a heck of a lot more than you do - productivity and mastery lie not in knowing everything about everything but rather in having a solid basis in the fundamentals and knowing where to look for knowledge which you will only use infrequently instead of wasting mental space on memorizing things which will be largely useless to you on a day-to-day basis.

Have a cookie and be a good kid. The rest of us have work to do.

Re:The purpose of this complexity

[symbolset]

Yet you refuse to listen to me on a point where I apparently know a heck of a lot more than you do - productivity and mastery lie not in knowing everything about everything but rather in having a solid basis in the fundamentals and knowing where to look for knowledge which you will only use infrequently instead of wasting mental space on memorizing things which will be largely useless to you on a day-to-day basis.

Wasting mental space on things like .NET which will in five years be obsoleted by the Microsoft tool-of-the-day?

Re:The purpose of this complexity

[symbolset]

It took me exactly one upgrade cycle of development tools to figure out that this was cyclic abuse. It was about 1995.

What's your problem? Slow learner? I don't want to be insensitive, but do you think you should be sharing that?

Re:The purpose of this complexity

[symbolset]

Yes, changing the APIs for some things is a pain in the arse, and it annoys me. If they do it to lock out competitors, I wish they'd knock it off. If they do it because they honestly think that it's better, that's different. Either way, it's their sandbox to manage as they see fit. If they screw over too much of their user base, people will go elsewhere tool wise and I think that they know that.

It is seldom that I have such an opportunity to use the same quote twice in one day, but...

'The only thing necessary for the triumph of evil is for good men to do nothing.' - Edmund Burke

In a few months when Microsoft deprecates .NET in favor of the new Longhorn approved architecture (ca-ching or whatever it is) you will herald it at the Next Great Thing. I hope in that moment you remember this: if deer move too fast, shoot the bison. Build not your castle upon the sand. Time spent understanding the babbling of a fool is time wasted.

Re:The purpose of this complexity

[symbolset]

If you look at his postings, the changes are only part of the thing he is screaming against. He's also screaming about the libraries, claiming that they are complexity for complexity's sake when that honestly isn't the case.

I'm not screaming. This is the internet, so THIS IS SCREAMING.

Let me share with you the Tao of Programming:

The Tao gave birth to machine language. Machine language gave birth to the assembler.

The assembler gave birth to the compiler. Now there are ten thousand languages.

Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.

But do not program in COBOL if you can avoid it.

.NET is the COBOL of the modern era, except that COBOL at least survived 50 years. The best hope .NET has is 5. 'Twere better not to learn it.

Re:The purpose of this complexity

[UbuntuLinux]

Symbolset, I have to say, I'd *love* to see you argue your point in person to someone who actually knows what they're talking about, because it would be absolutely hilarious to watch you squirm and wriggle and grow increasingly angry and red-faced as it became clear what a clueless idiot you were.

Re:The purpose of this complexity

[Anonymous Coward]

"'Twere better not to learn it."

Speaking as someone who earns more money and gets more done in a month then you probably do in a year, I'd say you were wrong. I expect this is why you're so bitter though, its very apparent in your posts whenever .NET comes up.

Re:The purpose of this complexity

[gbjbaanb]

In a few months when Microsoft deprecates .NET in favor of the new Longhorn approved architecture (ca-ching or whatever it is) Firstly, can I say that the guy who came up with the new MS technology, C$ (pronounced Ca-ching) is a genius.

MS has already done some deprecating in a big way - look at windowing technologies - want to do cutting edge GUI dev, use Winforms. No. Use Windows Presentation Foundation. No, use MFC.
(yes, MS is already deprecating C# in favour of old-fashioned native C++ - see the Ribbon control that is MFC only, not C# nor going to be C# for a while. The program managers for Visual Studio have said in their blogs that they've concentrated on the managed world enough, its time to return to native code again - probably because all their big customers still use their old/legacy code and want support)

Re:The purpose of this complexity

[Dutch_Cap]

Learn Lisp instead, that's been around for 30 years!

Re:The purpose of this complexity

[RingDev]

Come on Batman, VB remained relatively for 10+ years. Sure a lot of functionality was added, and some fat was trimmed. But if you could write 'Hello World' in VB 3.0, you could write it in 6.0.

As for the incapatibilities between .Net 1.0 and 2.0 (something that I too find rather annoying), it was the jump from MS's first attempt at a managed code language, to a much improved 2nd verion. To list all of the applications in the world that broke compatibility between versions 1.0 and 2.0 would be impossible, but it is hardly a rare or non-industry norm. And MS was nice enough to develop conversion tools for us, the 1.0->2.0 conversion tool was pretty good. MS also learned from that experience and set up 3.0 to be able to run in the same app pools on IIS, included an extremely accurate conversion tool, and left in the legacy functionality.

Not sure what your bones with Mono are though. It's sponsored by Novel now and I believe it is covered under the 'we wont sue eachother' pact MS and Novel signed last year (it's too early in the morning for me to go digging). And on their website they state "Its [mono's] objective is to enable UNIX developers to build and deploy cross-platform .NET Applications." And "Our current focus is on inter-operating with the Microsoft SDK." Sure sounds like the goal is .Net compatibility to me. And with the recent code release from MS, things are looking pretty good for the Mono project.

-Rick

Re:The purpose of this complexity

[SunTzuWarmaster]

No, no, you're right. Linux tools and whatnot have lifespans significantly longer than those short-lived .NET things.

Maybe I'm just bitter because I tried to get mySQL++ working with MSVS only to have it update after a week and work better... (less than a year)

Or the time that I pulled off an offline installation of Fedora Core 3 with all drivers and library dependencies resolved (hey, this was my first linux attemp!), only to have Fedora Core 4 come out THE NEXT WEEK.

Microsoft at least has the decency to change in large steps.

Re:The purpose of this complexity

[mgblst]

I wish that was true. Go look at the jobs out there, I am forced to learn .Net because almost everybody wants it. Unless you work at a University, or some smart company, you are left with .Net. For some stupid reason, all the big companies have jumped on the .Net bandwagon, even though there are way better tools out there. (In my experience, anyway).

Re:The purpose of this complexity

[AKAImBatman]

VB remained relatively for 10+ years.

Sure, the language stayed relatively constant. (Save for the constant pain of getting the right runtime DLLs.) So did Microsoft C++. What changed regularly was the APIs. Do it this way this week. No! We changed our minds! Do it that way now. Oh wait! We're really going to get it right this time! Nope, sorry. We lied.

Not sure what your bones with Mono are though.

I have a primer right here: http://slashdot.org/~AKAImBatman/journal/171365

It's by no means comprehensive, but it should give you some insight into my experiences. I've used Mono more since then and I can tell you, it's really quite terrible.

And on their website they state "Its [mono's] objective is to enable UNIX developers to build and deploy cross-platform .NET Applications." And "Our current focus is on inter-operating with the Microsoft SDK." Sure sounds like the goal is .Net compatibility to me.

Someone is feeding you a line of BS. The intent of Mono was to create a modern managed code environment for Linux. To that end, a lot of focus has been on Linux-specific APIs and not on .NET compatibility. There have been some efforts to make Mono compliant, but nothing that actually makes it usable (Trust me, I've tried. Oh, and XSP is not worth your time.) I really don't have the time or energy to look up the developer's quotes right now, so you'll have to settle for an OnLamp article:

http://www.onlamp.com/pub/a/onlamp/2004/03/11/mono.html

Re:The purpose of this complexity

[Dog-Cow]

In the proprietary-OS world, MS is the king of backward compatibility. Why do you think the problems with Vista have actually resonated with ordinary users and not just techies? It's because for nearly 30 years, people have expected software running on the MS OS of today to work on the MS OS of tomorrow. MS does not just obsolete development environments on a whim. For example, VB is still supported with .Net; it has just evolved as it has every single version.

Your assertion that MS will just abandon C# is not based on real examples, because it hasn't happened. It's based on the emotional instability expected from someone who hates because he hates.

Re:The purpose of this complexity

[bladesjester]

I'm not screaming. This is the internet, so THIS IS SCREAMING.

Okay, you don't like screaming. Would you prefer whining? Perhaps blathering? Grousing? Bitching endlessly? Take your pick... .NET is the COBOL of the modern era, except that COBOL at least survived 50 years. The best hope .NET has is 5. 'Twere better not to learn it.

Sorry, kid, but you're wrong again. The first public beta for .NET came out in 2000, so it's already been around longer than 5 years. Besides, as others have already told you, MS doesn't just abandon things - they really are the kings of backwards compatibility and conversion tools (sometimes to a fault).

Tell me, does it hurt being so wrong so often?

Re:The purpose of this complexity

[bladesjester]

Symbolset, I have to say, I'd *love* to see you argue your point in person to someone who actually knows what they're talking about, because it would be absolutely hilarious to watch you squirm and wriggle and grow increasingly angry and red-faced as it became clear what a clueless idiot you were.

I don't know. I think it's been pretty funny doing it here. =]

Re:The purpose of this complexity

[RingDev]

What changed regularly was the APIs. So you are blaming the programming language for changes to the Windows API? Even then, the Windows API hasn't changed all that radically. I'm sitting here on a XP box using the exact same GDI based double buffer graphics tricks in .Net as I did on Windows 95 and NT 4 using VB5. I can still use a lot of the same multi-media API that I used to write my first VB5 CD player years ago. And even my original socket based communication library from VB5 would only require a few tweaks to get running on XP. Things really haven't changed all that much. The most revolutionary things that happened back in the VB days were the introduction of DAO, then RDO, and finally ADO. Each was tailored for a specific purpose though, DAO was designed for Access/Jet, RDO was the first solid ODBC connection, and ADO was a more flexible connection capable of a variety of connections. But ADO operated identically from VB5 to VB6, DAO received some iterative changes since it's inception, but continues to exist and operate in largely the same manner. And RDO has largely fallen by the side as Lotus Notes diminished and ADO became more widely accepted.

So I'm not really sure what changes you are talking about. Silverlight has been going through a lot of changes, but it is an exceptionally young product (and the 1.0 release really should have been a beta prototype, 2.0 should have been the 1.0 beta).

My experience has been that Microsoft documentation is poorly organized, lacking in detail, designed to run you around in circles, and packaged in a proprietary format that makes it non-portable and generally quite useless. While I would agree that MS's documentation is not wonderfully organized, and is often lacking in detail, claiming that it is in a proprietary format and non-portable when it is available on the web in HTML, is well, a bit of an exaggeration. I've never bothered with developing on a Linux box, because, as you put it:

The craptacular Linux build process bests me again And there is the reason that Windows beats Linux, and Mac OS beats Windows. Process refinement and ease of use. So when it comes to developing .Net apps for Linux, it's just easier to use VS.Net to create your code, then compile it on the Linux box. Sure, you'll run into some annoying issues where Mono doesn't function identically to .Net, and you'll have to make some adjustments. But VS.Net is one heck of a specialized text editor.

Someone is feeding you a line of BS. The intent of Mono was to create a modern managed code environment for Linux. You see, I hear what you are saying there, and it makes sense. But I came across 3 explicit quotes on the website expressing their current efforts, the goal of the project, and their desires. All of which specifically sited compatibility and interop with .Net. And while I respect your opinion Batman, I'd take their word about their goals over your word about their goals.

-Rick

Re:The purpose of this complexity

[Digi-John]

30 years? Try 50.

Re:The purpose of this complexity

[Anonymous Coward]

>One of them is that MS has done something Linux and the others haven't -
> they make software that makes it fairly simple for most businesses and people
> to do 80% of what they need to easily.

Well, as one of the people who gets to do the other 20% of what's hard for businesses and people to to themselves, all I can say is....

Gee, thanks. I'm so glad it's so easy. Too bad you still need that hard 20% to be easy, because that's what's making it harder than easy or hard.

Re:The purpose of this complexity

[FredFredrickson]

Symbolset is upset because it costs money and time to upgrade from .net 2003 to .net 2005. Yes, there were differences. But guess what, my VS6.0 apps still work just fine in Vista, so I really don't think it's an issue. Sounds like you're upset because whoever you work for (that is if you even have a job in programming, which it doesn't sound like you do) keeps opting to change languages mid-stream. That's a pain, but seriously, the migration between 1.1 and 2 wasn't a big deal. It was mostly painless.

But seriously, saying you need to memorize the entire language for security is just stupid. Should I memorize the GD library for PHP to make my email form secure? AND OMG! I should warn my clients that my shopping cart code is potentially insecure because I didn't have the SWF library memorized.

Ok now back to earth. Good security comes from knowing a lot about software architechure and design in general, not the small differences between functions in libraries that you don't use.

If someday, a client asked me for a program that did function XYZ, I'd know where to look to do it. That doesn't make me a bad programmer. Nobody knows everything, and anybody who claims to, probably knows less than those who don't.

Re:The purpose of this complexity

[BountyX]

I'm a heck of a lot more productive using Qt windows API with Eclipse...look ma, no manifest or VM! I moc you.

Re:The purpose of this complexity

[Anonymous Coward]

Totally agree... I'm one of those people that bought a bunch of ADO/Asp books and .com books before that.... and a windows handle book for 98/95 before that... Microsoft purposefully changes things enough to screw things up royally so that you have to upgrade or die. It happens over and over and over... happened with VB. Happened with Visual C++ going to .net... happens all the time, every 2-4 years or so. You aren't spending enough money every month on new M$ products, time to screw things up enough that you need to buy all new programming books and software so that you can be back at ground zero and have to spend all your days relearning everything from scratch and reinventing the wheel so that you'll never be able to move beyond having to constantly buy our stuff forever!!!!

There's just a lot of features

[tjstork]

Simplicity? Internal logic?

Yes, actually. There's a ton of features in Windows at the SDK level and .NET is really designed to be a wrapper around all the different Windows services. A lot of things in Windows are rather difficult to program at the C or even the C++ level. The standard Win32 API isn't too bad to work with in C, but the windowing functions and the messages mechanism is enough to provoke tears. Really, Windows is terrible for programming in C compared to Linux, and so, at least .NET papers over all the crap.

Right off the wheel, I can think of a couple of things that are easier to do in .NET than in the native C++ in Windows. Writing services in C++ is basically torture. In .NET, services are very easy to write. In C++, cracking messages in Windows forms natively is a tad like pulling teeth. MFC is aweful and ATL/WTL are better, but, I would prefer a native C++ framework like what was done with BeOS. Still, GDI+ in C++ is pretty much the same as using GDI+ in .NET, except that .NET actually gives you more convenient handling of images and fonts. Files are much easier to work with in .NET than in C++. The Path combining classes are entirely welcome and those things are great. .NET String is better than the STL string, by far, and I really like that Microsoft stole the Java idea of a StringBuilder.

Of course, .NET forms are ugly and slow. The presentation framework looks cool, but, that's now two libraries for user interface, not counting all the web stuff.

Speaking of Java... I wonder how many lines of code are in THAT framework?

Re:There's just a lot of features

[Alex Belits]

Yes, actually. There's a ton of features in Windows at the SDK level and .NET is really designed to be a wrapper around all the different Windows services. Wrappers are acceptance of defeat as far as consistent infrastructure development is concerned.

A lot of things in Windows are rather difficult to program at the C or even the C++ level. The standard Win32 API isn't too bad to work with in C, but the windowing functions and the messages mechanism is enough to provoke tears. Really, Windows is terrible for programming in C compared to Linux, and so, at least .NET papers over all the crap. This only means that Microsoft "technologies" developed before dotnet are even crappier than dotnet itself (and dotnet runs on top of them). But we already knew that.

Re:There's just a lot of features

[Fuzzums]

> Wrappers are acceptance of defeat as far as consistent infrastructure development is concerned.

As af ar I know and you don't there is a different reason.
"Type safe" and "managed" are your Google keywords for today.

> This only means that Microsoft "technologies" developed before dotnet are even crappier than dotnet itself (and dotnet runs on top of them). But we already knew that.

Even if this is right, your comment shows you're rather "new" at programming. I'll explain.
Option 1: rewrite (i mean completely really rewrite) the wrapped classes. Hey! We need to rewrite and test almost everything (application / os) that has been built on this classes that were working, but nor have been rewritten.
Option 2: write a wrapper, possibly fix/catch bugs from wrapped classes, and no rewrite of apps and os.

Yes, your code could be so much better and nicer with option 1, but there are limiting factors like time and money.

Re:There's just a lot of features

[Alex Belits]

As af ar I know and you don't there is a different reason.
"Type safe" and "managed" are your Google keywords for today. Who cares? You don't build a consistent system by taking old, inconsistently designed pieces and making them seem to fall into some scheme by calling them from wrappers. You build a system in a way that reuses fundamental components as much as possible, so it is consistent by design.

Unix file descriptor remains being the greatest example of this consistent design -- whatever is added to the system, interface is provided by the same mechanism, so kernel interface, security, caching and buffering, naming and most of the ways to access those features rely on the same existing infrastructure. What is the closest Windows equivalent? Handle, an ugly wrapper, implemented without even a rudimental polymorphism.

Even if this is right, your comment shows you're rather "new" at programming. I'll explain.
Option 1: rewrite (i mean completely really rewrite) the wrapped classes. Hey! We need to rewrite and test almost everything (application / os) that has been built on this classes that were working, but nor have been rewritten.
Option 2: write a wrapper, possibly fix/catch bugs from wrapped classes, and no rewrite of apps and os. Option 3: don't write hideously convoluted crap that has to be concealed by layers of makeup in the first place.

It's really telling that Qt, a toolkit that by its very purpose has to contain wrappers providing compatibility between multiple platforms and targeted for a lower-level language, ended up being more consistent, more efficient, and easier to develop for than dotnet.

Yes, your code could be so much better and nicer with option 1, but there are limiting factors like time and money. This would mean something if Microsoft's efforts on building more layers upon layers didn't lead to exponentially growing complexity of both implementation and interface. If anything, the article illustrates how complex, and therefore expensive to develop, dotnet became.

Re:There's just a lot of features

[Fuzzums]

Theoretically you're right, but reality is different. A company just can't start from scratch each time they extend their product.

And frankly, you reactions make it look like you've never worked with .NET

Oh. Please don't think I'm all pro M$. Tux TM OS is cool too, but I don't know about a development framework for linux that can do what .net can do. I know there is Mono, but that's not a Tux TM invention.

Re:There's just a lot of features

[Alex Belits]

Theoretically you're right, but reality is different. A company just can't start from scratch each time they extend their product. Yes, it can. And yes, I have participated in projects that had to do it -- when design no longer matches the purpose of a product or its development direction, development of patches upon patches asymptotically approaches a usable release candidate, never producing a version that a sane person would want to release and support. Usually the only way to cross that line is to remove old cruft and build an infrastructure, what can be easily seen on examples of open source applications -- Mozilla, OpenOffice.org, X11, etc. With proprietary software it's exactly the same, except less people see the extent of every problem, and less is done about that.

Re:There's just a lot of features

[Alex Belits]

Oh. Please don't think I'm all pro M$. Tux TM OS is cool too, but I don't know about a development framework for linux that can do what .net can do. I know there is Mono, but that's not a Tux TM invention. There is no monolithic "framework" in a way that Java or dotnet made. Every piece of the system is designed to be usable as a part of any "framework" you need, they are all perfectly interchangeable.

Re:There's just a lot of features

[Anonymous Coward]

Really? What features - last I checked I had to wrap MOST Win32 API calls in order to access them from C#. Try working with anything in kernel32.dll, such as memory hooking / editing or the user..dll (whatever it is called now). .NET provides no "natural" access to most of these API functions, instead you have to use the dllimport wrapping for unmanaged code.

Re:There's just a lot of features

[sgt scrub]

.NET papers over all the crap.

Thanks for the adding those words to the thread. Visualize, .NET, Paper, and crap all fit perfectly in the sentence I would use to describe the vision I get when describing .NET.

Re:There's just a lot of features

[tjstork]

It's really telling that Qt, a toolkit that by its very purpose has to contain wrappers providing compatibility between multiple platforms and targeted for a lower-level language, ended up being more consistent, more efficient, and easier to develop for than dotnet.

Qt is not easier to develop for in .NET period. That's just crazy talk. .NET delegates are very nice.

Re:There's just a lot of features

[cwebster]

"Really, Windows is terrible for programming in C compared to Linux, and so, at least .NET papers over all the crap."

you've never written any code to run under X windows, have you? Not qt/gtk, but plain X, its just as bad, if not worse.

Yeah, but can I find what I'm looking for?

[Gazzonyx]

All other things being equal, after trying to find anything in the MSDN, let alone the vaporware API I inherited (DAO Jet library, try to find it some time - they didn't actually document it, and what they did document, was neither complete nor useful. That's being charitable.), seeing a Javadoc is like stumbling out of the desert and in to an Evian bottling factory.

Sure, the J2SE API as HTML files is 60 MB or something, but at the very least, it's consistent, well laid out, the cross references make sense, and I can drill down to the objects that are probably what I need in about 3 or 4 'hops'. Also, how large is the MSDN now? I think I've got about 4 versions (VS 6.0 - VS2k8) each weighing in at something like 700 MB. Back to my desert analogy, it's like "water, water everywhere; but not a drop to drink" with the MSDN.

Re:Yeah, but can I find what I'm looking for?

[Mongoose Disciple]

I've never really had that kind of trouble with the MSDN.

I can always find the page/article I'm looking for; it's just that sometimes it will be spectacularly unhelpful.

Constants and variables

[CustomDesigned]

Your objection to the Range type is an objection to using variables instead of constants. As long as the Range type has a constant syntax in the language, it is still helpful to document and enforce the purpose of the comparison:

if (Range('12/31/07','1/31/08').contains(date))

If the language needs to actually call a constructor even for constant objects, then it may not be worth it, but it can add clarity.

When the data really *is* variable, then the type is even more important. For instance, in an sql engine I wrote, a basic query is translated a list of arrays of ranges - a list of multidimensional boxes, one dimension for each key field. The low level indexing can use the array of key ranges very efficiently.

So, wait a minute

[glwtta]

Having a large class library is a bad thing now? You don't like it when other people do work for you?

It's all properly namespaced (unlike some languages I could name), having a bunch of classes you don't need to use does not add to your mental footprint.

Re:So, wait a minute

[trezor]

This article (in the context of being posted on slashdot) to me just seems like a chance for overly zealous Linux-fanboys to take a shit on Microsoft, .NET and "bloat".

Think people who spend a weekend to custom-compile their kernel with nothing as modules, everything else excluded and perfectly narrowed down to the things they need and nothing more. Just to save a massive 4KB of memory footprint.

After which they sit down and pat themselves on the back, knowing that their Linux environment is as optimized as it can be and that the lack of those 4KBs which can now be used as a system-cache will never impede their system's performance ever again.

Until they start wondering if compiling with -funroll-loops might save them 2-digit CPU-cycles per month and how that measures up to the increased memory usage.

You know: those guys. Ignore them, don't take them seriously, and don't expect them to know jack shit about development of any sizeable real-world project.

Even a troll with this many replies is Interesting

[symbolset]

Moderation abuse? Anybody?

Dependencies for Linux?

[Doc Ruby]

Is there a tool like NDepend for Linux?

Is there one that can analyze both the source code (in C or C++) and the DB schema SQL that the code runs against?

That can show lots of classes, inheritance, tables and relations, without overwhelming the view?

10 Seconds on the link emphasises "Stay away!"

[Qbertino]

This submition is breaking new ground: Proprietary MS plattform lockin now combined with the crappyness of pointless fanboy analysis in the style of über-crappy layouted GNU Open Source web posts. Great.

No thanks people. I'm staying the heck away from MS, .Net, 'SilverShite' and whatnot. For anything. But especially for web stuff. And because nearly 20 years of very good reasons too.

There are a bazillion webkits out there, one better than the next and *all* of them open. (I just ran across haxe again the other day - yet another totally awesome OSS solution). No need to even waste a minute considering MS. Unless you're being paid tripple for your time, waste of brainpower and for learning stuff that corporations have no interest in keeping around for long, because they want to sell it again and again.

Take it from a professional web-developer: Stear clear. Jump on the Rails bandwagon if you must (only if you really must) but do yourself a favour and stay away from .Net.

My 2 cents.

Re:10 Seconds on the link emphasises "Stay away!"

[dens]

So, how do you really feel? ;-)

.bloat can go to hell

[GNUPublicLicense]

Oh! A wonderfull bloat! Please open the hell gate and throw it through... why do we want to loose our precious time to promote the borg lock down and brain damaged stuff?? We, I meant us, real computer engineers, not those monkeys(...) part of the borg collective, open source or not.

.NET is an empty tin

[Anonymous Coward]

.NET is a money-trap of MS, a proprietary software and marketing strategy. It is on top of *real* programming environments thus slow. It is nothing to worth to talk about it or learning it...

most common .Net developer mistake

[192939495969798999]

The most common .Net developer mistake now is that people don't bother finding the function they need -- instead they just reinvent it and waste everyone's time when maintaining that code later. The problem with 30,000+ items is that there's no good way to teach people where to look for something that's already in there. If it were organized in such a way that one could easily not reinvent the wheel, then it would be an awesome language. Without that, though, it becomes yet another way for people to create crappy date parsers.

Re:most common .Net developer mistake

[dcam]

Part of the problem is that new features become available in later versions, where the code had to be written manually before.

Without that, though, it becomes yet another way for people to create crappy date parsers.

What, instead of relying on Microsoft's buggy date parsers? I have a bug replicated multiple times where if you parse a date with the locale set to en-au or en-uk, it still parses it as a US date. The issue varies from machine to machine, but it is there. This is on machines which definitely have the au locale. No solution found after vigorous googling, and reporting bugs to Microsoft is a ridiculous process that normally results in you paying $ and being told that this is a new "feature". So yes I will write my own date parsing code library thankyouverymuch.

Re:most common .Net developer mistake

[Anonymous Coward]

Classic Post *yawn* ...

reporting bugs to Microsoft is a ridiculous process that normally results in you paying $ and being told that this is a new "feature"
Read as: I didn't even try to contact Microsoft.

thankyouverymuch Cutesy /.ism. noproblematallnowgocontactmicrosoft

Re:most common .Net developer mistake

[dcam]

Read as: I didn't even try to contact Microsoft.

Read as: I am not going to pay Microsoft for the privilege of contacting Microsoft to report bugs in their systems. I have run into some bugs in the past:
- IIS parsing .Net 1.1 code in IIS using the 2.0 framework and generating 2.0 bugs. This was following a SP upgrade to 2.0.
            Response: You must be wrong, have you run aspnet_regiis?
            Me: Yes.
            Response: Try running it again.
            Me: same problem.
            Response: crickets
- IE7 interprets the no-cache directive for a SSL site as a directive not to write anything to HD under any circumstances. That means if you binary write a file to IE7 using this header the file cannot be opened.
            Response: this is by design
            Me: According to the standards this is broken
            Respose: we like our dead lightbulb feature

Now I'll be buggered if I'll waste my company's time and money reporting bugs to microsoft for that kind of response. I can file bugs with Mozilla. I can file bugs with opera. I can't file bugs with Microsoft without paying for the privilege.

Screw that, it is cheaper and easier for me to code around their issues.

MAXINT

[__aalnoi707]

I'm surprised that .NET hasent crashed on 32 bit systems

End Times?

[dreamchaser]

I always thought that if the entire .NET framework were pictorially represented it would open the Seven Seals and be the harbinger of the Apocalypse.

Yeah, but after 10 years, I'm back at square 1

[Gazzonyx]

Yeah, but I, for one, am stuck with a quarter million SLOC VBA(which is really a subset of VB 6) application that has no upgrade path to .NET. Furthermore, even if I could get out of VB 6, I'd have to refactor all the DAO calls to ADO, and that to ADO.NET or wrap them in an ODBC wrapper class. Sorry, I'm a little bitter about supporting someone else's custom Access application without any way out. The least they could have done is given me a way to get all the binary forms and reports out; sure, I can get the modules and class code, but I've no recourse other than remaking about a hundred forms. I understand that they moved on to .NET and there is no real way to port the code accurately, but they could have at least given me a way to export the design.

Re:Yeah, but after 10 years, I'm back at square 1

[RingDev]

Unfortuntely a lot of organizations made some really bad decisions with how and when to use access. I know your pain, and I pitty you. But if I choose to weld a bumper hitch on to a 1984 Honda Civic, it's going to suck trying to pull a boat with it. And no matter how new and fancy that hitch is, you're still trying to pull a boat with a Civic.

If you can export the Access forms to VB6 (I think there are some 3rd party tools floating around that do this) you can use the VB6->.Net 1.0 converter to get them into .Net. At the same time, I would strip all logic from behind the forms as the fundamentals of programing in VB.Net are radically different than VB even though the syntax is similar. But that should at least get you the form designs to start with.

-Rick

Re:Yeah, but after 10 years, I'm back at square 1

[Anonymous Coward]

You sir must not have used the vb6 converter. It's pretty much unusable.
Read about the absolutely huge outcry from the vb6 camp. It's so bad that instead of converting to .NET they switched to other tools completely. C#, PHP, anything but VB. VB programmers realized that MS didn't care enough about them so they moved on to a more common/supported platform.

Posting anon because of all the ms astroturfers.

What if I'm not a Web developer?

[dens]

"If you're a Web developer, you should check out a quick post about the number of types, methods, & fields in the .NET framework. It's a common misconception that .Net is only for web development.

Re:I finally get it!

[TheSpoom]

Star Trek is what happens when the human genome is released as open source!

Monorails ......

[ipjohnson]

Isn't that more of a shelbyville idea?

Slashdot .NET

[BountyX]

I used to find slashdot delightful, But my feelings of late are more spiteful; My comments Sarcastic The Iconoclastic Keep Modding to Plus Five (Insightful)