Jnr Software Developer

[Pyro]

So, for the newbie:
Something like Java or C# will get you through the basics of dev.

I'm personally not fond of python/perl and am not sure how long they would be useful if server-side JS takes off, but they are used in a lot of open source sites.

The main reason I would suggest a degree is to get your foot in the door. There's a lot of cvs to sift through for Junior positions, so you can cherry pick what sounds best. The alternative is examples of your work or really solid references.

Whatever route you take, some SQL knowledge will also be useful.

At the end of the day there is a LOT of similarly between different languages, so picking up new languages are easier than learning the basics.

 

[cguy]

Erm... what has a C/C++ handbag fight got to do with the OPs original question? This is one serious highjack. :wtf:

It's actually one of the reasons I've been pushing for Swa to give us some info on his background, I think it can be related to the OP.

Some languages, like C, are not OOP. But they allow a degree of emulating OO thinking in the code, as previous posters have shown. But because OO is not native to such languages, you have to implement so much emulation that is it questionable as to why you would do it.

Heresy! Although in C, it's really not that way out there, and doesn't require very much (but certainly not zero) coding overhead, which is why so many people do it.

But you have to ask yourself why you want to do it. As an academic excercise in a d!ck swinging contest, maybe. On a platform without OO compiler or large legacy C codebase, yes maybe. But why the fark will someone in their right mind do that on a platform that offer true OOP tools?

A lot of code has to be written for the lowest common denominator platform. So although your PC WIFI adapter could in theory have it's code written in OO C++, part of the driver stack is common for driving devices on some embedded systems that may not support C++ (or not properly at least - it's much harder to compile, and has less predictable output code structure).

Another reason is performance - although C++ can in theory compile to anything C can, the usage of standard C++ constructs contributes to less efficient code, especially when many developers work on the same project. Specifically, the issues tend to arise from implicit code execution, such as constructors, copy constructors, destructors, operator overloading, exception handling, etc. In C, you can look at a function, and without contextual knowledge, know exactly what is being executed - the only invisible code, is the code at the other end of function calls, which once again are explicit in the code.

