Announcement

Collapse
No announcement yet.

D Language Still Showing Promise, Advancements

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #76
    Originally posted by movieman View Post
    Garbage collection is a vain attempt to protect poor programmers from their own bugs, which merely introduces a ton of new ways for them to write poor code.

    I don't use C#, but I've spent far more time trying to optimise Java garbage collection than I have hunting down memory allocation bugs in C++. It's a crazy language which is supposed to be object-oriented, but you can't afford to use objects if you need any kind of consistent performance becuase the garbage collector will stall you for long periods while it cleans them up, and where you have to give your application 1GB of RAM just in case the user needs it, but your application will crash if they ever need 1GB + 1 byte on a machine that has 20GB free.
    Those are implementation shortcomings of Javas GC, what a good generational GC does is that every X object allocations you do a generation pass that takes microseconds, and you often never need to do full gc runs in the average use case. v8, for example, has a much better GC than the Oracle JVM, and I barely notice it run during memory profiling on Chrome.

    For the average application use case, old C++03 manual new / delete in the destructor was much more error prone than Java / C# new X and just try to reuse the objects you already allocated. Nowadays, I find smart pointers, even with the added seconds making them and instant of thought if I should be passing an owning or non-owning reference around are a tremendous productivity gain since I don't need to worry about my allocations crashing a VM.

    Comment


    • #77
      Originally posted by plonoma View Post
      But there are shitty assembly and plain binary programmers too!!
      What will we do now?
      That's the point :lol:

      Comment


      • #78
        Originally posted by elanthis View Post

        You have a dated idea of what a modern IDE can do (I did, having first used relics like TurboC++ and VS6 until years later trying VS2008+VAX) if you think Vim or Emacs is more powerful in ways that matter for software engineering. They can manipulate _text_ way better, sure, but a program is not really text. It is merely represented by text for our human consumption as we haven't figured out a more efficient medium for it yet. The compiler quickly converts that text into more abstract, semantically-meaningful representations as soon as it can. A good IDE does this as well. The IDE also understand that once you start debugging a program, it is _really_ not just text anymore. To do a complex refactoring with a good IDE, you hit a key-combo, maybe type in a new name or signature, and you're done; drink a coffee, watch the numbers tick on your bank account, or do whatever else you want while the Emacs user spends so time developing his one-off LISP macro to do the same (and then fix up all the false-positive matches it'll end up with). The IDE gives you a deeply integrated debugger with super painless visualization of values, drag-n-drop instruction pointers, etc. You can have visual debuggers for the modern GPU-heavy world, quite powerful multithreaded debuggers and visualizers, interactive charts and graphics, etc. The build system is integrated deeply in ways you literally can't even do with many UNIX-originated build systems.
        you spend too much time running in debuggers. Unit tests and simulations are the only way to prove algorithm and program correctness. Make it break and make it break fast. Writing multithreaded code debug builds typically don't force crashes like optimized builds do, which is exactly what customers run. VS in particular is very bad at supporting lots and lots of little independent unit tests and simulations. What I work with requires a level of provability and verifiability since we have some engineering accuracy specs to hit.

        About "garbage collection" of memory resources, the underlying system malloc/free can have a bigger impact than "smart pointer" management, ESPECIALLY with multithreading. This is especially true on windows, yes even win7 still. That's why there exists things like hoard, nedmalloc, tcmalloc, jemalloc, etc. On the linux side I don't see any gains with these allocators, on windows limiting use of things like iostreams, create/destroy std::vector, etc especially in iterative code lessens the need for these allocators.
        Last edited by bnolsen; 07-03-2013, 10:02 PM.

        Comment


        • #79
          Originally posted by plonoma View Post
          But there are shitty assembly and plain binary programmers too!!
          What will we do now?
          http://xkcd.com/378/

          Now get me an effin' butterfly!

          Comment

          Working...
          X