×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

320 comments

Answer: No Thanks (-1, Flamebait)

LiquidCoooled (634315) | more than 6 years ago | (#22790574)

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

Re:Answer: No Thanks (-1, Troll)

Naughty Bob (1004174) | more than 6 years ago | (#22790636)

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 (0)

linumax (910946) | more than 6 years ago | (#22790780)

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

Re:Answer: No Thanks (-1, Troll)

Naughty Bob (1004174) | more than 6 years ago | (#22790894)

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

I'd rather work with Mono [wikipedia.org] any day...

Re:Answer: No Thanks (5, Informative)

Anonymous Coward | more than 6 years ago | (#22791054)

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 (4, Informative)

diamondmagic (877411) | more than 6 years ago | (#22791102)

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

A surprise comeback! (0)

Anonymous Coward | more than 6 years ago | (#22791186)

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!

Wow, that's a big fat ASS^H^HPI (4, Insightful)

NewbieProgrammerMan (558327) | more than 6 years ago | (#22790614)

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 (1)

AKAImBatman (238306) | more than 6 years ago | (#22790638)

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 (2, Funny)

IdeaMan (216340) | more than 6 years ago | (#22790804)

"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 (3, Informative)

nmb3000 (741169) | more than 6 years ago | (#22790704)

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 (4, Insightful)

CastrTroy (595695) | more than 6 years ago | (#22790774)

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 (2, Funny)

liquidpele (663430) | more than 6 years ago | (#22791282)

Why are you comparing PHP to .NET? That's like comparing an old Honda to a monorail.

Re:Wow, that's a big fat ASS^H^HPI (4, Interesting)

iluvcapra (782887) | more than 6 years ago | (#22791390)

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 (1)

NewbieProgrammerMan (558327) | more than 6 years ago | (#22790824)

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 (1)

peektwice (726616) | more than 6 years ago | (#22791276)

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 (5, Insightful)

AKAImBatman (238306) | more than 6 years ago | (#22790946)

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 (0)

Anonymous Coward | more than 6 years ago | (#22791278)

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 (4, Funny)

PPH (736903) | more than 6 years ago | (#22790710)

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 (4, Insightful)

MrSteveSD (801820) | more than 6 years ago | (#22790978)

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 (5, Insightful)

daveime (1253762) | more than 6 years ago | (#22791226)

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 (1)

liquidpele (663430) | more than 6 years ago | (#22791322)

While I think his example was overly simplistic and that there are good uses for more types, I do agree that over abstraction can be a hindrance to code maintainability and efficiency. However, the "abstraction sweet spot," so to speak, differs for each project, so I don't see why having more types for those that want it is a bad thing. You can always just not use them and compare to the date directly if you want.

Re:Wow, that's a big fat ASS^H^HPI (2, Insightful)

Gutboy (587531) | more than 6 years ago | (#22791348)

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 (5, Insightful)

MrSteveSD (801820) | more than 6 years ago | (#22791398)

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 (1)

mikael (484) | more than 6 years ago | (#22791274)

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?

.NET is OOP gone stupid. (4, Insightful)

Anonymous Coward | more than 6 years ago | (#22790646)

.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. (4, Insightful)

NewbieProgrammerMan (558327) | more than 6 years ago | (#22790750)

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. (1, Interesting)

grahamsz (150076) | more than 6 years ago | (#22790836)

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. (4, Funny)

LaskoVortex (1153471) | more than 6 years ago | (#22790872)

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

cbart387 (1192883) | more than 6 years ago | (#22790970)

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

Anonymous Coward | more than 6 years ago | (#22790986)

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

Anonymous Coward | more than 6 years ago | (#22790998)

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

NewbieProgrammerMan (558327) | more than 6 years ago | (#22791114)

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

Anonymous Coward | more than 6 years ago | (#22791084)

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

Re:.NET is OOP gone stupid. (5, Insightful)

free space (13714) | more than 6 years ago | (#22790838)

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. (2, Informative)

Watson Ladd (955755) | more than 6 years ago | (#22790932)

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

free space (13714) | more than 6 years ago | (#22791020)

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

Jester998 (156179) | more than 6 years ago | (#22791132)

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

free space (13714) | more than 6 years ago | (#22791214)

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

Anonymous Coward | more than 6 years ago | (#22791062)

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

MrSteveSD (801820) | more than 6 years ago | (#22791064)

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

Mongoose Disciple (722373) | more than 6 years ago | (#22791416)

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. (5, Insightful)

n dot l (1099033) | more than 6 years ago | (#22791098)

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

Breakfast Pants (323698) | more than 6 years ago | (#22791336)

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. (2, Insightful)

Dilly Bar (23168) | more than 6 years ago | (#22791108)

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

Breakfast Pants (323698) | more than 6 years ago | (#22791360)

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. (1, Informative)

Anonymous Coward | more than 6 years ago | (#22791148)

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. (4, Informative)

batkiwi (137781) | more than 6 years ago | (#22791154)

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. (2, Informative)

jesterzog (189797) | more than 6 years ago | (#22791212)

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

Oddster (628633) | more than 6 years ago | (#22791344)

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.

The horror! (-1, Troll)

agent0range_ (472103) | more than 6 years ago | (#22790652)

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! (5, Insightful)

Lux (49200) | more than 6 years ago | (#22790834)

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! (5, Insightful)

DeadlyBattleRobot (130509) | more than 6 years ago | (#22791288)

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.

I agree (4, Informative)

grahamsz (150076) | more than 6 years ago | (#22790956)

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.

.NET (3, Insightful)

The Aethereal (1160051) | more than 6 years ago | (#22790656)

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

hmmm... (0)

Anonymous Coward | more than 6 years ago | (#22790680)

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

This is News? (0)

Dragonshed (206590) | more than 6 years ago | (#22790684)

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? (4, Insightful)

megaditto (982598) | more than 6 years ago | (#22790806)

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? (1, Insightful)

Anonymous Coward | more than 6 years ago | (#22790906)

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

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? (1)

megaditto (982598) | more than 6 years ago | (#22791032)

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? (1)

naasking (94116) | more than 6 years ago | (#22791164)

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? (1)

omibus (116064) | more than 6 years ago | (#22791368)

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? (1)

mingot (665080) | more than 6 years ago | (#22790930)

Huh?

Are you kidding?

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

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

Re:This is News? (1)

megaditto (982598) | more than 6 years ago | (#22791000)

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? (1)

kaens (639772) | more than 6 years ago | (#22791424)

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? (3, Insightful)

thePowerOfGrayskull (905905) | more than 6 years ago | (#22791016)

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? (2, Interesting)

marc.andrysco (1173073) | more than 6 years ago | (#22791354)

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? (1)

Gutboy (587531) | more than 6 years ago | (#22791414)

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.

ughh.. what happened to programming... (1)

nawcom (941663) | more than 6 years ago | (#22790752)

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

flyingfsck (986395) | more than 6 years ago | (#22791312)

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

corychristison (951993) | more than 6 years ago | (#22790756)

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

Hehe ok but you're a bit off. (1)

DigitalisAkujin (846133) | more than 6 years ago | (#22790916)

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.

Kind of like seeing an STD-map of all of my... (1)

xoundmind (932373) | more than 6 years ago | (#22790758)

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

Anonymous Coward | more than 6 years ago | (#22790782)

640 types should be enough for anyone.

If more types is bad, then Java is equally bad. (5, Insightful)

Anonymous Coward | more than 6 years ago | (#22790822)

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.

Correction (4, Funny)

TheSpoom (715771) | more than 6 years ago | (#22790852)

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

There, fixed that for you.

Bloatware (0)

Anonymous Coward | more than 6 years ago | (#22790876)

Bloatware

I love every single one of those lines of code. (2, Insightful)

rice_burners_suck (243660) | more than 6 years ago | (#22790914)

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.

Web developers? (0)

coppro (1143801) | more than 6 years ago | (#22790918)

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? (1)

mingot (665080) | more than 6 years ago | (#22790990)

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? (2, Insightful)

DAldredge (2353) | more than 6 years ago | (#22790992)

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? (1)

thePowerOfGrayskull (905905) | more than 6 years ago | (#22791034)

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? (0)

Anonymous Coward | more than 6 years ago | (#22791080)

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

Compare it to the Human Genome (4, Interesting)

wbean (222522) | more than 6 years ago | (#22790942)

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 (0)

Anonymous Coward | more than 6 years ago | (#22791058)

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 (1)

ars (79600) | more than 6 years ago | (#22791118)

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 (1)

wbean (222522) | more than 6 years ago | (#22791230)

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 (1)

n dot l (1099033) | more than 6 years ago | (#22791172)

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);
}

Familiar punchline (3, Funny)

spaceyhackerlady (462530) | more than 6 years ago | (#22791078)

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

R3d Jack (1107235) | more than 6 years ago | (#22791082)

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

Frantic addition of new features (1)

nofactor (1053982) | more than 6 years ago | (#22791094)

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 (2, Funny)

Paiev (1233954) | more than 6 years ago | (#22791116)

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 (1)

Maestro485 (1166937) | more than 6 years ago | (#22791294)

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.)
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...