Print

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

[Supermikhail]

Well, at least you didn't call me names.
For me the main advantage is that it's easy to do graphics with Object Pascal (or the common IDEs, I'm not sure). Also, I could never make timers in C or C++ work right. Obviously, I haven't programmed much or deep.

[Karantza]

My experience with languages is this: what you intend to do is far more important than the features of the language. If you plan on writing something that makes heavy use of C++ libraries, write it in C++. If there are better libraries for .NET or Java, use those languages.

Managed vs unmanaged factors in a little, but even for bleeding-edge games your bottleneck isn't going to be in function calls, it'll be in math and GPU calculations, both of which are unaffected by JIT vs Native compilation. I'd always go with the language that, in order of priority, a) has the best libraries that mean I have to reinvent less stuff, and b) is easiest to work in.

If I'm writing code for a microcontroller, or a driver, or a low-level API, I'll choose C (and get as close to ANSI as I can.) No real need for extra libraries, not a lot of architecture, and having the responsibility of managing memory is likely necessary.

If I'm writing a GUI application, I'll pick something with good GUI support - probably C# with Winforms or WPF. GUIs also tend to use COM a lot, and .NET handles COM a lot nicer than C++ (with or without ATL). Plus if you target 2.0, Mono still lets you be all crossplatformy.

If I'm writing a scientific application, or something for school involving lots of linear algebra, simulating differential equations, etc, I'll probably use Python. They've got so many libraries dedicated to math and visualization, it'll be a much nicer environment to work in. If I really wind up needing something faster, I'll write a component in C. Or find a Python library that already does that.

If I'm writing a game, I'll probably choose between C++ and C#. It used to be that all the good libraries were in C++ (and to an extent this is still true), though I've seen lately some wrappers for OpenGL, OGRE, physics libraries... even some direct ports of the aforementioned (writing all your code in C# tends to be faster than calling into native code frequently). So I'll probably start a little project to experiment with these C# libraries soon.

[Muz]

If I'm writing a scientific application, or something for school involving lots of linear algebra, simulating differential equations, etc, I'll probably use Python. They've got so many libraries dedicated to math and visualization, it'll be a much nicer environment to work in.

I think most people use MATLAB for scientific applications. It does piles of work in half an hour. Not free, but if you're doing something complex enough to warrant its use, you probably have someone financially backing you. Best language to prototype, IMO.

[Blacken]

If I'm writing a scientific application, or something for school involving lots of linear algebra, simulating differential equations, etc, I'll probably use Python. They've got so many libraries dedicated to math and visualization, it'll be a much nicer environment to work in.

I think most people use MATLAB for scientific applications. It does piles of work in half an hour. Not free, but if you're doing something complex enough to warrant its use, you probably have someone financially backing you. Best language to prototype, IMO.

It depends what you need it for. MATLAB is an excellent first-pass tool, but for programs that are going to be used over the long term it can often be a win to reimplement it in Python/C/whatever.

(They still use a shitload of Perl in biology/genetics, too.)

[Karantza]

I've used Matlab for lots of signals stuff, and I've heard good things about Maple's analytic solver. I'm talking more like, simulations and realtime visualization. Matlab is great for working with big sets of numbers, but python is a little more flexible. (Edit: I also had a professor that insisted on doing *everything* in Matlab. Kinda scary. That may have soured my taste for it a little.)

And yes, I've written my share of Perl for string manipulation; I'm not a biologist, but I suppose if you've got a terabyte long string of "AATAGCCT", perl's your go-to man for that.

I think the biggest point I can make is to not get religious about your software choices. Languages and development environments change all the time; many have different priorities and use cases. Figure out what works best, and then use it, to hell with the fanbois.

[qwertyuiopas]

Yes, I know that, but for comparison, it would have been easier and faster for me than trying to get the same result in VB.
Poor documentation and no hints as to why it shouldn't work, when it looks like it should.

