Suggest a career/learning path for a php developer

Hello guys, As the title says, I am a Php developer (can also do nodejs work) looking to start working in C as well.
I have 3-4 years worth of experience working for companies and doing freelance on freelancer and elance.


So why C? Well i am really interested in developing for embedded systems. Unfortunately, I am a bit overwhelmed, or perhaps my mind is a bit over loaded from studying too many
ebooks on embedded systems.


so let me break down my questions


1. Unfortunately, there are no C or C++ jobs available where i live (pakistan), So i hope
to continue as a freelancer and work remotly as i do with Php. Is that even possible? If
yes, Do i focus on C or C++, or both.


2. About Embedded Systems. I can get a Bread board and start playing. However, im not sure where to go from there.
Architectures confuse me, at this point i don't know the difference and the terms used for hardware and currents can be a lot to absorb at times. So what do i do next after i got a few Leds to blink on a bread board?

Hoping to get some advice and answers. I also love to get in contact with anyone, experienced or not, just to learn and share knowledge on skype or emailing. It's all about learning :D

I am a (newly graduated) embedded developer, so I know the industry fairly well.

I have never heard of anyone doing embedded work remotely, because well, for embedded systems, there's an inherent physical component.

In my day to day work, we work closely with hardware engineers to debug problems that can either be hardware or firmware, and often go back and forth multiple times a day. That is the same for all companies doing embedded development that I have worked for or know of. I don't think it's possible to work remotely in embedded development.

This is unlike websites where there is usually nothing physical, and most projects are fairly independent.

Embedded systems is an endlessly fascinating subject, so I do encourage you to learn more about it, but I wouldn't expect being able to find a job working remotely. It's very difficult even for local people (I am in Canada, but have also worked in and am pretty familiar with the Silicon Valley) to find work in embedded dev without at least couple years of experience, or a degree. It's a very broad field that requires both very good skills on the software side, and reasonably good knowledge on the hardware side, and not many people have that combination.

C vs C++: Ideally, you should know both. You might also throw in Ada into the set. It's vastly under appreciated in the industry, but it's a good language. The more languages you know, the better. Although if you ask me, then C is an abomination. Embedded systems are often constrained and cannot be easily updated, which means that it must be high quality from the start. C is directly contrary to this since it's low level, complex and easy to get wrong. C++ is better in this regard, but Ada is even better. I honestly think that is a good thing to think about, but unfortunately, many projects in the industry are locked to C because people are ignorant or due to legacy restrictions.

In larger embedded systems (32-bit processor), C++ is probably more common than C now.

Smaller embedded systems are mostly still on C/asm due to extreme memory and storage constraints, but the scales of the projects are so small that the language doesn't really matter anymore. They are mostly things like a tiny 8-bit microcontroller controlling speed of a fan, or temperature of some industrial process, etc.

Quote:

---

Originally Posted by Elysia

Although if you ask me, then C is an abomination. Embedded systems are often constrained and cannot be easily updated, which means that it must be high quality from the start. C is directly contrary to this since it's low level, complex and easy to get wrong. C++ is better in this regard, but Ada is even better.

---

One of the biggest misconceptions about C is this idea that you can easily shoot your foot with it. It is used as a joke to signal the dangers of careless memory allocation in C. An issue most C programmers are fully aware of and few known problems arise about it despite the extensive use of C in embedded systems. Why a "shot in the foot" developed from a warning to developers into full blown criticism of an entire programming language is still something I don't understand, particularly when coming from C++ advocates who also have plenty of ways to hurt their feet.

As for Ada... too verbose for my taste. I could properly write an entire novel with less words than those needed to program for an RTOS.

Quote:

---

Originally Posted by Elysia

I honestly think that is a good thing to think about, but unfortunately, many projects in the industry are locked to C because people are ignorant or due to legacy restrictions.

---

Or maybe we should apply common sense and think that "many people" can't be wrong.

Quote:

---

Originally Posted by Mario F.

One of the biggest misconceptions about C is this idea that you can easily shoot your foot with it. It is used as a joke to signal the dangers of careless memory allocation in C. An issue most C programmers are fully aware of and few known problems arise about it despite the extensive use of C in embedded systems. Why a "shot in the foot" developed from a warning to developers into full blown criticism of an entire programming language is still something I don't understand, particularly when coming from C++ advocates who also have plenty of ways to hurt their feet.

