Sadly you are required to move for such jobs, which is not always an option.
Compare this with C. There is a degree of serious technical focus that languages like these demand for big projects. Embedded systems, Operating systems, Databases, compilers etc. A big part of software world uses these languages on a daily basis. But there is no where the kind of hipster crowd, these languages have the web frameworks or languages have.
Even if you spend some time searching for resources on the net, there are few that teach deep C skills. There might be one or two books out there which haven't been updated in 2 decades.
By and large, these are unfashionable fields to work in. The barrier to entry is really high, Success comes only with seriousness and application of well focused effort, mistakes are expensive and they warrant serious RTFM'ing the hard way- to write to some real serious code.
Sure some languages take less time to learn than others. But every single language makes tradeoffs. For e.g performance vs productivity/usability OR static typing vs dynamic typing is a common theme when discussing C vs {Java, Python, blah}.
Also, your comments falsely compare the difficulty of the TASK with the difficulty of the IMPLEMENTATION/LANGUAGE. They are not the same! Take any advanced applied math algorithm and implement it in Python. Its not 'easy' by any means.
The domains you mentioned have a higher barrier to entry because the tasks themselves are difficult. The languages and technology used are simply variables in a much larger optmization problem that also includes monetary/human/computing/time resources as variables.
Personally I don't care about C, due to its unsafe by default design and my background in safer languages for systems programming.
I got my first computer, a Timex 2068, at the age of 10. Spent two years mainly playing games and eventually started looking into programming.
When I learned C, at the age of 16, I already knew BASIC (Spectrum, GW, Quick, Turbo), Assembly (Z80, x86, 68000), Turbo Pascal.
So C was for me a bit "meh" language, given that Turbo Pascal gave me much more, granted except for portability. So I quickly jumped to C++, which allowed me some strong typing comfort and higher abstractions in a forced C land.
Regardless of the language, when I was 18, I had already coded compilers, graphics applications, GUI prototypes, MS-DOS drivers.
Nowadays kids seem just to do JavaScript/Python/Ruby frameworks for generating web pages.
That's progress, IMHO.
Instead of distributing application binaries carefully targeted to each type of user machine, we only have to run the application on one server machine (or a cluster of them) in a central location and can serve the application over the network. We now have code-generating frameworks that help automate away much of the tedious, repetitive parts of implementing an application.
It's not a good thing that software development is hard. It does mean that you're a very smart and hard-working person if you're able to do it effectively. But it's not a good thing for society that you need to be so smart and hard-working in order to do it.
It is, however, a good thing that it's not as hard as it used to be. The fact that a software developer has to do and know less today than they did 20-30 years ago, just to build an application and distribute it to a large number of users, is a sign of progress.
it has pointers, pointer arithmetic, manual memory allocation, function pointers, casts, unions, you name it.
I bet you could write could write 30 odd rules for cpp and then compile your "pascal" with cc, e.g.:
#define begin {
#define end }
#define := =
#define ^ *
#define @ &
and so on
- It has real strings
- Arrays don't decay to pointers
- It has reference arguments, which avoid pointer usage for records and out arguments
- Requires explicit casts for type conversions, instead of implicit type casts
- Provides region allocators, which allow to release a full block of memory in one go
- Has real enumerations that don't decay into ints
- Allows writing generic code over arrays without requiring the developer to manage a separate length variable
- Has proper memory allocation constructs instead of requiring the developer to know the size of memory to allocate
Finally, there are other languages in the Pascal family, that provide safety, while allowing for C dirty tricks done explicitly via a system/unsafe package which provides much fine control over the use of said features.
pascal style strings can be done with the preprocessor, as can generic iterators, allocation for idiots, and "out" function arguments.
memory pools are a library feature.
and the arrays are the same too, a pointer in pascal can be treated as an infinitely sized array, but the reverse isn't true, just like in C.
and, believe it or not, there are other languages in the C family, that provide safety in the same way there are for pascal.
tl;dr: pascal and C are more alike than different.
That still does not make them safe, implicit conversion to int will still happen.
> pascal style strings can be done with the preprocessor, as can generic iterators, allocation for idiots, and "out" function arguments.
No type safety.
> memory pools are a library feature.
That aren't part of any C compiler. So you can't count them being available.
> and the arrays are the same too, a pointer in pascal can be treated as an infinitely sized array, but the reverse isn't true, just like in C.
You lost me there.
> and, believe it or not, there are other languages in the C family, that provide safety in the same way there are for pascal.
Yes, that is why I use Modern C++, C#, Java, D and will only use C at gunpoint.
> tl;dr: pascal and C are more alike than different.
True, except in Pascal when bad things happen is because the developer explicitly wanted them to happen.
In C everything goes and to have Pascal's safety back, all modern C compilers provide static analyzers. Thus proving a point about the languages design's.
True. Talent going to waste is sadly nothing new. Has happened, will continue to happen. :(