The lack of implicit code generation is also one of the reasons that Linux uses C. Performance is often cited, but so is the fact that having implicit code execution in something like a driver or OS kernel, is generally a bad idea (I've personally worked on a C++ driver before, and found all these problems to be oh too real).

There are some other more exotic reasons such as improved compile time (I've seen applications that require mission critical compilation speeds, for live fast turnaround debug and deploy), less ambiguous simpler standardizations, and more mature compilers that actually match the standard (partially because of the simpler standard), improving cross platform consistency.

 

[CheekyC]

A lot of code has to be written for the lowest common denominator platform. So although your PC WIFI adapter could in theory have it's code written in OO C++, part of the driver stack is common for driving devices on some embedded systems that may not support C++ (or not properly at least - it's much harder to compile, and has less predictable output code structure).

Another reason is performance - although C++ can in theory compile to anything C can, the usage of standard C++ constructs contributes to less efficient code, especially when many developers work on the same project. Specifically, the issues tend to arise from implicit code execution, such as constructors, copy constructors, destructors, operator overloading, exception handling, etc. In C, you can look at a function, and without contextual knowledge, know exactly what is being executed - the only invisible code, is the code at the other end of function calls, which once again are explicit in the code.

The lack of implicit code generation is also one of the reasons that Linux uses C. Performance is often cited, but so is the fact that having implicit code execution in something like a driver or OS kernel, is generally a bad idea (I've personally worked on a C++ driver before, and found all these problems to be oh too real).

There are some other more exotic reasons such as improved compile time (I've seen applications that require mission critical compilation speeds, for live fast turnaround debug and deploy), less ambiguous simpler standardizations, and more mature compilers that actually match the standard (partially because of the simpler standard), improving cross platform consistency.

I can buy that. Source code portabilty across platforms, esp embedded ones is a great bonus. And yes for an OS kernel it is a diff story.

But the OP's question as a noob was to determine what the best language was to adopt. In all likelyhood he is not going to contribute to a Linux kernel, or write device drivers or develop embedded code. So the whole C/C++ handbag sling is moot.

OP wants to get into the job market ASAP. To that question, my suggestion is as a minimum for backend type work:
- C# (as it is a better lang to start off on than C++ and there is huge demand)
- definately some basic SQL (the query lang, not necessarily the MS product)
and/or
for front-end type work
- javascript
- ASP.NET MVC
- HTML5/CSS

Regardless of where OP fits in, good pratices like
- Dependency Injection, OO Design, SOLID, etc
- also skill up on design patterns in general


Hell, if the OP gets skilled up, I will even employ him... But skilling up is gonna take a lot of time and effort from OP to invest in himself. And even then being a good programmer is not guaranteed.

 

[cguy]

I can buy that. Source code portabilty across platforms, esp embedded ones is a great bonus. And yes for an OS kernel it is a diff story.

But the OP's question as a noob was to determine what the best language was to adopt. In all likelyhood he is not going to contribute to a Linux kernel, or write device drivers or develop embedded code. So the whole C/C++ handbag sling is moot.

Agreed. My recommended language for the OP was and is C#. The rest of the thread has been an attempt to stem the massive amounts of misinformation being pushed by Swa (such as the idea that C++ is the must have skill for desktop apps).

 

[semaphore]

I can buy that. Source code portabilty across platforms, esp embedded ones is a great bonus. And yes for an OS kernel it is a diff story.

But the OP's question as a noob was to determine what the best language was to adopt. In all likelyhood he is not going to contribute to a Linux kernel, or write device drivers or develop embedded code. So the whole C/C++ handbag sling is moot.

OP wants to get into the job market ASAP. To that question, my suggestion is as a minimum for backend type work:
- C# (as it is a better lang to start off on than C++ and there is huge demand)
- definately some basic SQL (the query lang, not necessarily the MS product)
and/or
for front-end type work
- javascript
- ASP.NET MVC
- HTML5/CSS

Regardless of where OP fits in, good pratices like
- Dependency Injection, OO Design, SOLID, etc
- also skill up on design patterns in general


Hell, if the OP gets skilled up, I will even employ him... But skilling up is gonna take a lot of time and effort from OP to invest in himself. And even then being a good programmer is not guaranteed.

Maybe im being a bit pedantic, but ASP.NET MVC is not frontend work its a pattern running on the .NET platform it still falls under html/css/javascript.

 

[CheekyC]

Maybe im being a bit pedantic, but ASP.NET MVC is not frontend work its a pattern running on the .NET platform it still falls under html/css/javascript.

Yes you are pedantic.. But yes MVC is a pattern to ultimately serve html/js/css to the browser. But to me it classes as front end work as it relates to the UI as opposed to server-side services (which can be any technology). To me there is a very hard line between front end and server. Server referring to some kind of service layer and not the DB server.

 

[semaphore]

Yes you are pedantic.. But yes MVC is a pattern to ultimately serve html/js/css to the browser. But to me it classes as front end work as it relates to the UI as opposed to server-side services (which can be any technology). To me there is a very hard line between front end and server. Server referring to some kind of service layer and not the DB server.

Well then im afraid your classification is wrong because the preprocessor and dlls run server side for asp.net mvc And service layers can run in the web domain as well not just server side a service can also be an exposed api via rest or wcf or whatever.

 

[CheekyC]

Agreed. My recommended language for the OP was and is C#. The rest of the thread has been an attempt to stem the massive amounts of misinformation being pushed by Swa (such as the idea that C++ is the must have skill for desktop apps).

I would NEVER EVER recommend C++ for a noob. Also not for desktop apps. It's like giving him rope to hang himself. Yes once he gets experienced, he can do C++ if he really feels the need.

I started from C then C++ then C# and some others in between. I paid lots of school fees in terms of mistakes I made (before the days of the internet). C/C++ requires LOTS of discipline and has a steep learning curve. Memory management, pointers, collecting your own garbage, etc etc. Lots of pitfalls that most programmers starting out nowadays simply cannot afford in terms of the time it takes.
Also I think the market for C# is far greater than C++.

 

[CheekyC]

because the preprocessor and dlls run server side for asp.net mvc

Yes I am aware of that but I am referring to the logical separation of UI vs backend rather than physical.

 

[semaphore]

Yes I am aware of that but I am referring to the logical separation of UI vs backend rather than physical.

Fair enough i'm just having fun, within your few posts you've already known a much vaster knowledge than Swa i mean C# is just a fad after all

 

[_kabal_]

It's like playing chess with a pigeon. It doesn't matter how well you play, the pigeon's still gonna knock over all the pieces, poop on the board and strut around like he won.

.

 

[Swa]

To summarize:
1) obj->method(obj, p1, p2) rather than obj->method(p1, p2), totally kills the paradigm.
2) You don't get that in terms of implementation, functional inheritance is just pointer table replacement, and that attribute inheritance is just extending an attribute list - easily handled without attribute repetition or object embedding using some simple macros.
3) Go cheeseburger!
4) Disliking C++ means that Linus Torvalds isn't actually using OO when writing his C code like he thinks he is.
5) Yelling "Go cheeseburger" enough times means that you've won the "debate". I bet you win all your debates, and find it strange that the world is always wrong.

We've got the picture - your reasoning skills are clearly beyond reproach.

