Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Saturday August 22 2015, @04:03PM   Printer-friendly
from the java-is-in-the-lead-because-of-the-caffine dept.

Think of it as a map of the rapidly changing world of computer software.

On Wednesday, GitHub published a graph tracking the popularity of various programming languages on its eponymous Internet service, a tool that lets anyone store, edit, and collaborate on software code. In recent years, GitHub.com has become the primary means of housing open source software—code that's freely available to the world at large; an increasing number of businesses are using the service for private code, as well. A look at how the languages that predominate on GitHub have changed over time is a look at how the software game is evolving.

In particular, the graph reveals just how much open source has grown in recent years. It shows that even technologies that grew up in the years before the recent open source boom are thriving in this new world order—that open source has spread well beyond the tools and the companies typically associated with the movement. Providing a quicker, cheaper, and more comprehensive way of building software, open source is now mainstream. And the mainstream is now open source.

Hmm, Perl has been declining...


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by Subsentient on Saturday August 22 2015, @05:45PM

    by Subsentient (1111) on Saturday August 22 2015, @05:45PM (#226315) Homepage Journal

    I hope not. In many places, Go lacks features that C has. I do recall pointer arithmetic being among them...

    --
    "It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2, Insightful) by Post-Nihilist on Saturday August 22 2015, @10:02PM

    by Post-Nihilist (5672) on Saturday August 22 2015, @10:02PM (#226410)

    Pointers arithmetic is something best left to the compiler, you only need to be able to get and set a pointers; even for system programming and GO provides that. When you think about using pointer arithmetic you should be thinking about slice and struct. Go ahead try to find a case where structs and arrays are insufficient...

    --
    Be like us, be different, be a nihilist!!!
    • (Score: 1) by massa on Sunday August 23 2015, @06:18PM

      by massa (5547) on Sunday August 23 2015, @06:18PM (#226698)

      Pointer arithmetic is good to write memory allocators.
      Really efficient string manipulations depend on really well-written string allocators (not present today on many "most-used languages", including C++, go, perl, ruby, python, etc. -- and don't get me started on Java...).
      But otherwise, yeah, C++-like iterators and for-each are more than good enough to substitute C-like pointer arithmetic.

      • (Score: 1) by Post-Nihilist on Monday August 24 2015, @12:18AM

        by Post-Nihilist (5672) on Monday August 24 2015, @12:18AM (#226768)

        Can you point me to an example where the following construct : address_of(array_u8[arithmetic]) would be insufficient? I am curious

        --
        Be like us, be different, be a nihilist!!!
        • (Score: 1) by massa on Monday August 24 2015, @02:25AM

          by massa (5547) on Monday August 24 2015, @02:25AM (#226786)

          Not insufficent, less efficient. The compiler has to have a clear view that you are doing

          for( i = 10; i 20; ++i ) prod *= a[i]

          and that it's the same as doing

          for( p = a+10; p a+20; ++p ) prod *= *p

          (which would translate to a single "repeat 10 times multiply addressed by register with autoincrement" instruction inside the loop -- those things in the core of the loops make the big difference in performance)

          (notice that in most cases, yeah, the compiler can do that. But the pointer arith is there to deal with the other :D cases)

          • (Score: 1) by massa on Monday August 24 2015, @09:22AM

            by massa (5547) on Monday August 24 2015, @09:22AM (#226944)

            (smart people know that there is a < that was omitted above, on each code example)
            :D