---

There are plenty of ways to shoot yourself in the foot in C and it provides scarcely few tools to help prevent it. So that's when you turn to 3rd party tools and that's when it starts getting messy. C++ is a little better in this regard, but it still has a lot of flaws. But it is still better than the abomination that is C in my opinion. Too few tools to create proper programs, even for constrained systems.

Quote:

---

Or maybe we should apply common sense and think that "many people" can't be wrong.

---

You know as well as I do that that is wrong on so many levels. You can't just take peoples' words and make it into truth when writing scientific papers, so I very much doubt that "many people" cannot be wrong.
If there is a consensus between several well-known experts, then that is a good argument. But otherwise, I don't buy it.
C is still an abomination in my opinion, though. I prefer strongly typed object oriented languages such as Ada before C.

Quote:

---

Originally Posted by Elysia

There are plenty of ways to shoot yourself in the foot in C and it provides scarcely few tools to help prevent it. So that's when you turn to 3rd party tools and that's when it starts getting messy. C++ is a little better in this regard, but it still has a lot of flaws. But it is still better than the abomination that is C in my opinion. Too few tools to create proper programs, even for constrained systems.

---

Your constant attack on a widely used language is as old as it has become annoying. It's becoming hard to ignore you on this matter, just like the constant buzz of a fly. Especially when you seem always too eager to disseminate it at every opportunity, despite having spent years listening on these forums to the counter arguments of people far more knowledgeable than you. You don't even realize it is not valuable information you provide, but simply verbal diarrhea caused by your stubbornness born out of ignorance and zealotry. You remind me of Linus Torvalds. How ironic is that?

Many of the things that make C an horrible programming language (as you put it) don't seem to worry C developers. Maybe you should become a C developer and experience the language first-hand.

What you persistently fail to realize is that C++ is as insecure as a programming language as is C. No less. C++ offers your tools, as you say. But these require a working knowledge of the language pitfalls to be used effectively (and in many, many cases they have been used incorrectly). This is, by far and wide, the exact same principle behind C programming. You are required a working knowledge of the C programming language pitfalls in order to write correct code. The proof of this is this world were you live in, strongly populated by correct and error free C code.

Idioms like RAII or language features like casting operators do not make C++ a more secure language. They simply expose the language weaknesses. Besides it's impressively easy to misuse these features with the added trouble of gaining a false sense of security. If you feel secure by these features that's because you gained the necessary knowledge to use them. C draws the same parallel with C programmers. Wake up.

Quote:

---

Originally Posted by Elysia

C is still an abomination in my opinion, though. I prefer strongly typed object oriented languages such as Ada before C.

---

Your opinion is an abomination in itself. Because it has historically dismissed any argument thrown at you and have historically refuse to look objectively at C as a working programming language in its own right. Few care to hear you on this matter anymore, of that I'm sure. It's your spread of your false religion that irritates me. You just can't shut the hell up.

My local power plant wanted php developers.

Quote:

---

Originally Posted by Mario F.

Idioms like RAII or language features like casting operators do not make C++ a more secure language. They simply expose the language weaknesses.

---

I don't think idioms "simply expose the language weaknesses" in themselves. Idioms are well known patterns of programming that may be particular to a programming language. Sometimes, these are conventions adopted as a workaround for some language weakness, but at other times they may simply be a best practice to make use of the strengths of a language. I think RAII is an example of the latter.

I agree. But by "expose" I mean their existence make the languages weaknesses more apparent. They act like loud warning signs. But this is no different than C, because this language has rooted itself too in idiomatic expressions. Many of which with the exact purpose of increasing the code robustness and handling common language pitfalls, by offering code workarounds or taking advantage of the language strengths.

A typical language strength idiom in C might be the dealing with malloc dependency:

Code:

---

// bad
Foo* bar = malloc(sizeof(Foo));

// idiom to handle malloc dependency
Foo* bar = malloc(sizeof *bar);

---

It's interesting to note that we are also taking advantage of a language feature. We can easily draw a parallel between the sizeof operator compile time check in C and casting operators in C++ as both being language features that have the potential of offering more robust code, but which can both be useless in the hands of someone without a working knowledge of the programming language pitfalls.