No, to summarise:
1) Using obj->method(&obj) kills it because you're moving away from object oriented paradigm. You are no longer thinking mainly about the object but how you are going to implement your procedure. Iow the object is losing the focus. Even more so if you use method(&obj). This can still be overlooked perhaps, even with all the problems it can cause, if the rest took an object oriented approach and you can even use a this pointer to make it seem more natural. But alas you have been unable to show that it does.
2) Of course virtual function inheritance is a pointer replacement. What you don't get is that there is no direct support for that so any way you try to implement it is likely to cause problems. By using macros for inheritance are you referring to something like this? Besides still using object embedding it's a terribly long winded approach. Proving again my point that instead of focusing on the objects themselves you are trying to figure out how to implement your paradigm. Better hope that all attributes are correctly aligned. Something which is easier said than done especially when multiple inheritance enters or you have function pointers.
4) No the fact that nobody has shown how you are going to implement it in an object oriented manner. His commentary that he dislikes it (to put it mildly) is just an indication that he's biased and so negates his authority. You were trying to appeal to authority here?
3,5) Stop with the cheeseburger stuff. It just shows that you have no idea of what's being said.

BTW, Hamster also wants to know what and where you studied.

And like you it's only after his points were defeated. It's like two people doing a maths problem and using basic rules one shows the other why their solution is wrong. That person then jumps up and shouts "but I'm the professor and you're the grade 6 pupil. I refuse to entertain such arguments especially on an anonymous forum. If someone is a real authority on a subject it should be evident in the knowledge they display.

http://lwn.net/Articles/444910/

Lets see swa argue that with the guys who wrote the linux kernel didnt emulate parts of OOP or he most likely thinks he knows more about c than linus

And like I already said you CAN emulate parts of it. But emulating it doesn't make it OOP. The way you have to go about in order to implement and make it work has provided enough illustration that your focus is on procedural coding and not the objects themselves defeating the whole purpose of OOP.

A lot of code has to be written for the lowest common denominator platform. So although your PC WIFI adapter could in theory have it's code written in OO C++, part of the driver stack is common for driving devices on some embedded systems that may not support C++ (or not properly at least - it's much harder to compile, and has less predictable output code structure).

Another reason is performance - although C++ can in theory compile to anything C can, the usage of standard C++ constructs contributes to less efficient code, especially when many developers work on the same project. Specifically, the issues tend to arise from implicit code execution, such as constructors, copy constructors, destructors, operator overloading, exception handling, etc. In C, you can look at a function, and without contextual knowledge, know exactly what is being executed - the only invisible code, is the code at the other end of function calls, which once again are explicit in the code.

The lack of implicit code generation is also one of the reasons that Linux uses C. Performance is often cited, but so is the fact that having implicit code execution in something like a driver or OS kernel, is generally a bad idea (I've personally worked on a C++ driver before, and found all these problems to be oh too real).

There are some other more exotic reasons such as improved compile time (I've seen applications that require mission critical compilation speeds, for live fast turnaround debug and deploy), less ambiguous simpler standardizations, and more mature compilers that actually match the standard (partially because of the simpler standard), improving cross platform consistency.

Ok some valid points there except for the part about interfacing with other software. It doesn't matter what language it's written in as long as the calling conventions between different functions are the same. This begs the question if OOP is so inefficient to use then why on earth would you want to emulate any of it in a language that doesn't even support it?

Agreed. My recommended language for the OP was and is C#. The rest of the thread has been an attempt to stem the massive amounts of misinformation being pushed by Swa (such as the idea that C++ is the must have skill for desktop apps).

My original comment still stands. Something like C++ is the way to go for desktop apps. I never said exclusively. If you disagree you are welcome to give your own recommendation but instead you and semaphore decide to try and tare it apart based on your own imagining of what was said and what not and take the thread on one big derail.

Fair enough i'm just having fun, within your few posts you've already known a much vaster knowledge than Swa i mean C# is just a fad after all

Yeah continue to make your own assumptions instead of reading what's actually written. _kabal_'s describing your style of reasoning perfectly here.

 

[cguy]

No, to summarise:
1) Using obj->method(&obj) kills it because you're moving away from object oriented paradigm. You are no longer thinking mainly about the object but how you are going to implement your procedure. Iow the object is losing the focus. Even more so if you use method(&obj). This can still be overlooked perhaps, even with all the problems it can cause, if the rest took an object oriented approach and you can even use a this pointer to make it seem more natural. But alas you have been unable to show that it does.
2) Of course virtual function inheritance is a pointer replacement. What you don't get is that there is no direct support for that so any way you try to implement it is likely to cause problems. By using macros for inheritance are you referring to something like this? Besides still using object embedding it's a terribly long winded approach. Proving again my point that instead of focusing on the objects themselves you are trying to figure out how to implement your paradigm. Better hope that all attributes are correctly aligned. Something which is easier said than done especially when multiple inheritance enters or you have function pointers.
4) No the fact that nobody has shown how you are going to implement it in an object oriented manner. His commentary that he dislikes it (to put it mildly) is just an indication that he's biased and so negates his authority. You were trying to appeal to authority here?
3,5) Stop with the cheeseburger stuff. It just shows that you have no idea of what's being said.

