Does managed code make people stupid?

This is a discussion on Does managed code make people stupid? within the A Brief History of Cprogramming.com forums, part of the Community Boards category; Sorry , but I'm calling BS on the idea that higher level languages are needed to abstract the hardware so ...

  1. #16
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Sorry , but I'm calling BS on the idea that higher level languages are needed to abstract the hardware so that they can economically solve complex problems. In my experience its usually the exact opposite. High level languages lock you into a specific solution for a broad class of problems. C/C++ and assembly let you tailor a solution to the specific problem, allowing it to be solved much more efficiently, if at all. No way in hell a high level language is going to run real time object tracking and classification at 30 fps on a 10 megapixel feed.

    Stop assuming modern computers are overpowered for everyones tasks. Some of us need computers to be hundreds or thousands of times faster than they are before we can deploy applications we already have sitting in the back room until then.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  2. #17
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    I think Mad_guy was more referring to large (not to say HUGE), complex and convoluted solutions, where most of the computational tasks are trivial, and a large portion of the code is user-interfaces, data-base accessing, and other light-weight from a computational standpoint, but still getting raterh complex eventually.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #18
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,586
    No more than being able to manage memory makes you smart. Memory management is ONE aspect of programming. Managed just happens to take care of it for you. However you can still completely misuse a managed language and create a mess. Managed does not require you to be stupid it just takes the memory management load off of you. While I personally feel that for the competent C/C++ programmer this is not really a problem, others don't share my views.

    Since I don't know anything about Java I will only comment on C#. I'm currently in training for C# and after a bit of messing with it the language really begins to grow on you. C# would probably be easier to maintain but there are some gotchas in it as well that could really ruin your day if you are not careful. C# is fast enough for robust GUI apps, small games, non time-critical communications, etc. I would not use it to communicate directly with a device where timing was crucial or where you needed direct access to I/O ports. I also could not yet see it in a professional production quality game. However I could see it sitting closest to the user as a front end GUI in a large application.
    It's very useful, has very good performance, and overall is easier to both develop under and maintain.

    I'm first and foremost a C/C++ programmer but if I had to code in C# every day it really would not hurt my feelings any. It's a great langauage. It's not a matter of whether C# is the new C++ but a matter of using the best tool for the job. Not everyone benefits from using just C/C++ and not everyone benefits from just using C#. As well some may be forced to mix the two for their needs. It all depends on what you are wanting to do and the requirements set forth and how the language will help you meet the requirements safely and in the least amount of time.
    Last edited by VirtualAce; 07-23-2008 at 03:42 PM.

  4. #19
    Disrupting the universe Mad_guy's Avatar
    Join Date
    Jun 2005
    Posts
    258
    Quote Originally Posted by abachler View Post
    Sorry , but I'm calling BS on the idea that higher level languages are needed to abstract the hardware so that they can economically solve complex problems. In my experience its usually the exact opposite. High level languages lock you into a specific solution for a broad class of problems. C/C++ and assembly let you tailor a solution to the specific problem, allowing it to be solved much more efficiently, if at all. No way in hell a high level language is going to run real time object tracking and classification at 30 fps on a 10 megapixel feed.
    In your class of problems, i.e. purely data computation, number crunching, there is little to be gained by high level languages; it's simply part of the job description that it needs to be done as fast as possible. I'm not disputing it, nobody is.

    In other classes of problems however, higher level languages are far and away a winner however. Take for example Erlang. It is designed for highly fault-tolerant real-time applications (such as telephony systems.) It is extremely concurrent; a single lightweight process takes only roughly 300b of memory, so you can spawn thousands and hundreds of thousands of lightweight workers to do your work in parallel. But that's still not the main benefit, it's fault tolerance (concurrency is a necessary part of this structure. If one fails and nobody is there to pick up, it simply fails.)

    Erlang extends this with natural distribution; extending your code to work on a cluster is quite simple. If you want an example of something I wrote in erlang when I was testing something a while back, it was going to essentially be a basic game server. In 300 lines of code after 2 days of work, I had (working):
    * Load balancing inbetween an expanding number of nodes.
    * Nodes could be added to the game server on the fly and removed on the fly via administrative functions. It could also move clients off nodes if they were being removed, and new nodes were automatically factored into the load balancing.
    * Worked easily across networks and LANs alike, meaning you can have this split up among entire clusters and it all takes care of itself and scales properly (part of the scaling is because each erlang process has it's own heap, and everything is message passing, there is no shared state.) Processes and the erlang system also automatically utilize multicore (so you can sometimes even get linear speedups.)
    * Basic fault tolerance (didn't get it fully fleshed out before the code got obliterated,) using the proven OTP libraries.

    Can you get all that running in 2 days, no, not even that, with 300 lines of code in many other languages, e.g. C++? I'm skeptical to say the least. In this case, using a higher level language got my significant benefits instantly, including extreme scalability and ease of programming. As well, I got built in fault tolerance thanks to some Erlang libraries that come with the distribution.

    Using erlang the developers have been able to create extremely large systems that have run with 99.9999999% uptime year round. To put that in perspective, the telecom switch they programmed would go down for about 30ms each year, meaning you would blink and the downtime would be over.

    Another example is Haskell. With Haskell, prototyping and development is significantly eased thanks to the extremely powerful type system. The type system proves lots and lots of little theorems about your code, and in many cases when you get things to compile, more often than not they 'just work' (Indeed, many times I've thought something up, written it down and it worked. No problem.)

    We can even express a certain class of dependent types with type level functions: this helps greatly in the areas of correctness. For example, given two vectors and we wanted to add them, i.e. [1,2,3,4] + [5,6,7,8] == [6,8,10,12]. What do we do in the case of adding vector [1,2,3] with [1,2,3,4,5]? Optimally, we would like the typechecker to reject the program, and with haskell we can do this: we can embed the length of the vector into its type at compile time (we can even define type level functions for things like addition) and so adding the two vectors above would result in a type err: you can't add a vector of length 5 with a vector of length 3, and the type system proves it to us. Essentially, we can embed values into the type system at compile time![1]

    Purity in haskell helps with correctness, because we eschew mutable variables. It makes functions easier to test, it makes functions easier to reason about all together, because we can be assured for all 'x', a function applied to it, e.g. f(x) will *always* have the same result every time. Meaning we can easily construct invariants and prove them with testing frameworks that generate random data, insuring the integrity of the function. This wouldn't be possible without purity: the state of 'the world' changes to much to be certain about many things.

    Parametric polymorphism in the type system helps you write generic, 'lego' functions that you can easily tear apart and put back together, because their operation is uniform over a range of different types. So you don't repeat yourself. Several languages recently 'adopted' this; you might basically know them as generics.

    Do you see where I'm going with this? Features like these allow us to not only express problems easier, but gain benefits like correctness, scalability and integrity. Things like this are becoming more important in software every day. Older languages certainly have their place: I have never been one to dispute that, it's simply in many cases the cost-benefit analysis doesn't weigh in their favor (certain times considerably.) So it's just easier and more productive to get it done in a higher-level language. In this case I listed off two functional languages I like, however, the same applies to many other languages as they also have good abstraction as well as thriving ecosystems and library support. That's another matter for another day though.

    That's why they're there. To make things easier, to try and progress. If one isn't willing to expand his mind and try to do better, learn new things and take new approaches, I don't see how he could be a very valuable programmer to say the least.

    [1] Haskell98 doesn't have these features, type level functions are extensions enabled by GHC. Also, haskell is not 'dependently typed' per se, but the type system can become turing complete with these extensions essentially meaning it has equivalent computational power, just not as nice. There have been type-level quicksorts, lambda evaluators, peano numbers and super-type intensive session types which basically allow you to define a statically verifiable communication protocol at compile time.
    Last edited by Mad_guy; 07-24-2008 at 02:12 AM.
    operating systems: mac os 10.6, debian 5.0, windows 7
    editor: back to emacs because it's more awesomer!!
    version control: git

    website: http://0xff.ath.cx/~as/

  5. #20
    the hat of redundancy hat nvoigt's Avatar
    Join Date
    Aug 2001
    Location
    Hannover, Germany
    Posts
    3,138
    Quote Originally Posted by brewbuck View Post
    C and C++ are like the manual transmission. They require you to think and take more responsibility for the performance of the machine. If you look around you definitely do not see an excess of manual transmission vehicles but they are still there, everybody at least knows what they are if that can't personally drive one, and it isn't going away any time soon.
    Sidenote: This probably is different from culture to culture. I don't think anyone would say the Germans are not technologycally advanced enough to build cars, but automatic transmission is still seen not as a great tool, but as a crutch in Germany. It's a feature for disabled or old people. Who in their right mind would give up control over their car ?

    It's all about point of view and personal preference. I don't think Lewis Hamilton would be number one if his car had automatic transmission. But then, I would not be able to transport those crates of beer home in his car either. There is a tool for each job. Know your job and you will know which tool is best.
    hth
    -nv

    She was so Blonde, she spent 20 minutes looking at the orange juice can because it said "Concentrate."

    When in doubt, read the FAQ.
    Then ask a smart question.

  6. #21
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,383
    Quote Originally Posted by Mad_guy View Post
    * Load balancing inbetween an expanding number of nodes.
    * Nodes could be added to the game server on the fly and removed on the fly via administrative functions. It could also move clients off nodes if they were being removed, and new nodes were automatically factored into the load balancing.
    * Worked easily across networks and LANs alike, meaning you can have this split up among entire clusters and it all takes care of itself and scales properly (part of the scaling is because each erlang process has it's own heap, and everything is message passing, there is no shared state.) Processes and the erlang system also automatically utilize multicore (so you can sometimes even get linear speedups.)
    * Basic fault tolerance (didn't get it fully fleshed out before the code got obliterated,) using the proven OTP libraries.
    This is an area that I'm particularly interested in.

    I never favored software based load balancing, having preferred the hardware choices. How do you say would Erlang tools perform in contrast with a multilayer switch?
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  7. #22
    Ethernal Noob
    Join Date
    Nov 2001
    Posts
    1,901
    does using smart pointers make you dumb?

  8. #23
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by indigo0086 View Post
    does using smart pointers make you dumb?
    Yup, definitely ;-)

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #24
    Ethernal Noob
    Join Date
    Nov 2001
    Posts
    1,901
    Well I do know reading Mad_guy's post makes me feel dumb. *goes back to fifth read through of quaternion math*

  10. #25
    Disrupting the universe Mad_guy's Avatar
    Join Date
    Jun 2005
    Posts
    258
    Quote Originally Posted by Mario F. View Post
    This is an area that I'm particularly interested in.

    I never favored software based load balancing, having preferred the hardware choices. How do you say would Erlang tools perform in contrast with a multilayer switch?
    I'm afraid I have no experience with load balancing hardware/switches, at least not to the point of being able to make a fair comparison. Doing it in erlang was relatively easy, however (I believe I looked into some stuff about an OpenPoker server being written in erlang, had some good tips.)
    operating systems: mac os 10.6, debian 5.0, windows 7
    editor: back to emacs because it's more awesomer!!
    version control: git

    website: http://0xff.ath.cx/~as/

  11. #26
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,383
    Gave it a quick look. Quiet interesting. The syntax is of course completely alien to me, but that's a minor nuisance that shouldn't take more than a few days to get used to. Still it seems to integrate well. I could for instance take advantage of the apparently more streamlined multithreading (or even traffic/queue) support of Erlang by writing whatever engine I needed in Erlang and expose it through a dll I could call from C++, no?
    Last edited by Mario F.; 07-24-2008 at 12:04 PM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  12. #27
    Dr Dipshi++ mike_g's Avatar
    Join Date
    Oct 2006
    Location
    On me hyperplane
    Posts
    1,218
    I'm starting to get disillusioned with Java, in the sense that theres a hell of a lot of bugs floating around in it. Its almost as if the people that made it were like me: jumping around from one idea to the next, but not bothering to make sure that the code always works as intended.

  13. #28
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Well I didn't mean to start a war, at least *most* people understood what I was asking

    erlang does look very interesting, very 1960s style

  14. #29
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,383
    Quote Originally Posted by mike_g View Post
    I'm starting to get disillusioned with Java, in the sense that theres a hell of a lot of bugs floating around in it. Its almost as if the people that made it were like me: jumping around from one idea to the next, but not bothering to make sure that the code always works as intended.
    I think its the prerogative of proprietary programming languages, albeit as I understand that's not what Java is anymore since last year. The thing that drives me off this language is however the "All Programmers Are Dumb" approach that I so much criticize in its other shapes like "All users are Dumb" in Windows. Some features that Java lacks and that could be probably be easily integrated, aren't simply because programmers must be protected from themselves.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  15. #30
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    Java is still a proprietary language, a trademark of Sun. Only those you pass Sun's test suite get to call themselves Java.

    It's just their virtual machine that has been open-sourced, I think.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Call managed code (c#) from unmanaged code (VC++ 6.0)
    By playxn in forum C++ Programming
    Replies: 3
    Last Post: 10-14-2008, 12:11 PM
  2. make user press enter / wierd code thingy
    By CorvusVita in forum C++ Programming
    Replies: 10
    Last Post: 04-05-2006, 09:55 AM
  3. God
    By datainjector in forum A Brief History of Cprogramming.com
    Replies: 746
    Last Post: 12-22-2002, 11:01 AM
  4. How do I make and edit box scroll down with code?
    By Unregistered in forum Windows Programming
    Replies: 0
    Last Post: 11-26-2001, 01:33 PM
  5. Replies: 25
    Last Post: 10-28-2001, 12:08 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21