Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Willfor]

Oh, and don't use C#. It's a decent enough language, (it's the good stuff from Java with the good stuff from C++, with more OO than either) but it restructures your brain and turns you evil. All C# developers suffer from this, but can't see it themselves.

I twist my mustache at you, good sir.

[eerr]

I thought that was Java?

Oh right, incompetence.

Psh, you just can't handle concentrated OO.

[qwertyuiopas]

.NET is an idiotic way to program. To get *anything* done, you must RTFM until you have memorized half of MSDN.

Maybe you don't notice, but for the first year or two, rather than simply looking at a library reference, a beginner will be stuck trying to understand how to do something. Should they seek a constructor? Maybe an overloaded method? Wrong type of object? Maybe it's in system.*? Perhaps it just can't do it that way, and you must create three intermediate objects, hopefully getting the right sequence, else you have to do this all over again...

Other languages will actually let you know when something is impossible, rather than say "maybe, but I'm not telling you how...".

If I stuck with the C interface, I would have spent half of the time doing boilerplate, yes, but at least I would have accomplished my goal rather than givin up after wasing more time than a proper language would have needed total.

[Willfor]

Qwerty, that was my experience with ALL programming languages...

[ed boy]

I thought that was Java?

Oh right, incompetence.

Psh, you just can't handle concentrated OO.

I've been having a go with ruby, and it puts the object orientation of Java to shame.

[Blacken]

.NET is an idiotic way to program. To get *anything* done, you must RTFM until you have memorized half of MSDN.

Manifestly wrong. I don't know the BCL well at all (aside from some of the basic classes and hierarchical class structures--the data types, Stream, useful bits of Winforms I've picked up over the last few years, etc.), but I have tools that let me figure out what I need. Which is commonplace in environments that aren't relics of the 80's.

(flames removed - tt)

Other languages will actually let you know when something is impossible, rather than say "maybe, but I'm not telling you how...".

This is absolutely false, as anyone who actually has experience with the toolset, as opposed to fearmongering ignorance, will attest. Occasionally it is difficult to find how to do something--but that is the case in any language or framework, and there's no serious argument that the discoverability of .NET is inferior to the clusterfuck in most other commonly used languages. At least there's meaningful documentation to be had when working with .NET and Mono. Good luck finding that for much of anything outside of the oh-so-small subset of necessary functions you get in C++'s standard library (which is woefully inadequate for any sufficiently complex task).

If I stuck with the C interface, I would have spent half of the time doing boilerplate, yes, but at least I would have accomplished my goal rather than givin up after wasing more time than a proper language would have needed total.

Really? Do you really think this is going to fly as an argument? It should be self-evident to anyone with subject matter expertise that this is an utterly dishonest representation. Don't get me wrong, intellectual dishonesty seems to be par for the course from you, because frankly you don't seem to have the wherewithal to actually make an honest effort to understand something outside the little box you've already adopted, but this sort of behavior is still absolutely cretinous.

You know that Bjarne Stroustrup himself doesn't even recommend using C++ the way people use it, don't you? (Wait, sorry, that doesn't jibe with your bizarre little worldview, so you're going to dismiss it out of hand.) Here's a hint: people didn't just up and abandon C++--and make no mistake, C++ is shrinking and that is nothing but a good thing--because Java, .NET, and other similar toolkits were inferior. The benefits to using a modern toolset are evident even to managers, let alone developers, and it's the little wannabe-l33tists who haven't gotten the memo.

The people who are worth a damn are busy actually being productive and not jerking off over C++ for anything but perf-critical code. Maybe when you get an actual job writing code and a decade of programming experience under your belt you'll have some kind of actual perspective, but your track record with critical self-analysis is clearly very poor.

[Outcast Orange]

... and then Blacken started flaming.

Everyone was very shocked.

[Blacken]

Calling someone out for intellectual dishonesty isn't flaming when it's true. Sorry to disappoint you.

And yes, I have a good idea of what he actually knows, because he's tipped his hand and it's utterly evident he has no expertise or authority to make sweeping grand statements about .NET. My post was pretty annoyed, because this isn't the first time he's tried so hard to sound like he has a clue and clearly does not.

I've been doing this stuff for a little under fifteen years, been writing C++ for just shy of ten, and been using .NET for around five. I've written language parsers in C++ and compiler code in .NET--in other words, I do, in fact, know my shit. It is evident that he does not, and when he tries to mimic knowledge and expertise he does not have, I will most definitely call him out on it. Sorry if that upsets your little world, but dishonesty--willful and intentional dishonesty--is unacceptable.