You just don't get it. You're rehashing the same crap, and your ability to reason is shocking. Stop it - you are boring everyone. And no: "No, YOU'RE <something cguy said>." is not a valid counter argument.

And like you it's only after his points were defeated. It's like two people doing a maths problem and using basic rules one shows the other why their solution is wrong. That person then jumps up and shouts "but I'm the professor and you're the grade 6 pupil. I refuse to entertain such arguments especially on an anonymous forum. If someone is a real authority on a subject it should be evident in the knowledge they display.

I've never said anything of the sort - you're making false assumptions about what I will do with that information. I have no intention of comparing your education to mine, and I'm not trying to discredit you based on your education or lack thereof - you've done an infinitely better job of doing that all by yourself. I think that given the amount of crazy you've spewed out - it would be a good anecdote to know if this comes from a position of lack of education (in which case, I would strongly suggest that you pursue some formal education), or if you have an education, it would be a good example of how education isn't always all it's cracked up to be.

Ok some valid points there except for the part about interfacing with other software. It doesn't matter what language it's written in as long as the calling conventions between different functions are the same.

I'm not talking about interfacing with other software - I'm saying that if a piece of the stack needs to run on a platform that only had a C compiler, then that piece of the stack has to be written in C.

This begs the question if OOP is so inefficient to use then why on earth would you want to emulate any of it in a language that doesn't even support it?

Seriously? That's what you got from my comment? I didn't say that OOP was inefficient - you just don't know what OOP is.

 

[Fuma]

What if Swa is cguy?

 

[Necuno]

What if Swa is cguy?

or semaphore ?

 

[semaphore]

or semaphore ?

Nah i wouldn't stoop to that level it has however been amusing and fun.

 

[cguy]

What if Swa is cguy?

Nope. As amusing as it would be to play him - like they said in Tropic Thunder: Never go full ...

 

[Swa]

You just don't get it. You're rehashing the same crap, and your ability to reason is shocking. Stop it - you are boring everyone. And no: "No, YOU'RE <something cguy said>." is not a valid counter argument.



I've never said anything of the sort - you're making false assumptions about what I will do with that information. I have no intention of comparing your education to mine, and I'm not trying to discredit you based on your education or lack thereof - you've done an infinitely better job of doing that all by yourself. I think that given the amount of crazy you've spewed out - it would be a good anecdote to know if this comes from a position of lack of education (in which case, I would strongly suggest that you pursue some formal education), or if you have an education, it would be a good example of how education isn't always all it's cracked up to be.

Yeah whatever man. You are constantly rehashing the same crap assuming it somehow proves your approach is object oriented. What _kabal_ said of pigeon chess is very accurate here. And I have a pretty good idea of why you asked about my qualification and the way you asked it.

I'm not talking about interfacing with other software - I'm saying that if a piece of the stack needs to run on a platform that only had a C compiler, then that piece of the stack has to be written in C.

You are making no sense here. Most compilers are available for a wide variety of platforms and if they can't run on the platform there is at least the option to compile code for the platform. While there may be some situations where it does apply it's far from being a lot.

Seriously? That's what you got from my comment? I didn't say that OOP was inefficient - you just don't know what OOP is.

Are you kidding? Reread what you've written. What you mentioned (bar exception handling) are language constructs specifically for supporting OOP. And you complain about the performance of these but want to emulate them. That doesn't make any sense and is a good indication that you are the one who doesn't know what OOP is.

 

[cguy]

You just don't get it. You're rehashing the same crap, and your ability to reason is shocking. Stop it - you are boring everyone. And no: "No, YOU'RE <something cguy said>." is not a valid counter argument.

Yeah whatever man. You are constantly rehashing the same crap

you just don't know what OOP is

you are the one who doesn't know what OOP is.

Are you five?

Look, your problem is that you aren't capable of understanding what semantics are - you're convinced, however, that you have a great understanding of them because you suffer from the Dunning-Kruger effect. This means that we are at an impasse. My only reason for arguing with you is to try and clarify your understanding of this issue and to make sure that your silly beliefs aren't perpetuated - at this point, I don't believe that you are capable of learning anything, and I don't believe that anyone will take you seriously either.

Due to the above, you probably believe against all evidence, that I and the others that chimed in just don't share your deeper understanding, and that anyone reading this thread will be impressed with the concise way you refute all arguments by simply stating your original position again, and side with you. So maybe you can stop wasting everyone's time, and sit back and nod contentedly to yourself, knowing that from now and into perpetuity, you will always be right.

 

[Necuno]

cguy, funny that you mention it... last night I was reading about it:
Why the stupid think they’re smart