Print

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

[Blacken]

Let's reiterate: Java isn't interpreted (except on really gimpy platforms that he's obviously not using). Java is JIT-compiled, as is .NET. Both can be (and often are) precompiled as well.

For the majority of tasks, Python/Psyco, Java, .NET, etc. are so close to native code performance that worrying about it is absolutely nonsensical. And if you hit those edge cases where you do need that performance, you can drop down into native code via Python importing, JNI, P/Invoke and marshalling, etc. when you need it instead of slumming at that level throughout your codebase.

[Virex]

Let's reiterate: Java isn't interpreted (except on really gimpy platforms that he's obviously not using). Java is JIT-compiled, as is .NET. Both can be (and often are) precompiled as well.

Thanks for correcting me there. I got the impression that Java is usually JIT-compiled though.

For the majority of tasks, Python/Psyco, Java, .NET, etc. are so close to native code performance that worrying about it is absolutely nonsensical. And if you hit those edge cases where you do need that performance, you can drop down into native code via Python importing, JNI, P/Invoke and marshalling, etc. when you need it instead of slumming at that level throughout your codebase.

While it doesn't matter much in most applications (and certainly not in the OP's case mind you), the JIT-compilation of Java and .NET, as well as the interpretation of Python/Ruby can and often do add some additional overhead, which makes it less suited for very intensive programs without invoking additional code to compensate for that, which are the methods you describe. It is very possible to attain high performance, it just takes some extra work compared to "natively fast" languages such as C or assembly (the fastest you can get without going into bytecode)


However, C's additional speed comes at another price. The reason C and it's brothers are generally so fast is because it does nothing behind the scenes, while for example Python handles a lot of garbage collection, type checking et cetera behind the scenes. This means that with the "slower languages" you usually don't have to worry about catching type exceptions and proper cleanup of loose wathervers that are floating around, making programming faster and less error-prone (you still need to be aware of it, because you can always cause exceptions the compiler/interpreter doesn't catch). However, that means that to get as fast as possible you sometimes need to override those checks and balances. In the end that means extra work compared to a properly designed C program. Hence me saying that it is possible to get Python as fast as C (at least within a very close margin) but you'll need to do some extra work for it. On the other hand, with C you'll need to do extra work to prevent it from screwing your program over.

[DrPizza]

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

That's nonsense, of course, as long as we're talking about Turing-complete languages. They're all equally capable; what varies is how different tasks are expressed.

Some languages give you high-level constructs to make expressing ideas more direct and straightforward. C does not.

C does not tell you "this is impossible". It just tells you "the only way to express this will be complicated and baroque".

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.

If the only overhead C imposed as a bit of boilerplate, the world would be a much better place.

Standard C challenge: write a program that asks the user to type in their name, reads in their name (i.e. whatever text they enter on the keyboard, up to a newline), and then writes back a message saying, say, "Hello <name>" (where <name> should obviously be replaced with the name they entered). A pretty basic task; so write a program that uses only standard C, and which is correct.

[DrPizza]

ANY language with function overloading - or worse, operator overloading - is a disaster waiting to happen.

Then why are you advocating C?

C has both function and operator overloading.

The only even vaguely mainstream language I can think of off-hand that truly has neither is ocaml (and even that has an awkward corner, in that < and other comparison operators are, I believe, technically overloaded rather than just operating on interfaces. I would have to check, which I don't care enough to do).

[Virex]

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.

If the only overhead C imposed as a bit of boilerplate, the world would be a much better place.

Standard C challenge: write a program that asks the user to type in their name, reads in their name (i.e. whatever text they enter on the keyboard, up to a newline), and then writes back a message saying, say, "Hello <name>" (where <name> should obviously be replaced with the name they entered). A pretty basic task; so write a program that uses only standard C, and which is correct.

I thought C added string support to the standard library some time ago? Or am I sorely mistaken here?


Also, function and operator overloading can come in handy at times, especially when you're not sure what kind of data the end user is going to feed into the function in the first place (You could of course add ways to handle that within the function or tell your user not to do that, but handling it gracefully trough overloading is a useful option too)

[ThreeToe]

Enough personal insults.  I don't want to hear about who's stupid etc.  I'm getting a lot of reports about this thread and I don't want to start handing out warnings.  Please be nice.

[Blacken]

I thought C added string support to the standard library some time ago? Or am I sorely mistaken here?

C added array-terminated-with-a-\0 support a very long time ago. This isn't really a "string" in the sense of most other languages.

There are ways to write "real" strings in C, but they are clunky.

[qwertyuiopas]

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.

If the only overhead C imposed as a bit of boilerplate, the world would be a much better place.

Standard C challenge: write a program that asks the user to type in their name, reads in their name (i.e. whatever text they enter on the keyboard, up to a newline), and then writes back a message saying, say, "Hello <name>" (where <name> should obviously be replaced with the name they entered). A pretty basic task; so write a program that uses only standard C, and which is correct.

The use I would have had would have had the only input in the form of a two-state sytem, where in the first it will respond to mouse clicks by transitioning into the second if the user clicks in one of two rectangles, and depending on the rectangle, one or the other preset string will be passed as initialization of stage two, and that would be the creation of a WebBrowser COM object, that would be the entire interface(and thus all input handled by external code), and then simply exiting when the user closes it.

With the only input being handled by a numeric input passed by windows along with WM_LBUTTONDOWN, the hidden pitfalls where code can fail during text input would be entirely irrelevant. The rest would be fairly standard procedure for the creation of a control at run-time.

[DrPizza]

Good answer (not).

It is a rare program that never has to perform any kind of string manipulation.

And COM in C... what a fantastic idea. Yes, you can do it. But that doesn't mean you should.

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

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.

The problem is not finding the best way to do it, the problem is finding a way that works when the documentation fails.

In this case, no string manipulation would have occured, only passing and selecting constant strings.

And to get somewhat back on topic:
I wouldn't reccomend COM in C either, unless you want to understand how COM works on a level that is best described as the "dug too deep" of 2d DF. In fact, I wouldn't reccomend COM at all, unless you understood what it was and why it was the right tool, and were using it in a decent language for that kind of thing. Ignoring the cases where you don't need to know that it is being used, of course(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...)

[DrPizza]

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.

[Siquo]

Yay, I started it! 

Sorry ThreeToe. And sorry, OP. These guys have these big red buttons just begging me to push them. And then they start pushing eachothers and it spirals into Language War. Happens every time, don't worry about it.

[Supermikhail]

Hey, guys are you going to call me names if I say that I'd like to one day program a game in Object Pascal? because it's the first language I've programmed in and actually achieved some result, partially due to the nature of the text book I used.

[Rose]

Personally, I would do it in C++, but that's because it's the one I'm actually familiar with.

[Blacken]

Hey, guys are you going to call me names if I say that I'd like to one day program a game in Object Pascal? because it's the first language I've programmed in and actually achieved some result, partially due to the nature of the text book I used.

Object Pascal is fugly, but at least it is generally well-thought-out. I used to use what is now Embarcadero Delphi pretty regularly.