[Outcast Orange]

Do you have any examples of things you've done?

I can honestly say I've been programing for eight years.
You would laugh at all the things that are technically true.

[Blacken]

Do you have any examples of things you've done?

Uh, yes? My most recent project is a goddam thread on here.

Other projects (chosen mostly because there are links to them) include Summer of Code 2007 (morons decided to "rewrite it in Python" the next year, but that's not my problem) and Summer of Code 2008 (which was the project that preceded Novell's MonoVS project). I wrote a 45,000-line MUD codebase in C++ from scratch (2004-ish--what a fucking mistake) and maintained and heavily expanded a C/C++ CircleMUD clusterfuck over the course of two years (2006 to 2008--even bigger mistake). More recently I've written an automatically scaling enterprise-level cloud application in PHP/PostgreSQL, though it isn't available for public consumption as of yet, and numerous code-to-order gigs as part of running my consulting firm.

(I'm also currently in discussions with two Fortune 500 tech-focused companies to come aboard as a developer--which you don't get without demonstrable and excellent chops. Hint: one begins with a G, rhymes with "frugal," and they flew me to San Francisco last week.)

I've written code from servers to mobile devices and at most levels of scalability; I've almost certainly written more C++ over a significantly longer time than the people here who frigging worship it. It's a tool, and while it has its place, that place is rapidly shrinking as modern toolkits supplant it.

[qwertyuiopas]

...

ANY language with function overloading - or worse, operator overloading - is a disaster waiting to happen. With minimal use and a very good guide, it is not a problem, but with 20 ways to make an object, half of them applicable to your task, and "help" that does very little to assist you, or when + starts acting differently depending on the order of operations (should I put the classC or the classN object first?), then someone doesn't understand that simplicity is usually best in those cases. C++, .NET, even many other recent languages all allow this, and most of them make the mistake of overusing such features.

Now, here is a nice feature to put in an editor:
Be able to identify overloaded operators, colour-code them, and then make the tooltip text show what class overloaded it! Bonus if you can navigate to the declaration of the overloading from the right-click menu!

Finally, notice I said "C", and not "C++"? Yes, I use "C" to mean "C", and not "C, C++, C#, or some other similar language". Because C has *one* set of argumentss to any given function, so you don't have to worry if you should be passing a string or a system.uri. If you want multiple argument sets, you make a new function.

glVertex2f?
glVertex3i?
glVertex3ub?
glVertex2dv?

Same function, different arguments. And clearly shows the arguments in the name itself. And, it is *consistant* across the entire OpenGL API. If all of thosse were overloaded glVertex2() and glVertex3(), fewer languages could use them, you would have to explicitly cast values, and you would have to look at the source of the values to understand what version of the function was being called. If they are members of a structure, you have to find the correct header file, browse to the structure, and look at the types of the values. And God help you if there is a structure within a structure, now you have to do *two* lookups, possibly in entirely different files, just to understand one fnction call. Oh, and if the types were #defined elsewhere, you have to find those as well...

Read this. Finding the right set of arguments is just one extra sub-step but it adds up.

(3 posts later)

I have the experience of trying to work with the WebBrowser control in VB for a few hours, and getting absolutely nowhere just because they tried to make it do everything however you wanted with whatever arguments you passed, and made a mediocre interface, rather than trying to do everything one way, and do it exceptionally well. The greatest pitfal of OOP is when it encourages you to try to make everything work everywhere.

You do not have that experience, and are thus unqualified to dispute it.

Specifically, I wanted to get input from the user between a few pages, then navigate to that page and not navigate away. It would work correctly if I set the URL in the GUI editor's property sheet, but changing the url from the code to respond to the user's input just didn't work. Rather than understand why(due to their inability to fully explain every variation of every function, since they over-overloaded them), I attempted to get it to work through multiple different sequences of instructions, and *none* of them worked.

If I had researched how to use COM in C, I would have asked the user then created the browser with the URL preset, but because this was VB, and a pre-created windows form, I didn't want to, and likely couldn't without days of research, learn how to create a new WebBrowser after getting input, and I couldn't even guarentee it would work. If there is a clear way to accomplish your goal, and the manual clearly describes how things should work, then you know when something is wrong, and can find out what to do. Otherwise, you will seek alternative methods even when they will fail anyway, because you don't know that they will. In the end, I simply made a new project for each page, but I cannot be fully content with such a workaround to an inherent flaw of OOP and documentation. Now, you can probably tell me "Oh, you just had to set option X before changing the URL", and you would probably be right. But did MSDN say that? Certainly not! And MSDN should have, but didn't because they just assumed that everyone could comprehend among their countless overloads what one has the right parameters for the current task. I'm sure that Python would probably have been as simple as "new browser; disable navigation; browser.goto(page)", or some other language, but .NET does *not* want you to find the easy way on your first attempt. MAybe non-windows .NET does, and it probably has proper documentation, too, but the default .NET that comes with the downloadable VB doesn't.

