Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!


How Languages Compare?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
37 replies to this topic

#21 Karsten_   Members   -  Reputation: 1645

Like
1Likes
Like

Posted 14 November 2013 - 06:47 PM

struct DeadPlayer {
     Player player;
     Point deathLocation;
}

Now, you write methods that take a DeadPlayer* as their first argument (and observe, you can pass DeadPlayer pointers to all methods that expect a Player).


Nice example.
Usually a fairly junior C# or Java developer will jeer at C because they don't realize or understand how this works. This is how Gtk+ (and many object-orientated C libraries) does it and demonstrates that C is pretty darn flexible.

Edited by Karsten_, 14 November 2013 - 06:51 PM.

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.


Sponsor:

#22 Paradigm Shifter   Crossbones+   -  Reputation: 5410

Like
2Likes
Like

Posted 14 November 2013 - 07:37 PM

Automatic enforcement of initialising stuff is good in C++ though (in C, you don't want to forget to call an init/deconstruct method).

 

But most things you can do in C++ you can do in C, although C's version of templates via macros is not good ;)

 

C makes you write a lot of boilerplate code and get it right which C++ shields you from.


"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#23 Yrjö P.   Crossbones+   -  Reputation: 1412

Like
0Likes
Like

Posted 15 November 2013 - 07:57 AM

Almost any piece of high level C code can be improved by applying C++ techniques. References, generic algorithms, lambdas, constexpr, smart pointers, move semantics etc. are all really nice. You don't need to write object oriented code to benefit from C++.

Just the fact that C++ has a good assortment of standard containers is a huge leg up on C. If you are working in C, you'll be using containers from some 3rd party library, or have rolled your own from scratch with great time expenditure and possible quality issues, or you are effectively hamstrung by lack of appropriate tools.

#24 Mercury Filter   Members   -  Reputation: 316

Like
0Likes
Like

Posted 15 November 2013 - 09:07 AM


Almost any piece of high level C code can be improved by applying C++ techniques. References, generic algorithms, lambdas, constexpr, smart pointers, move semantics etc. are all really nice. You don't need to write object oriented code to benefit from C++.

I hate to nit-pick (ok, I actually love to, it seems very effective in terms of learning), but isn't it a bit misleading to refer to genetic algorithms and lambdas as being C++ techniques? Correct me if I misunderstood what you were saying but the statement seems to associate those techniques with C++, while I am pretty sure the two I mentioned existed before it did. I could not say about the others, as I am less familiar with them, and I am not very familiar with those two in the first place.



#25 Paradigm Shifter   Crossbones+   -  Reputation: 5410

Like
0Likes
Like

Posted 15 November 2013 - 09:26 AM

Lambdas were LISP (acronym for: Lots of Irrelevant Superfluous Parentheses <- j/k) originally I think.


"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#26 ryt   Members   -  Reputation: 294

Like
0Likes
Like

Posted 15 November 2013 - 11:01 AM

A lot of you guys say that with C you can do all the stuff that you can with C++. Its true, but than you could say with assem or binary you can do the same things that you can do with C++. So how much time would it take to build something ? I think C++ saves you a lot of time.


Edited by ryt, 15 November 2013 - 11:03 AM.


#27 Mercury Filter   Members   -  Reputation: 316

Like
0Likes
Like

Posted 15 November 2013 - 12:36 PM

What I am really taking out of this is that it is a "toolbox" type issue. Everything has strengths, everything has weaknesses. I certainly did not ask the question with the goal of trying to crown the king of languages. I wanted to know what are some positive points of the two, unfortunately I used some questionable wording. I have found a lot of these posts to be quite informative. I am guessing that no matter who you ask, they are always going to have a personal preference (a very strong one in some sometimes, probably), and I can see a bit more why I was warned by Winfield that such a question can incite a holy war. Thanks everyone, for maintaining civility on such a topic, since there was some pretty good information to be had.

The current view I am going to go forward with is that based on responses, and on other threads that I have read as well, my best bet is probably just choosing and sticking to a language for the time being (that one seems to have been reiterated in numerous places). Not that I was really questioning that it was the best thing to do, nor trying to get help choosing. Just wanted to try and learn a bit more about the two, and I would say that goal was achieved.

 

Although everything that I stated above is meant sincerely, I feel a bit too much "after-school special" seeping into it.....the cynic in me feels quite ill, but thanks for the information, again.



#28 RobTheBloke   Crossbones+   -  Reputation: 2349

Like
2Likes
Like

Posted 15 November 2013 - 05:36 PM

A lot of you guys say that with C you can do all the stuff that you can with C++. Its true, but than you could say with assem or binary you can do the same things that you can do with C++. So how much time would it take to build something ? I think C++ saves you a lot of time.

 

You know what? Who gives a damn about the language. A programming language doesn't automatically make a specific programmer more or less productive because he/she now has access to language feature 'X' or 'Y'. Software development is about the approach *you* take to ensuring that your code is stable, maintainable, and efficient (where necessary), and in this, fundamentally C++ doesn't save you any time over C/C#/Python/Lisp/ASM/Whatever (I say this as someone who actually uses C++ for most things, and C#/python/lua/mel script/max script for the rest).

 

I could write a code generator in 5000 lines of lua that spits out 5 million lines of C. That would make me significantly more productive than a programmer who spends 3 months writing 3 million lines of bug ridden C++. Programming is about the thought process you go through to solve a particular problem. A programmer who claims 'language feature X makes you more productive', is in my experience, the kind of programmer who will turn to face their goal, and then run a marathon to get there. Walking barefoot to the taxi rank round the corner, is normally a better solution than debating which pair of running shoes is faster. 

 

Almost any piece of high level C code can be improved by applying C++ techniques. References, generic algorithms, lambdas, constexpr, smart pointers, move semantics etc. are all really nice. You don't need to write object oriented code to benefit from C++.

Complete and total bullshit. If I have a working piece of C code, it sodding works! Changing the interface (cos references, lambdas, and smart pointers, are cool lolz!), just forces you to:

Change the documentation
Modify the unit tests

Modify every place where that code is used. 

Fix up any bugs which you *will* have added.

Verify that those languages features work as intended on every single target platform
 

It's a fool's errand. Work smarter, not harder. 



#29 Yrjö P.   Crossbones+   -  Reputation: 1412

Like
0Likes
Like

Posted 17 November 2013 - 05:53 AM

Almost any piece of high level C code can be improved by applying C++ techniques. References, generic algorithms, lambdas, constexpr, smart pointers, move semantics etc. are all really nice. You don't need to write object oriented code to benefit from C++.

I hate to nit-pick (ok, I actually love to, it seems very effective in terms of learning), but isn't it a bit misleading to refer to genetic algorithms and lambdas as being C++ techniques? Correct me if I misunderstood what you were saying but the statement seems to associate those techniques with C++, while I am pretty sure the two I mentioned existed before it did. I could not say about the others, as I am less familiar with them, and I am not very familiar with those two in the first place.

They aren't C++ inventions, but I wasn't calling them as such. According to the topic of the thread, I was comparing C++ to C. C++ has language support for the things mentioned, while C does not.

Also, it's "generic algorithms", not "genetic algorithms".

#30 Yrjö P.   Crossbones+   -  Reputation: 1412

Like
0Likes
Like

Posted 17 November 2013 - 06:09 AM

A programming language doesn't automatically make a specific programmer more or less productive because he/she now has access to language feature 'X' or 'Y'. Software development is about the approach *you* take to ensuring that your code is stable, maintainable, and efficient (where necessary), and in this, fundamentally C++ doesn't save you any time over C/C#/Python/Lisp/ASM/Whatever (I say this as someone who actually uses C++ for most things, and C#/python/lua/mel script/max script for the rest).

I could write a code generator in 5000 lines of lua that spits out 5 million lines of C. That would make me significantly more productive than a programmer who spends 3 months writing 3 million lines of bug ridden C++.

This example has nothing to do with your (faulty) assertion that languages do not matter. You'd be far more productive when writing your code generator in Lua than when writing it in assembler. That's because in comparison to assembler, Lua has many more features that help you get the job done. It boggles my mind that you'd even try to claim otherwise.

Complete and total bullshit. If I have a working piece of C code, it sodding works! Changing the interface (cos references, lambdas, and smart pointers, are cool lolz!), just forces you to:

Seriously weird strawman argument. If you have 100% perfect, 100% efficient C code that never needs to be changed again, then sure, you don't want to go in and change it for any reason. But I didn't tell anyone to do that. Rather, I'm saying there are benefits from writing the code in C++ in the first place, even if the code is not object oriented, and even if it mostly looks like C.

#31 Mercury Filter   Members   -  Reputation: 316

Like
0Likes
Like

Posted 17 November 2013 - 02:59 PM


They aren't C++ inventions, but I wasn't calling them as such.

I did not really mean to say that was what you meant so much as I was questioning the wording because I felt that it could make it a little confusing as to the origin of such techniques. I did indeed misread generic as genetic. I did a little reading, and have a bit of a question on that. From what I have seen, with generic algorithms, it seem that we are talking in terms of templates, essentially. While I am guessing that there would be good reason not to do this, would it be possible to implement something similar to templates via unions in C? Perhaps I am thinking along the wrong lines, and it may be something that would be ridiculous amounts of work to build something that is handily available elsewhere, or some other technique can take the place of. Primarily, I just wonder as to the possibility as a matter of curiousity.



#32 Paradigm Shifter   Crossbones+   -  Reputation: 5410

Like
0Likes
Like

Posted 17 November 2013 - 03:08 PM

unions aren't the same thing as templates.

 

You can do something similar by writing complicated macros using the token pasting operator ## to build new names out of the macro arguments (e.g.

 

#define DEFINE_CREATE_LIST(type) type* CreateListof##type { /* code goes here, need to be all on one line or extend line using \ */ }

 

so when you use DEFINE_CREATE_LIST(int) it pastes a function definition called CreateListOfint into the source. You need another macro to create a list of pointers though. And it is nasty code templates much nicer (although the syntax is hairy).


"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#33 Mercury Filter   Members   -  Reputation: 316

Like
0Likes
Like

Posted 17 November 2013 - 03:12 PM

Sorry, I realize that they are not the same, I was just asking if there was some roundabout, not necessarily sensible way that you could massage similar behaviour (the part about accepting different types), and create something similar. I realize that it may make no sense to actually do that, just wondered if it would be possible.

 

It may also be that I am misunderstanding more than one thing (history suggests this is indeed a worthwhile consideration). It was just intended as a question of idle curiousity.


Edited by Mercury Filter, 17 November 2013 - 03:14 PM.


#34 Paradigm Shifter   Crossbones+   -  Reputation: 5410

Like
0Likes
Like

Posted 17 November 2013 - 03:23 PM

Yes, use macros and token pasting as I said above. You need to use several macros (one to paste all the code in to the source) and others to call the functions by building the correct names from the types (so you could have

 

#define LIST_PUSH_BACK(type, data) ListOf##type##_push_back(data)

 

etc.


"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#35 ApochPiQ   Moderators   -  Reputation: 16069

Like
1Likes
Like

Posted 17 November 2013 - 03:34 PM

Most of this thread is rather vacuous.

Differences in program implementation are much more a function of the programmer(s) involved than the language(s) involved. You can write C-like code in C++, you can write C++-like code in C. You can write Haskell-like code in both with enough boilerplate.

Of course, there's also languages like Java, in which all programs asymptotically approach utter crap.


But again, this has less to do with the language that most people here seem to think. Ultimately, languages are almost irrelevant for most software, and mostly irrelevant if you're still learning to program. It takes a lot of experience and objective insight to understand the strengths and weaknesses of various languages, and it takes extraordinary discipline to effectively leverage multiple languages. Chances are your code will have a style that resembles idiomatic code in your "preferred" language and paradigm, regardless of what host language you're actually writing in.

This is why people never can agree on what languages are capable of what, and what languages are preferable for what.

Ultimately it's all a giant holy war and not worth wasting brain cycles on. Turing equivalence is a rather cliche thing to bring up in a language war, but it's basically true: with enough work, you can write anything in any language that's Turing complete. The only important difference between languages is how easily they express certain concepts.

When it comes down to it, most programmers don't actually understand how concepts and languages map to each other, except in the vaguest of senses. (I include myself in this indictment, by the way.) They have an idea of how they personally would do things, but it's rarely really objective. In the end this just fuels the holy war.


My advice for the OP: don't sweat it. Learn many languages if you can, because that will help you understand what tools are suited for particular jobs. But don't bother getting mired in the minutiae of how to make language X behave like language Y.

Just write some fucking software.

#36 blewisjr   Members   -  Reputation: 622

Like
0Likes
Like

Posted 18 November 2013 - 07:27 AM

Most of this thread is rather vacuous.

Differences in program implementation are much more a function of the programmer(s) involved than the language(s) involved. You can write C-like code in C++, you can write C++-like code in C. You can write Haskell-like code in both with enough boilerplate.

Of course, there's also languages like Java, in which all programs asymptotically approach utter crap.

*snip*

 

I really have to agree with what ApochPiQ is saying here.  It really make a lot of sense and I have come to the same conclusions over the years.  There really is no point to making one language into another language.  For instance with C it is a procedural language.  There is really no need to force it to be object oriented.  I understand for instance GTK built an entire object system in C to make GUI programming easier but why X11 got by without doing this and so did ncurses.  Sure the API's are a mess but it works and is reliable.  If you want objects it would be better to just use a language that provides OOP.

 

The general idea is that it is not worth the effort to fight against your language unless it is the only language you have available (often in the case of embedded all you have is C).

 

The largest problem I see is that programmers are stubborn and form religions around what they enjoy to use and defend it tooth and nail even if they are totally off base.

It is not just languages it is also editors, ides, gui kits, and the list goes on and on.  It is really just hot air flying around it is best to just evaluate and learn and then choose what you want to use for the job.  It is best not to over complicate the evaluations and it is best to avoid the classic holy war information out there.  Educated decisions always win out over the head bashing baseless arguments.



#37 Winfield   Members   -  Reputation: 179

Like
0Likes
Like

Posted 20 November 2013 - 02:28 PM


but why X11 got by without doing this and so did ncurses. 

 

X11, ncurses, and GTK each do completely different things. Structural dissimilarity should be unexpected.

 

 

 


Differences in program implementation are much more a function of the programmer(s) involved than the language(s) involved. You can write C-like code in C++, you can write C++-like code in C. You can write Haskell-like code in both with enough boilerplate.

 

Between possibility and practice lies a gulf as deep and as broad as that between practice and perfection. I can play baseball, but the difference between me and a baseball player is significant. Calling a conversation vacuous because it concerns the real differences between languages, is contrarianism at its least useful.


Edited by Winfield, 20 November 2013 - 02:29 PM.


#38 ApochPiQ   Moderators   -  Reputation: 16069

Like
0Likes
Like

Posted 20 November 2013 - 04:43 PM

I really don't follow your point here.

I didn't say the thread was vacuous because it "concerns the real differences between languages." I called it vacuous (and not all of it, just most of it) because the discussion here has virtually nothing to do with real differences between languages! It has to do with how to make one language act like another, and techniques for that, with a little bit of waffling over whether or not it's a good idea.

Over the course of the thread, conversation has steadily drifted away from what actually separates languages, and more towards how to kludge things so they feel identical.


Hence my followup statement: differences in program implementation are much more a function of the programmer(s) involved than the language(s) involved. I stand by that fully and see nothing in your analogy to baseball that contradicts what I said.

Then there's the rest of my post, which also stands, and again I don't really see why you're calling it "contrarianism" or not-useful.


Obviously some people have found it useful, so it isn't objectively worthless. If you have genuine objections to what I wrote on a factual level, I'd love to hear them. Otherwise, just complaining because I didn't jump into the holy war is rather silly.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS