PDA

View Full Version : Does managed code make people stupid?



zacs7
07-21-2008, 05:03 AM
Well,

Being a first year Software Engineering student I've noticed that all they seem to teach, at least for the basics of programming is managed code. I mean things like, Python, C#, Java especially and Visual Basic. There's no arguing that managed code "removes" you from a few tasks... on a side note I find myself doing "unnecessary" safe things in Java -- redundant checks that java does etc.

Would you say that it's a bad thing that so many grads are coming out of Uni without having touched languages such as C, etc? Bare in mind that these people may very well come work in C or C++ with you without having "fallen" into the many traps. I'm just wondering what the oldies who started with things like C in Uni have to say...

Unless you think languages like C are slowly going to die? I can't see that happening... the VMs at least have to be written in something :)

whiteflags
07-21-2008, 05:54 AM
From another student's perspective, it doesn't seem so bleak. Here's a short list of the courses you need to take, if you want to be a programmer, at my local college:

C++ Programming 1
C++ Programming 2
C# Programming 1 or
Visual Basic Programming or
Java 1

Of course the degree requires you take one of several programming course sequences and I do see other sequences that include visual basic. It is impossible to go through the program without programming in some C# or C++ though. So inevitably they're at least learning about said traps at some point.

matsp
07-21-2008, 06:05 AM
Obviously, handling memory and managing it is specific to lower level programming languages - Python and such you just use stuff, and how the memory is managed is none of your concern.

But eventually, given enough programming experience, the programmer will most likely learn about managing other resources that require some actual action to free them, and once the concept of allocating/freeing resources is understood, then the concept can be moved to the memory management as well.

But also bear in mind that A LOT of applications are better written in high level languages, avoiding those problems, and achieving the same thing in a lot less code.

Programming should not make anyone stupid. There are other activities that may induce stupidity [falling on your head, certain drugs, alcohol, solvents (intentional abuse, or side-effects from using solvent-based products), bad diet and many other things]. Only "ignorance" in the sense of "never having learned about it" is what you can attribute to learning programming in a managed environment.

--
Mats

Mario F.
07-21-2008, 06:10 AM
The answer to your topic question is definitely a big No, in my opinion.
As for unis... the real objective is not to teach programming languages, but to teach programming in general. That can be essentially done in any number of languages as long as the different programming paradigms the student will face out there are supported.

Granted, not touching C throughout the whole time is a little... weird. It's prevalence and its importance is obvious - even if one couldn't think of anything else, for the influence it had on many other current programming languages. It's possible that the fact you aren't learning it, or will not learn it in the upcoming terms is a troubling sign. Makes one wonder the about quality of the course. But in reality it is not strictly necessary, in my opinion, as long as you are being taught what you should be taught. And that is how to program and how think like the machine. About any programming language can help with that.

There is however one interesting aspect in that course of yours. And that is... it's not usual. Usually students rightfully complain their teachers are old crones attached to old practices. C and C++ is usually still being taught with old non-standard compilers and with all the bad practices, some denounced long since. Teachers simply make no effort to adjust, adapt and learn the "new ways". However, in your course you are learning more recent programming languages. That's interesting and if in fact you are being taught how to programming instead of how to program in any of those languages, then I think you've hit goal. Otherwise it's probably a behind.

medievalelks
07-21-2008, 06:19 AM
I think it is a problem with someone who will enter the work force and work primarily with C or C++, but I also see the majority of the work force using alternatives now.

But no, it doesn't make them "dumber". I've long since eschewed the notion that you have to twiddle bits and manage memory to be a "real programmer".

indigo0086
07-21-2008, 06:25 AM
Does using a library make you look stupid because you aren't writing it yourself like sockets, threading, etc.?

zacs7
07-21-2008, 06:38 AM
Hmm, good to know -- thanks for the input. It's just there seems to be a rather large gap that isn't filled in the core units between assembly and say Java for example.

> There is however one interesting aspect in that course of yours. And that is... it's not usual. Usually students rightfully complain their teachers are old crones attached to old practices.
Yes, heard about that -- speaking to 3rd or 4th year students who complain that they had to do such things in first year.

> As for unis... the real objective is not to teach programming languages, but to teach programming in general.
Also drilled into us at every lecture. Little side notes "Java is only used to demonstrate the algo" etc.

> Only "ignorance" in the sense of "never having learned about it" is what you can attribute to learning programming in a managed environment.
I agree, sort-of what I was trying to say by saying "stupid".

Really, thanks for the replies ;)

indigo0086
07-21-2008, 06:42 AM
still, programming isn't an easy task. Chances are if you've made it through an entire coursework, using only Java or C# chances are you are in a minority of people who can actually understand programming on an advanced-beginner to intermediate level. To use the word "stupid" is pretty ignorant in itself.

I love C++, but I also love Java and C#. they are interesting and I do say that at times I make slip ups with basic pointers and stuff, and haven't really used them on a large scale yet.

zacs7
07-21-2008, 06:45 AM
Perhaps ignorant would have been a better word than stupid. I too love Java, it is infact the main language for my coursework (used to demo algos etc), taught in first year "Computer programming" for OOP concepts, data structures, how to program etc.

But my little corner of the world they almost mean the same thing ;)

indigo0086
07-21-2008, 06:46 AM
I disagree.

abachler
07-21-2008, 07:36 AM
I find it odd that they woudl have a course in programmign and not include C/C++, btu Many of us here learned to program in other languages like BASIC or assembly, so C/C++ is not a requirement to learn programming. That said, if you know C/C++ you can always fidn a job, because more employers are willing to let you pick up, e.g. python, on the job if you know C/C++ than the other way around. My employer required me to learn to use LabView post emplyment, the fact that I could program in C/C++ which is seen as 'hard' led him to believe I had the ncessary skills to learn a simpler language.

medievalelks
07-21-2008, 07:47 AM
That said, if you know C/C++ you can always fidn a job, because more employers are willing to let you pick up, e.g. python, on the job if you know C/C++ than the other way around.

I'm not sure that's true, at least in today's market where I live. Employers won't ask you in for an interview if you don't list the languages they seek on your resume. I mean, I've got C++, Java, Python, Perl, etc., but couldn't get a sniff at a C# position. I also have several years of Oracle 8 and several of SQL Server, but couldn't get an interview for a position that required someone with Oracle 9 experience.

matsp
07-21-2008, 07:58 AM
I think the "what's required" and "what's optional" varies from position to position, and also who is involved in sorting out CV's for interview, how many potential candidates come forward, etc, etc.

In some companies, the person first receiving the CV's is some admin staff in HR - at this level, it's just true or false if you fulfill the criteria or not - and if there are candidates that DO fulfill the requirements they are sent forward to the engineering manager or whoever is responsible for hiring new software staff. Once you have got past the "admin stage", you are probably at a level where the person looking at your CV is (within reason, at least) qualified to determine if you are capable of learning a new language or not (or picking up the differences between Oracle 8 and Oracle 9 for that matter).

Of course, if there are NO qualified staff (say that the company uses say Haskell, which isn't exactly the most commonly used language in the world, and also needs someone with Real-time kernel knowledge and understanding of networks under TCP/IP), then it becomes a "closest fit" problem, and it's probably not someone with more software engineering skills that determine whether you are a reasonably good fit or not.

Finding a job involves several factors:
- Luck of applying to the right company at the right time.
- Persistence and not giving up until you get a job you like.
- Living in the right area or finding a company with remote working capabilities.

--
Mats

brewbuck
07-21-2008, 08:16 AM
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.

I don't know if managed code makes people "stupid" but they certainly open up the field for a whole slew of programmers who maybe could not be effective without the managed environment as a support system. We have millions of potential programmers on the planet but not every one of them is going to be the kind of superstar necessary to write solid unmanaged code.

The world needs programmers. If managed frameworks are what it takes to get more of them writing code, then managed code is a necessary step. Like you say, there will never be zero market for people who can program closer to the hardware. The computers won't work without those people.

Mad_guy
07-23-2008, 01:25 PM
Software is only getting more and more complicated. And that isn't going to change any time in the near future.

Because of it, I think it is in our best interest to seek out abstractions and tools that make expressing these problems easier and more robust overall. Higher level languages facilitate this - they take away some of the common burdens that are simply natural to deal with when you're closer to the hardware. You can argue that with enough encapsulation or templates etc. etc.. that you can achieve the same thing, but you're only covering up the problem and not making it go away. Past a certain point it is simply more efficient economically and logically to invest in something else, something that can get the job done quicker and with better results in the same amount of time or less.

Having said that, I think for a programmer knowing something like C is fundamental; it is on the opposing side of the spectrum when compared with a lot of languages that are flourishing today (Java/C#, etc.) You can more accurately appreciate what higher level languages give you.

I don't particularly think managed code makes people stupid, in many cases it can be a benefit. But it's essential to know what you're dealing with at a more fundamental level if you want to get the most out of what you're using.

abachler
07-23-2008, 02:11 PM
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.

matsp
07-23-2008, 02:15 PM
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

VirtualAce
07-23-2008, 03:38 PM
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.

Mad_guy
07-24-2008, 01:53 AM
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 (http://erlang.org). 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.

nvoigt
07-24-2008, 04:39 AM
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.

Mario F.
07-24-2008, 05:54 AM
* 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?

indigo0086
07-24-2008, 07:49 AM
does using smart pointers make you dumb?

matsp
07-24-2008, 08:00 AM
does using smart pointers make you dumb?

Yup, definitely ;-)

--
Mats

indigo0086
07-24-2008, 08:04 AM
Well I do know reading Mad_guy's post makes me feel dumb. *goes back to fifth read through of quaternion math*

Mad_guy
07-24-2008, 08:28 AM
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.)

Mario F.
07-24-2008, 12:01 PM
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?

mike_g
07-24-2008, 06:33 PM
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.

zacs7
07-24-2008, 06:57 PM
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 ;)

Mario F.
07-24-2008, 07:55 PM
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.

CornedBee
07-24-2008, 08:25 PM
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.

Mad_guy
07-25-2008, 08:53 AM
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?

This might be tough; erlang has a mechanism called 'ports' which let Erlang communicate with non-erlang languages, and as well, you can also write linked-in drivers for the erlang runtime which will essentially give you a foreign function interface, but beyond that I do not think it's possible to link the erlang virtual machine itself into something like a library/shared object. Here are some resources that might provide some information in that area, though:

http://www.erlang.org/doc/
http://www.trapexit.org/

Specifically you will want to look at the 'interoperability tutorial' on the erlang.org documentation pages.


Well I do know reading Mad_guy's post makes me feel dumb.
Do not be disheartened, I am extremely weak at things like math (when I go to uni. for the first time in a month or so I'll only be doing algebra)! I tried as I could to make the above post approachable to those who do not have first hand experience with a language like haskell, and if you have questions I would be happy to answer and can likely explain it to you in easier terms. :]

Mario F.
07-25-2008, 09:37 AM
but beyond that I do not think it's possible to link the erlang virtual machine itself into something like a library/shared object

I was thinking more on the line of something like HiPE (pdf (http://www.astec.uu.se/Reports/Reports/9904.pdf)). I understand this is for SPARC, but my readings tell me there's a x86 Linux version too. I assumed before there would be a Windows version, but it seems there are problems implementing one.

Sang-drax
07-28-2008, 02:53 AM
Today, I mostly use MATLAB for development, which is an "extremely managed" language. Nevertheless, it come with a JIT compiler and some projects, written in a couple of days, would take months to write faster (or at all!) in C or C++, due to the heavily optimized standard libraries.

I don't know about Haskell, though. As far as I know, it's not very widely used.

Mad_guy
07-28-2008, 04:10 PM
I understand this is for SPARC, but my readings tell me there's a x86 Linux version too. I assumed before there would be a Windows version, but it seems there are problems implementing one.
HiPE is now apart of the standard erlang distribution. But it doesn't generate an object-file; it generates a 'fat binary' with the native code alongside the regular BEAM code that is in a .beam file. When you run it, the native code is executed instead.

There doesn't seem to be much of a push to get it on windows, however.


As far as I know, it's not very widely used.
For appropriate definitions of "widely," sure. Regardless it still has an active community, is growing every day and (I think, anyway) offers an elegant solution to many problems.

Plus learning it will expand your brain, even if you don't use it much for your day-job (I think similarly of other languages like prolog and erlang.) I don't think haskell will ever become truly mainstream; it's greatest legacy will be the impact it has on other languages. :]