[Blacken]

It's funny how he tries to claim that I have "no experience" with System.Windows.Forms.WebBrowser when the second project I linked above (GSoC 2007) used it, and did active DOM manipulation and event raising from within .NET as well. And it worked just fine. Absolutely fucking trivial to do, really--I was still something of a newbie to .NET and yet it took maybe an hour for me to wire in everything I wanted. When you actually read the documentation, instead of screeching that oh it's so complicated and hard, it gets done in short order.

Yes, there's a lot of stuff to the interface of many .NET classes. Most of it you don't have to use. Having more options for when you do need to use it is only a negative if you can't actually focus on the task you want to accomplish. Or, in other words, PEBKAC. Spend some time actually learning how to do what you want to do instead of screaming that it doesn't work the way your preconceived notions think it should, and you'll be fine.

Ha ha. Funny. Laugh!



If you seriously think C's glVertexX is a good API when overloads are trivial to iterate through in any sort of modern IDE (yes, modern programming is harder to do when you refuse to use the tools available to you, so don't refuse to use them), I don't even know that to say--it's a terrible, terrible result of not having good enough tools in the first place and making foolish decisions because of it. Modern GL wrappers, like OpenTK, turn those idiotic glVertexX calls into overloaded functions, and it makes reading the code simpler and easier. Continuing to use stone knives when power tools exist is not noble, smart, or worthy of respect. All C's method does is bloat the function list for no good reason. I mean, for fuck's sake: this is the future. If you don't suck at programming you're capable of figuring out what overload you actually want. Maybe three presses of the up and down arrows will get you there for most overloaded functions. This is so transparently Not A Big Deal.

I agree with you to an extent re: operator overloading, which is why I'm very glad .NET doesn't overuse it. It's used for string concatenation and event subscription and...well, that's about it, even avoiding places where I wish they did it (the Drawing namespace, for point/vector stuff) they generally avoid it. Operator overloading is a method of increasing readability when done well, and decreasing it when done poorly; the obvious solution is to not do it poorly. Which C++ does not do (">>" for streams? really?) and .NET does fairly well. Also, VS allows you to do exactly what you said re: overloaded operators in .NET. Just hover over it and you get a tooltip; click it and press F12 and it takes you to the function definition. It probably does in VC++ too, but I don't have a project around that implements it.

[Willfor]

Blacken stole my thunder, but since I was already in the middle of making an illustrated example; This is something I've been playing around with that it turns out I didn't need at all, but it illustrates the point nicely. I think.

Spoiler: "Illustration" (click to show/hide)

[Blacken]

Haha. Nice, Willfor. Go To Definition is the best tool ever featured in any IDE ever. Ever.

And you can see how really, really nasty function overloading has to be. OH MY GOD YOU HAVE TO PRESS THE ARROW KEYS TO GO THROUGH THE LIST OF OVERLOADS WHATEVER SHALL WE DOOOOOOOOOOOOOOOOOOoo

[Virex]

To get back to the OP's question;


When choosing the language you're going to use, you should factor in a few things. First of all, what do you know? You are schooled in VBasic, so you'll probably want something with a similar syntax (trying to learn Lisp when you're used to a C-like syntax such as Vbasic uses can be mind-bending because nothing makes sense. On the other hand, you may have no problem with it, so don't let me scare you).


Secondly, what are you going to use it for? If your program is high-end, you'll need a language that makes it easy to optimize for speed. This means that Ruby might be a poor choice, because although it is possible to optimize Ruby for speed, such optimizations are harder then when you're using an "intrinsically fast" language such as Perl, or a language that has highly optimized interpreters such as Java.


On the other hand, there's the readability and ease of programming, which weigh higher the less you need to optimize for speed. If speed is of a lesser concern, languages like Python and Ruby become more attractive, because getting a bare-bones program to run in them is usually easier then in for example C++ and you don't have to take much care of optimization and interpreting is generaly faster then compiling, meaning you get your results faster. As you already know Vbasic, that also becomes an option in this case. I already mentioned Lisp, saying the syntax might break your mind. If it doesn't, you might consider it because it gives you direct access to the guts of your program (and the guts of the compiler for that matter), making code prototyping easier.