Search Unity

  1. Unity 2019.2 is now released.
    Dismiss Notice

Is Unity helping or hurting programmers?

Discussion in 'General Discussion' started by DexRobinson, Jul 21, 2014.

  1. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    14,278
    Only for languages with similar grammar. When I started programming I only had access to procedural programming languages. Making the jump to an object-oriented language forced me to completely rethink how I wrote my applications and in many ways they were far better written because of it.

    Learning a language to improve your overall programming skills is a good enough reason in itself.
     
  2. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    11,952
    A huge part of what makes C++ so painful to newcomers is that you need to manage memory for yourself. That involves understanding a lot of stuff that you simply don't need to understand to work in C#.

    You don't have to have a silly language war to believe that learning some lower level stuff can* be beneficial even for people who wholly or predominantly work in higher level environments. And sure, you can read about it or whatever on the side of doing your C# or other higher-level language work, but that's not the same for learning as actually dealing with it as you have to if you work with C/C++/other lower level** languages.

    Also, doing stuff for learning is a wholly different thing to doing stuff for production, so there's really nothing to even have a silly language war over. Nobody's saying what you should use, just that there's some stuff that's useful to understand and that some languages expose you to it more than others.

    * "Can" is not "will always be". There are indeed some people for whom this will never make a difference. But game programmers often have to optimise things, and optimising things well involves fully understanding how they work. Lower level languages hide less of that from us, so they're useful for learning in some situations even if they might not be the best tools for getting work done in others.

    ** When I say "lower level" I'm talking in comparison to the schwanky garbage collected stuff that does indeed often leave me feeling spoiled these days. There are of course even lower level languages than C/C++ and plenty of other languages that could expose you to similar learnings. There just happens to be plenty of material around for C/C++ thanks to its overwhelming popularity.
     
  3. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    11,952
    Agreed. And I haven't done that in ages...
     
  4. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    14,278
    Garbage collectors actually do exist for C++, but learning the basics is still a good idea.

    http://en.wikipedia.org/wiki/Boehm_garbage_collector
     
  5. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,337
    Uh... that's BECAUSE it was a design decision to have an interpreted language. These are *slow*. Unity doesn't use interpreted languages.
    You're not understanding fully what's going on there. The equivalent would be running lua in unity, ie interpreted and can change code while the game is running. That's slow, and probably not far off what playmaker is doing.
     
  6. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,064
    Unity uses C# which is 'converted' to a bytecode assembly that is then run through mono which uses a Just In Time compiler to convert the bytecode to native code which is then executed. If the routine is called again then the cached native code is called.

    My point is that a compilation step is required for any Unity scripts running within mono. This is a step that requires the overhead of mono and it's garbage collector (know to produce performance problems).

    Unity Technologies have even stated that they are starting to move to a native code build pipeline in Unity 5 that will take the bytecode and convert it into C++ that will be compiled to native platform specific code.
     
  7. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    11,952
    Actually it depends on platform. There's already AOT support.

    Yes, there's a compilation step involved. Two, in fact. But I don't see what the point of your point is?
     
  8. der_r

    der_r

    Joined:
    Mar 30, 2014
    Posts:
    259
    I think every new coder should at least make one game in C or C++... only so they can appreciate C# or Java. :p

    Kidding aside, I think it's important for the learning process that you really enjoy the project you're embarking on. I really really wanted to learn C++ back in the DOS days, because I wanted to move on from QuickBasic and TurboPascal and all the Apogee platformers and id shooters were using the Watcom C/C++ compiler that came with DOS/4G which helped with the limited memory back then (you could load more graphics and other assets into the limited memory). You could do that in Turbo Pascal, but you needed specialized assembler code for those extended memory pools.

    If learning is perceived as a chore ("I should learn C++ because it's a traditional language and all "real" coders know it"), your learning process will be much slower. It's better to learn using a lovable project. Once you know all the concepts, it's easy to learn another language, because they only differ in their grammar, their syntactical sugar and of course their application.
     
    inafield and angrypenguin like this.
  9. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,707
    Now that I'm no longer on an android device, I can actually type without the forum text freaking out on me, lol.

    I was going to quote this part and mention how I am skeptical as to memory management being this.... hard to grasp, complex topic so many people make it out to be. Sure, it's not as simple as learning how to declare variables or assign them value...but still...

    I read over and over again that it was the hardest thing about C++, that is was a nightmare for people to grasp, blah blah blah. Then I actually took a lesson in pointers. Talk about an easy concept.
    I was like, "Wait.. that was the hard part? People have trouble with this concept? ...what?"

    I actually like pointers when you need them, although they are pointless most of the time (hence their extinction in newer languages).

    I have a hard time believing that memory management is this evil (for the newbie) people pretend it to be. It was one of the first concepts I was taught, and although not as simple as the easier stuff, it is way more simple than the broader concepts of programming/engineering software or the heavy subject of game engine architecture.

    The real reasons C++ is painful to newcomers, is because it is so low level and so archaic (see: old). It takes the user hours to write classes on what C#, Obj C, or Java do in a single line of code. You have to do EVERYTHING yourself, or use libraries or frameworks that are often poorly documented. The quality libraries are almost requirements, making you wonder why they aren't part of the language in the first place. Fortunately, they are part of newer languages.


    If someone understands C# or another language, learning C++ won't be this difficult journey solely because of pointers. I'm not saying you were hinting at that, but it is common in programming circles to assume Pointers are the reason newbies and professionals dislike C++, when the actual reality is that C++ is just old and what I'd say is correctly termed: "incomplete". It lacks the awesome features and power of newer languages and their strengths.

    All in a world where performance is not as important as it used to be in the days of the Amiga.
    What modern programmers want and need, is not performance. It's ease of access, completion speed, and just plain getting things done with less work. One could argue that the very idea of C++ for game dev directly contradicts all of what Unity stands for. Low level to High level, and it turns out nearly everyone wants high level. Even big game companies like Blizzard (ex. Hearthstone = Unity ) and especially indie developers or indie professional developers (Shroud of Avatar, Shadowrun Returns, Camelot Unchained).

    In the end, nearly everyone could care less what is used to make something. They care more about how it is made, what it's like making it, how easy it is on them, how much work they can get rid of compared to quality/value, etc. Otherwise Unity and Unreal wouldn't be such big success stories, and everyone would say "Unity? Pffft, C++ all the way bro! Your platformer will own in C++!"
     
    Last edited: Jul 23, 2014
  10. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    11,952
    First thing's first, "pointers" are not "memory management". Memory management actually plays across many of the areas you mentioned as being bigger, e.g.: software architecture.

    Anyway, the issue isn't that it's this impossible beast that can't be managed. It can. The issue is that it takes time and that mistakes can be stupidly costly. Modern languages like C# relieve us almost entirely of both of those things.

    As for people not caring what you make stuff in, I couldn't agree more. Yes, use whatever helps you get the job done fastest. However, having a better understanding of your tools also allows you to get the job done better without necessarily taking any longer. For instance, it might help you make better informed decisions about how to design parts of your code. Or, see my earlier comments on optimising stuff, in case you ever have to do it.
     
  11. Kaji-Atsushi

    Kaji-Atsushi

    Joined:
    Oct 6, 2012
    Posts:
    234
    Unity is definitely not helping my archery skills.
     
  12. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,707
    Ah, well that makes sense. Maybe for me, memory management seemed to be common sense, or I didn't make any massive program or followed the right tips to prevent the common problems. With either, I never saw what all the hub-bub was about.

    Nearly every website about C++ & Newbies, discuss Pointers, not memory management as a whole, as this super-evil which destroys the brains of all learners. I must have assumed you were saying the same thing as most people on the interwebs.

    Then again, according to programmers on the internets, everything is evil. Maps are evil. Arrays are evil. Every container except Vectors are evil. Pointers are evil. Memory management is evil. Anything but C++ is evil, but no one knows how to program in C++ (according to the know it alls, of course). Good ol' internets, the place where sound reasoning and rational thought come to die.



    I admit I was a bit taken out of this thread and forgot everything I was replying to, thanks to 3 of my posts being totally destroyed by some Android/UnityForum bug. For some reason, anytime I use ANY android device (I've tried 3 different ones, a phone and two tablets) I can only *sometimes* type. Other times it automatically does something similar to autocompleting the same word X times in a row, where X = character length of the wordwwordworwowwordworrdwoord
     
  13. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,707
    ...or IS IT?

    <--- was this you just now???
     
    SememeS likes this.
  14. inafield

    inafield

    Joined:
    Feb 26, 2013
    Posts:
    281
    Without knowing at least some of the fundamentals, there is no appreciation or understanding of why some things are the way they are. Disrespecting the history of C/C++ memory management leads to a bad understanding of memory management now and sometimes immature comments about garbage collection. I think it's also important for most programmers to respect and understand the differences between pointers, references, and value. It doesn't mean I'll use it, but it does mean to respect the basis and how the upper level languages deal with it.

    From this foundation we can apply this knowledge and respect to other libraries we use and not abuse them. This is one of a few things that sets developers apart from each other. Respect.
     
    der_r likes this.
  15. inafield

    inafield

    Joined:
    Feb 26, 2013
    Posts:
    281
    You know what's really hurting programmers? CSLA: Component-based Scalable Logical Architecture. The creator of it is a nice and helpful guy, but it needs a LOT more optimization. Great idea, but just not feasible!!

    Scalable my butt!
    /rant
     
    Last edited: Jul 23, 2014
  16. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    11,952
    Hear here!

    A really experienced coder I know once told me a difference between inexperienced coders and experienced ones that was something along the lines of the following. When an inexperienced coder finds something they don't understand, they will often assume that the person who came before them didn't know what they were doing and start on a better solution. An experienced coder, on the other hand, will assume that the person who came before them had a good reason for doing what they did and set about better understanding that reason.

    Or, to put it another way from another great programmer I know, "Always start with the assumption that the person who wrote the code was at least as smart as you are". That doesn't mean to treat the code as the holy grail, just that you should stop and understand the whys of something before assuming you can do it better. And even when you can do it better, realise that the person before you might not have done it that way because they were an idiot - they could have been in a time crunch, it may never have been intended for production, it may never have been intended for the current use case, the design may have changed 10 times since they wrote it... etc.
     
    Ryiah, giyomu and inafield like this.
  17. inafield

    inafield

    Joined:
    Feb 26, 2013
    Posts:
    281
    YES. Unfortunately, even experienced coders will make the mistake of "I don't know how this works and so I'm just going to rewrite 900 lines of code for this itty bitty +/-1 error." My team paid for that mistake for 3 sprints because a 20+ year grizzled developer thought he knew better. :(

    <-- Made puppy dog want to growl at him.
     
  18. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,707
    I'm sorry, but when it comes to actual practical application, "respect" for history of programming is a joke because it is irrelevant.

    It sounds eerily similar to the old timers who argue that understanding binary should be required learning so people "respect how it all works" or "have a better understanding of programming".

    In other words: 011001000111010101110010011100100111001001110010011100100111001001110010011100100111001001110010.

    If the worst thing that will happen due to a "lack of respect" are "Immature comments" then it sounds like respect is not very important. If the worst thing that happens to a game developer is that they make stupid comments on the internet about something they didn't use, then wow, lol.

    edit: No offense intended. I just find all the arguing and pompous know-it-all-ism of programmers on the internet (many other websites, common attitudes) demanding crazy things as requirements for talent or professionalism to be as ridiculous as it is crazy. (See: Incredibly)

    In the end, it will devolve into something along the lines of Respect = Talent. Not the ability to program things effectively or efficiently, but respecting needless historical facts or understanding archaic practices equate to what defines someone as talented or not, lol.

    "George Washington's favorite type of chair was a three legged wooden stool called a "Champleg" !!!!!!!! *0100101010100101010101* OMG MY PROGRAM WORKS! :D
     
    Last edited: Jul 23, 2014
  19. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,473
    Just to add another approach to the initial question: Game developers doesn't necessarily need to be programmers anymore nowadays. You can make complete games without touching a single line of written code. And this not just at a hobby / indie /casual level like with Gamemaker. The non programming approach has finally arrived in the AAA region with Blueprints in Unreal Engine.

    The trend is clear. And will continue. Away from written code, in direction of non programming tools. This will never make programmers completely obsolete. You will always need programmers. But in the gaming industry they more and more have to share their market with the non programming approaches. Which hurts of course programmers.
     
  20. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,707
    Care to link to this Blueprints thing or an article about it and how it affects game dev? I mean, if you know of one? Thx.
     
  21. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,473
    I doubt that there are already official articles around. Blueprints is too new. I just know the official page and a few videos at Youtube. https://www.unrealengine.com/blog/what-can-you-do-with-blueprints

    It's just an example anyways. We have some more of this kind of approaches even in Unity. Strumpy shader editor or Shader Forge, and Playmaker for example. Which has quite a user base. And even Unity itself can be seen as such a non programming tool in some areas.
     
    Last edited: Jul 23, 2014
    CarterG81 likes this.
  22. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,707
    Thank you very much :)
     
  23. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,832
    I think you've got some preconceptions that are false. For a start, what is 'proper software development' how does that differ from software development in Unity3D?

    I find it interesting you state in such strong terms that programming can be avoided... but talk about a tool that I cannot imagine being anything *but* a programming tool. Are you describing textual programming?
     
  24. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,473
    Yes. I mean textual programming.

    You are of course right. Working with nodes is in fact programming too. But it gets seen as non programming since ages. Tools like Multimedia Fusion even makes advertising with that no programming is required. So when i talk about programming here then i mean the text approach. And the useage of a traditional programming languages like C++ or C#
     
    Last edited: Jul 23, 2014
  25. DexRobinson

    DexRobinson

    Joined:
    Jul 26, 2011
    Posts:
    594
    I may of confused proper software development with traditional C++ development. While I have been using C++ I have noticed a couple of things that I have had to do while I was unfamiliar with while I was using Unity. Before I started using Unity I came froma C++ background so it wasn't as confusing as it could of been, but I was wondering if I only had used Unity I could see how using Unity would hinder someones ability to work in a new environment. Unity makes doing everything a breeze. You write some code, press play and you can see if what you are working on does what it needs to do. Using C++ there is 5 times more work that needs to be done in order to get the same result. I was using UE4 over the weekend and to make a simple FPS style controller and shooting mechanic took 5 different classes and about 2 hours to create. Same with the in house C++ engine I am using now, it takes me 10 minutes just to get something up and running to test if a feature works or not. Since I was use to Unity this is how I would test my code. Now I am writing Unit test and writing my code into small simple function vs in Unity I could get away with keeping stuff in the update and start function.

    In C++ you have actual constructors and you have to know how to inherit from another class, in Unity I rarely inherited from another class. Monobehavior was the main thing I inherited from. In Unity the development is fun because you are mainly working on game logic and game play while in C++ I am spending most of my time writing behind the scenes logic. Unity is like painting a car and picking out all the cool things about the car and C++ is more like building the engine and making sure the car works.
     
  26. TheSniperFan

    TheSniperFan

    Joined:
    Jul 18, 2013
    Posts:
    686
    And a quite complicated one on top of that. There's just SO MUCH that needs to be taken care of when developing a game.
    It's like doing your first driving lessons in a racing car. Possible, but dumb.
    ^This! This, so much!

    I've seen countless threads pop up here and on IndieDB by people who want to get into game development, but know NOTHING about programming. Those people are asking questions like "Which engine should I choose for my project?" and "How does <absolutely trivial thing> work?".
    Some questions asked in the Scripting sub-forum also give the impression that whoever asked them, has never programmed before.

    Seriously people:
    Game development should be your goal, not your first step.
     
    angrypenguin likes this.
  27. Wild-Factor

    Wild-Factor

    Joined:
    Oct 11, 2010
    Posts:
    605
    Blueprint is a programming langage.
    And if you know how unreal work, it's a programming langage where they put nice box on top of it to hide the scary text...

    Using blueprint is programming. It just replace the scripting language like LUA used by technical artist, and use things artist are now used to work with in their everyday tools (clicking boxes...).

    Artist can make a game with blueprint as much as a programmer can use photoshop to draw his sprite...
    Some prog will succeed, like some artist will succeed. But it's not a revolution.
    But it makes it look easier when it's not. Try to make a real game (not a shiny demo or a prototype), and you will cry when you will try to fix a bug :) As soon as there were a bug, the artist ask a prog to redo it instead of trying to fix it :)

    In real AAA industry, if a blueprint function is used often, they ask a prog to convert it in C++. Most of the time it is a test and trash, becasue artist makes most of the time sometinh dirty, that is full of bugs, but enough to test his 3D model in game.
     
  28. TheSniperFan

    TheSniperFan

    Joined:
    Jul 18, 2013
    Posts:
    686
    Well, for one C++ != C#.
    The easiest way to put it is that C# traded efficiency and flexibility for convenience.
    You don't have to care about memory management for example; You have the garbage collector taking care of that. The downside to this is that there is no choice involved. You're stuck with it.

    Other than that you're basically saying that writing your own engine is more work than using one someone else provides. Well, that's true. Basic logic really.
    "Proper" is the wrong word to describe it. What you mean is "from scratch".
     
  29. dogzerx2

    dogzerx2

    Joined:
    Dec 27, 2009
    Posts:
    3,802
    But thinking logically can be transferred to any programming environment... so you must be talking about Unity specific knowledge, in which case, isn't it obvious that you can't transfer that? It's what Unity does, saves you time so you can be more productive, no way to apply what Unity does for you outside of Unity, that's the whole idea behind using a game engine that makes your life easier.

    Unity is definitely not hurting the actual programmer. The real question is whether Unity hurts the end result, as having so many things taken care of (such as memory management and garbage collection) ends up in lack of performance in the resulting game.
     
    Last edited: Jul 23, 2014
  30. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,832
    Exactly :)

    From what I read you're having a few problems:

    1) A more difficult language (r.e. effort needed to achieve result).
    2) Possibly a less easy to use framework.
    3) Component vs Inheritance architecture.

    None of these are Unity specific - they are just particulars of your particular situation.
     
    inafield likes this.
  31. Wild-Factor

    Wild-Factor

    Joined:
    Oct 11, 2010
    Posts:
    605
    If you want to be close to the truth, you should have said:
    "The easiest way to put it is that C# traded a little efficiency and a little flexibility for PRODUCTIVITY".
     
    inafield and GGnore.AlanSmithee like this.
  32. Slyder

    Slyder

    Joined:
    Oct 17, 2013
    Posts:
    270
    Coding is about fundamentals and problem solving. The language and API is irrelevent (unless the API has S***ty documentation then goodluck)

    • I picked up Unity using UnityScript a long time ago while getting my CS degree. Quit for a long time.
    • Picked it back up using UnityScript and decided to switch enitrely over to C#...that took a couple of days to transition.
    • Picked up Unreal Engine 4 after not seeing or messing with c++ for 10+ years. Took 1 month to learn the API and apply programming knowledge to that language and engine. Also learned cool things like behavior trees in the process.
    • Now working with a small team that has 2 successful indie releases under their belt. I am forced to use Unity and UnityScript because they cant be assed to learn C#. They are artists after all :D. Unity fits this project scope better than UE4 due to system requirements..

    If you UNDERSTAND progrmaming, then you should be able to transition between languages and APIs fairly easily. I absolutely hate Unity after working in UE4. Once you're regularly using pointers and references, call by copy-reference just doesn't stack up. C++ projects are WAY more organized, modular, and object oriented than anything you'd do in Unity.
     
    Last edited: Jul 24, 2014
    Ryiah and dogzerx2 like this.
  33. nbirko2928

    nbirko2928

    Joined:
    Aug 20, 2012
    Posts:
    125
    I think you're confusing programming with the environment. It's like asking if someone who has been doing Windows Apps using VB.NET for 3 years will have a problems building E-Commerce Web Apps in Java using the Spring framework. Will they have trouble? No doubt, but not because they lack of programming knowledge, it's the environment..

    Make no mistake that when you write scripts in Unity that is programming. Assuming you have the fundamentals then using Unity by no means should effect your actual programming knowledge.
     
  34. TheSniperFan

    TheSniperFan

    Joined:
    Jul 18, 2013
    Posts:
    686
    Yeah, "productivity" is the better word to describe it.
    However, I did not use terms like "a little", "lots of" or similar for a reason. What you said is factually wrong.

    Whether the limitations of C# (and similar languages for that matter) are a big deal or not depends on your work. For you it might just be "a little". However, a kernel developer will see this differently.

    There's something ironic in your post, considering this is the Unity forum.
    Two words: Garbage Collector.
    This is not about the efficiency, because you can improve Unity's GC. It's about the flexibilty.
    With languages like Java and C# it's not like someone took C(++), modernized it, added productivity features and said: "Here, use those features to be more productive."
    They force you to use them. There is no choice involved.
    Unity's Garbage Collector is one of the biggest (if not the biggest) performance problems the engine has - especially for mobile developers. And yet you say that not being able to opt-out matters just "a little".

    It's why I consider languages like Java and C# to be inherently flawed, as in: They will never replace C and the likes.
    So far I know of only one language that could pull it off, and that's D. The language where all this stuff is optional. The more I read about it, the more I want to learn it and I will (once I'm done with this semester's exams).
    Unity with D would be a dream come true. Too bad that it's highly unlikely.
     
  35. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,832
    The problem is that you're thinking about this in an entirely wrong way. What Wild Factor said was "The easiest way to put it is that C# traded a little efficiency and a little flexibility for PRODUCTIVITY".

    So yes, you can complain that the lack of control over memory management hinders low level optimisation (which is not the same as performance), the flip side is you'll actually have a delivered product to worry about performance for.

    Should you be in one of the few projects where low level optimisation is actually critical, *and* you have the resources to do something about it, then thanks to languages like C# you can focus on optimizing the typically small portion of code that needs performance (e.g. unsafe C#, F#, C++, C, Assembly) and keep the rest in the more productive code.

    That's the kind of thinking that C# promotes. It's certainly not the strawman argument 'replace C' - C# has no such objective. Sure, it doesn't work for every project - I would never use C# for a realtime system and it's not had much success that I'm aware of in embedded systems - but it does work for a huge range of applications.
     
  36. TheSniperFan

    TheSniperFan

    Joined:
    Jul 18, 2013
    Posts:
    686
    The problem is that you're thinking about this in an entirely wrong way. What I said was that what Wild Factor said wasn't always true. The corrected version would be "The easiest way to put it is that C# traded a little efficiency and a little flexibility for PRODUCTIVITY".
    At the end of the day whether it's a big deal or not depends on what you're doing.

    1. You delivered in C#
    2. You wouldn't have delivered in (say) C++
    These are two presumptions you made there. You say that as if it was universally true; And I have my doubts about that.
    (Also: "Delivering" a product with worrying performance issues? Seriously? <.< )

    You completely missed the point there. I was talking about using one language. I was talking about C#. Not about C# with some C++ here and some Assembly there.
    I mean Christ. You could use a dozen languages in one project if you wanted to.

    Now we're talking.
    What I wanted to say in my previous posting was that there isn't any absolute rule regarding those languages. C# is suitable for some things, but not for others. C++ is suitable for some things, but not for others. The same for every language (with the POSSIBLE exception of D - although I'm not 100% sure about that yet).
    You should get the idea.
     
  37. Wild-Factor

    Wild-Factor

    Joined:
    Oct 11, 2010
    Posts:
    605
    No I'm not wrong, I just don't have the same opinion. And I don't see why I can't use these words ? Because you don't want to ?

    A kernel dev can see it how he want. The important thing is you final product. A kernel dev is focus in his own job, and to find something to do... even if his time would be better use in other area to make a game.

    That's what they did nevertheless.

    Force you to use them for your own good. To protect you from your bad choice and your bugs.
    Be free to make a bad choice, is not something smart to give to your users.

    I can be pretty sure that the bad garbage collector of Unity is better than what can do 99% of experienced dev in C++ can do. First because they are other thing to do, like making a game. And second, you need several years of experience, and be ultra specialise to make anything good.

    And for Unity, the grabage collector, has just old, not bad. The last C# one, is good.

    That's only your opinion. Nothing more, nothing less.

    Even carmack who is a top notch low level prog, change his mind on C#.

    When you will have some experience you will:
    Ask yourself how many time you saw a dev making their own math lib because he thought he could do better...
    And how many time you see him failed to do a math lib with all the proper fuctionnality, bug free, and as fast as the default math lib he whished to replace. Do you really want to give programmer the choice of doing their own math lib, their own memory management etc.. ?

    The only one language that could pull it off is assembly. You will have 100% freedom, and will be able to optimize with all processor specialized instruction... :)
    Even C++ is a trade between productivity and flexibility/performance. C# is only the next step.
    You can accept the progress or not.

    C++ is still there because there a gigantic base of existing code. And it's became a standard. Not because of it's quality, but because you have no choice.

    PS: I love C++
     
  38. Wild-Factor

    Wild-Factor

    Joined:
    Oct 11, 2010
    Posts:
    605
    You're right, which make everything you said previously wrong...

    If you still prefer C++ over c# it's probably because you prefer making tech than making game.
    See how you talk about D. You are liking more the langage than what he help you do.
    D may be a good langage, but can you make a better game with it ? Is all the game lib available ?
    Can you acces all input ? 3D Graphic card ? Can you build it on PS vita, Wii, Xbox one ? etc...
     
  39. Soul-Challenger

    Soul-Challenger

    Joined:
    Dec 30, 2010
    Posts:
    152
    Unity is MAKING programmers :D
     
  40. TheSniperFan

    TheSniperFan

    Joined:
    Jul 18, 2013
    Posts:
    686
    You can use the words all you want. You can also say 2+2=5. Neither are a matter of opinion though.

    Let's not derail this thread any more shall we?
    To make myself more clear let me get back to the core of our little argument.
    I said that C# traded efficiency and flexibilty for convenience. That's all. I said that as an universal statement. After all the GC and similar features aren't free (efficiency), you're stuck with them (flexibility), but on the other hand you don't have to deal with all the crap yourself (productivity).

    See, I use C# almost exclusively for Unity while targeting Desktops. The efficiency isn't an issue for me. I know however, that it can be for others. As such I didn't say that it traded <this much> efficiency/flexibility because everyone has to decide that him-/herself. Exactly how much it matters in your individual case is a matter of opinion.

    I was making a general statement, which you corrected. Therefore it's factually wrong when you corrected it and added your opinion. "A little" is correct for you, it's correct for me, but Mr. Kerneldeveloper will see this differently and disregarding his views on this is just ignorance from your side.

    Being German I have to answer this.
    You wouldn't say such things if you lived in a country in which games targeted exclusively at adults (18+) are often cut or don't get released due to "youth protection".
    "Censorship is telling a man he can't have a steak just because a baby can't chew it."
    So shouldn't the skilled programmer be allowed use all those features because there are unskilled ones? No, you shouldn't take the choice away.

    That's really a matter of opinion though and we'll probably have to agree to disagree.

    Old code is an important reason for sure (see COBOL and similar). I also think that there isn't any language that can fully replace C/C++. C# can't do that. At the end of the day the runtime itself needs to be written in some language.

    No it doesn't, we were just talking about two different things. :D
    I was trying to make a general statement and neither of our opinions has anything to do in it.

    God no.
    I hate all this fussing about. Again, I never said that I prefer C++. I was just making a general statement.

    A language is a tool, nothing more, nothing less.
    I heard some people talking about it and talked to some bloke who learns it. I haven't looked into it in detail yet, but the concept, the mere concept seems to be the blueprint for the best programming language of its kind.
    The idea that you can have all the control of C and all the productivity of C# using the same language is something that fascinates me.
    I don't know whether it's implemented as good as it sounds, since I didn't have the time to look into it yet.

    Would it help me making better games? I don't think so. For me making games is making art. The best tools and most skilled developers are no guarantee for a good game.
     
    Wild-Factor likes this.
  41. Wild-Factor

    Wild-Factor

    Joined:
    Oct 11, 2010
    Posts:
    605
    ok (censorship and C# is a funny comparaison so)
     
  42. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    14,278
    This is a flawed argument. You can make bad choices just as easily in C# as you can in C++. The difference is how it affects the application.

    Handling memory is the aspect typically touched on. People are quick to point out how carelessly handling memory in C++ can result in memory leaks. While the GC in C# can help prevent most of them, it is still possible to cause memory leaks.

    Not to mention it is possible to work against the GC causing it to run for longer periods of time. This can cause noticeable performance problems.

    http://msdn.microsoft.com/en-us/magazine/cc163491.aspx
     
  43. Wild-Factor

    Wild-Factor

    Joined:
    Oct 11, 2010
    Posts:
    605
    Well bad or good choice can be measure on consequences nothing else.

    Yes it's still possible to have issue with C# (I don't think anyone in this discution say the opposite), but they just happen less often. If you take the same programmer and by making him using one langage instead of another one, you reduce greatly the number of bug for your app. And your user don't see a performance decrease. Why shouldn't you do this ?
     
  44. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,832
    Or Mr 'kernel developer' would agree entirely. For example do they write the entire kernel in C/C++ or do they write performance hotspots in assembly? Do they reuse general collections where possible instead of rebuilding for each scenario? Heck, are these not the same group of people that built the entire ecosystem to let languages like C# and platforms .NET exist so people would not have to spend all their time in C/C++?

    If Kernel developers didn't believe in trading a little bit of efficiency and flexibility for productivity... why are they writing a kernel? Why aren't they working in hardware?

    And beginning a *mature* human being you'd also realize that strict, government censorship is entirely different from language/platform design decisions.
     
  45. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    14,278
    Except you are not reducing bugs, you are merely hiding them. Much better to correct the problem early on than to encounter them later because the language had been concealing them.

    A programmer who suddenly becomes much better simply by using a higher level language is likely not a very good programmer to begin with. I wouldn't waste my time with them.
     
    Last edited: Aug 6, 2014
  46. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,707
    Agreed. Once you know programming, you know programming in all languages. It takes at most a few days (worst case scenario) to understand the subtle differences.

    I especially agree with the C++ project vs Unity part. Any project that uses any language with the basics (OpenGL/DirectX/whatever basic game framework) will be more organized, modular, and object oriented than Unity. Well, the last part is a given since Unity takes on a component-based approach (which I actually like, even though I have significantly less experience with that style).

    To be honest, working with Unity has its strengths, but at the same time... those strengths could be recreated in your own custom framework (without all the crap you don't need) - all in a much more organized way. Especially organized for the creator, since it's their own work, their own mindset. Nothing is better than understanding everything inside and out because you created it yourself.

    I actually don't think I will be using Unity after my first major release. I chose it because I thought the game would be simpler to make in Unity, but ended up sticking with it only because I already invested so much time into the game to switch over. I honestly don't think it would have been more difficult making it using a game library instead of a Unity engine. More time? Sure, but not much. So unless my mind is changed by some kind of mind-blowing Unity feature (perhaps cross-platform portability?) then I won't be using it again.

    If I were making a 3D game, I might have an entirely different opinion. I don't make those though. I only make 2D games. At least for my next few titles anyway.

    This is just my opinion though, my style. I was much faster and significantly less frustrated when I was working on my own game engine, than when using Unity. Even when I had no idea what to do, it was a lot more rewarding accomplishing things. Although Unity makes things easier, I have learned I don't care about easy. I care about understanding what I'm doing, and enjoying myself while I do it. With C++ and C#, I understood everything I was doing and never had any doubts. Part of what keeps me sane in Unity, is that a huge portion of my game runs without Unity (just uses C# without Monobehaviour). Creating those "scripts" are the funnest, most rewarding aspect of game dev in Unity.
     
    Last edited: Aug 6, 2014
  47. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,707
    To note, I also regret choosing Unity because (as I mentioned above) I miss out on learning opportunities.

    I actually feel like my programming skills are degrading while using Unity.

    I actually miss programming, because Unity requires so little. Surprisingly little.
     
    Last edited: Aug 6, 2014
  48. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,832
    Have you looked into the data? My understanding is that programmers tend to make X bugs every Y lines... regardless of the language. I then follows that a high level language that needs less LOC to achieve the same result will be less buggy.

    Either way I have a hard time seeing how higher level languages 'hide' bugs, they generally attempt to avoid letting them occur in the first place.
     
  49. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    14,278
    Once again it is not producing fewer bugs, it is concealing them better. A concealed bug is a bug that can later cause problems.
     
  50. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,832
    How does a high level language 'conceal' a bug? For example, take these two simple constructs:

    Code (csharp):
    1.  
    2. for (int i =1; i<=array.Length; i++) /*oops, we're off by one*/;
    3. foreach (var item in array) /*no possibility for a off by one error*/;
    4.