But is that telling us facts about VB (or C#, or even C++, or any other language that does COM better than C), or just facts about you?

At least with COM, there is no operator overloading(Binary standard, remember?), so that would be one major quagmire fewer, furthermore, the compiler didn't generate the window generation, so I would have had the control of how it works to generate it later as if it were still window creation time.

C and C++ make operator overloading unavoidable. So does VB, for that matter. When you understand that, you'll understand why it's a good thing.

(Every VB form is full of COM/OLE, and you don't need to care about it, as the compiler does it all for you...)

Which certainly makes your C recommendation look peculiar.

What paralell universe did you wake up from? C never has, except by obscure nonstandard extension, had operator overloading. This shows that you see C as the C family of languages, not as the language called C, or haven't worked with it in a while. Or maybe just forgot. Or use some library or something. Simply: + is always the same + is C.

As for everything else, I am stating that for me, it would have been faster to work with COM directly than work with MSDN in the specific area of understanding the WebBrowser component. Not because I can't understant it, but because it does not fully detail how anything works, or why it might not(This one should be in every reference, but rarely is. MSDN has less of an excuse than most others, because of the community component).

[Normandy]

I'm kind of lost in the dark here, I'm not quite sure what COM is. I understand that it is some sort of cross-process data/memory management scheme standard so that programs can used shared memory resources, somewhat like how DLLs work (different programs referencing the same symbols in another part of the memory). Is this understanding correct?

[Blacken]

What paralell universe did you wake up from? C never has, except by obscure nonstandard extension, had operator overloading. This shows that you see C as the C family of languages, not as the language called C, or haven't worked with it in a while. Or maybe just forgot. Or use some library or something. Simply: + is always the same + is C.

This is demonstrably false. "int + float" takes a different code path than "int + int". The operator is overloaded because a different function is called for the same syntactic construct. That end developers cannot leverage this does not mean that overloading does not exist, and demonstrates a failure on your part to think through the consequences of "NO OVERLOADING EVARRR."

And I'd like to echo DrPizza in pointing out that the standard C library does overload functions.

I'm kind of lost in the dark here, I'm not quite sure what COM is. I understand that it is some sort of cross-process data/memory management scheme standard so that programs can used shared memory resources, somewhat like how DLLs work (different programs referencing the same symbols in another part of the memory). Is this understanding correct?

COM is a system designed to allow the usage of objects that can be used in environments other than that within which they were implemented. Think of it as a predecessor to something like local WCF - a self-contained (...mostly) protocol and system for disparate systems to talk to each other on the local machine.

[qwertyuiopas]

Okay, maybe I can be clearer:

C doesn't have overloadable operators, meaning that people too stubborn to change how they think are completely unable to make >> the operator used to multiply the character pairs of two strings, or other equally worthless and confusing tasks. Similarily, if it does support function overloading, I see no way that it can be accomplished by someone who has read one too many OOP guide by someone who doesn't understand what they are writing about, but they do know that it makes money.

Fortunately, I don't know of any of those kinds of people, and hopefully they don't and have never existed, but I really don't have that much faith in humanity's intelligence...

[Blacken]

I actually dislike stream I/O being done with >> and << at least as much as you do. But you can't deny that function overloading is not an effective tool for adding readable, simple functionality. I mean, just today I wrote an overload for the + operator to add together vectors and return a result, because "v1 + v2" is simple, mathematically well-known, and consistent with the behavior of the "+" operator in the first place.

I mean, sure, people can abuse them. Morons abuse C all the time and write absolutely dangerous code. Do we take that away too?

[DrPizza]

What paralell universe did you wake up from? C never has, except by obscure nonstandard extension, had operator overloading.

Oh really?

So 1.f + 1.f emits the same instructions as 1L + 1L, does it? The same as (((int*)0) + 1L)? What's that you say? No it doesn't?

Well I hate to break it to you, but that's an operator that has been overloaded. It does different things in different contexts, depending on the arguments it is used with. It might do floating point addition, it might do integer addition, it might even do weird pointer addition, where the arguments are mismatched (one is a pointer type, one is an integral type) and the arithmetic is weird (since it uses increments of the pointed-at type). That's an overloaded operator.

There are languages that do not do that. ocaml is one. In ocaml, integer addition uses +. Floating point addition does not. It uses +. instead. So C certainly isn't overloading operators due to necessity. It's doing it solely out of convenience. The fact is, it's useful to have "+" do the right thing in an argument-dependent way.

This shows that you see C as the C family of languages, not as the language called C, or haven't worked with it in a while. Or maybe just forgot. Or use some library or something. Simply: + is always the same + is C.

Except as I've demonstrated, that clearly isn't true.

Similarly, C99's <tgmath.h> provides function overloading.

Now, you might argue that C supports no user-defined operator overloads, and no user-defined function overloads. That's mostly true (I say "mostly", because varargs functions could be used to provide a similar feature, albeit with runtime dispatch rather than compile-time dispatch). But I never said anything about user-defined.

And why are user-defined operator and function overloads even a bad thing? Since we've already established that you cannot tell what C's "+" operator does without knowing the types of the operands (without knowing the operands, we know only that it does something addition-like; we do not know the exact nature of that addition), why should we not extend that "ambiguity" to user-defined types? Why should we not be able to use "+" with, say, our own vec3 class? If such a capability is good enough for C's designers--and it is--why is it not good enough for everyone else?

[qwertyuiopas]

...

Due to clarifications, I realized that I was wrong, because I forgot about the ones as part of the compiler.

See here:

Okay, maybe I can be clearer:

C doesn't have overloadable operators,
...

Also:

If such a capability is good enough for C's designers--and it is--why is it not good enough for everyone else?

Probably because everyone else can't be trusted to use common sense during every singe moment of their lives. They might not realize when it complicates things, seeming perfectly natural(I didn't even consider that different numeric types had different math operations...), or for any other reason, but the only way I see operator overloading working in a way that doesn't confuse people is if it, by design or closely maintained common sense, only overloads operators to do similar things to the original. Incrementing an iterator may seem the perfect place for ++, but is it really going to be more obvious than .increment()? I see the function call as a reminder that it is a class, and that it does use a function at that point, something especially important to remember if there were any side effects to that function... Although, someone with more experience could probably point out an area where disguising it makes perfect sense...

[Siquo]

I love overloading operators.

Special containers that can be accessed with [], mathematics done on complex numbers, vectors, and pixels, vertices, string operations for output (ScreenLog += "New log line"), they are awesome. Why? Because C++ in itself sucks to write, it makes stuff easier to write and read, and I am the sole programmer in my projects so I can do what the F I want

[Blacken]

If such a capability is good enough for C's designers--and it is--why is it not good enough for everyone else?

Probably because everyone else can't be trusted to use common sense during every singe moment of their lives. They might not realize when it complicates things, seeming perfectly natural(I didn't even consider that different numeric types had different math operations...), or for any other reason, but the only way I see operator overloading working in a way that doesn't confuse people is if it, by design or closely maintained common sense, only overloads operators to do similar things to the original. Incrementing an iterator may seem the perfect place for ++, but is it really going to be more obvious than .increment()? I see the function call as a reminder that it is a class, and that it does use a function at that point, something especially important to remember if there were any side effects to that function... Although, someone with more experience could probably point out an area where disguising it makes perfect sense...

Why are you giving people pointers, if they can't be trusted to use common sense during every sing[l]e moment of their lives? They might segfault or write into the wrong areas of memory. Why are you letting people use #defined macros? They might do something horrifying like MAX(a,b) which doesn't properly evaluate with side effects (but appears correct). Why are you letting people emit shell code via system()? "They might rm -rf ~". Why are you using C-strings instead of building in a rigorous string system? Shit, this is one of the biggest failings in C and the cause of no end of security problems.

People are, yes, generally complete and total morons when it comes to writing code. There comes a point where you have to say "okay, we can't help them anymore, let's give the people with a clue the tools that will benefit them."


Granted I work in an environment where everything is a class far more often than I do anything else, but I am not clear on why you care if it's "a class" or not. That doesn't matter. It's a data type. Some data types have functions attached to them. Others don't. Overloadable operators are just a context-sensitive way of expressing a function--if they are misused it creates logically inconsistent or incoherent problems, but that's the case with anything.

I can rename "add" in my list class to "remove," and it's still a valid class. It's just stupid.

[DrPizza]

Probably because everyone else can't be trusted to use common sense during every singe moment of their lives.

So get rid of manual memory management. Bounds check arrays, garbage collect to prevent stray pointers, prohibit pointer arithmetic. Because more time, money, and data have been lost due to programmers not using "common sense" with C's pointers (and their retarded cousins, C arrays and C strings) than have ever been lost due to operator overloading.

Seriously, you're saying that regular programmers should be denied the ability to do things that the language designers can do, and yet you're advocating C? That's incoherent.

They might not realize when it complicates things, seeming perfectly natural(I didn't even consider that different numeric types had different math operations...), or for any other reason, but the only way I see operator overloading working in a way that doesn't confuse people is if it, by design or closely maintained common sense, only overloads operators to do similar things to the original.

I don't agree. I think the operator overloading used in e.g. boost::spirit is perfectly sensible and legitimate.

Incrementing an iterator may seem the perfect place for ++, but is it really going to be more obvious than .increment()?

Yes. "++" is how C++ spells "increment". Using the operator also enables generic programming to treat iterators and pointers as equivalent. In fact, some iterators are pointers.

I see the function call as a reminder that it is a class,

But why do you care?

and that it does use a function at that point, something especially important to remember if there were any side effects to that function...

Why? If you need to increment a pointer, are you really going to stop and consider "hmm, this increment() thing is a function, it might have side-effects"? Why? What difference does it make? It's not like you can say "I don't want the side effects so I won't call the function after all". The side effects are a complete irrelevance. After all: the increment itself is a side effect. Since you can't decouple them, you've just got to go ahead and accept them.

Although, someone with more experience could probably point out an area where disguising it makes perfect sense...

Yes; templates.