Re: C++ jobs down another 40%
In article <firstname.lastname@example.org>, "BGB / cr88192" <email@example.com> wrote:
"tanix" <firstname.lastname@example.org> wrote in message
In article <email@example.com>, "BGB / cr88192"
"Chris M. Thomasson" <firstname.lastname@example.org> wrote in message
"tanix" <email@example.com> wrote in message
Kanze <firstname.lastname@example.org> wrote:
On Dec 23, 11:02 pm, red floyd <redfl...@gmail.com> wrote:
On Dec 23, 12:50 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
The number of job adverts in the UK citing C++ has fallen
40% for the second year in a row:
Hey, Jon! Wha'ts the market for F# jobs like?
Well, I just looked at it on Wikipedia:
Looks like another bluff to me. All sorts of bells and whistles.
For me, personally, it is a no go, and primarlily because it is
based on .net framework.
FWIW, here is a fairly portable C# and CLR implementation:
yep, in my case, I acknowledge that mono exists.
looking deeper into the project though, I am personally a little less
it is, IMO, poorly architected and built on terrible code (and terrible
Uggh. That one is going to wait then.
well, I guess it is probably not so bad if:
one only really expects it to work on Linux, and uses MS's .NET on Windows;
makes sure to pretend (sort of) that they are coding on Windows, and stays
clear of Mono's extensions (mostly GTK bindings, glue into a bunch of GNome
related stuff, ...).
personally, I would have assumed making a new GUI API, which was generally
free of being tied to a particular OS-level GUI. I don't like the idea of
coding against a GTK wrapper, as personally I don't want to be tied to
having to use GTK.
but, this is not the end of it, as it is worth noting that Mono itself is
tied to GTK at a very fundamental level (IOW, a lot of the core VM code is
built on GTK's API functions, on GLib, ...).
GUI IS one of the biggest problems.
I had a chance to look at some of those toolkits in passing.
I think there needs to be some portable GUI subsystem so you don't have
to worry about one toolkit on one platform and totally different way
of doing it on another.
Something like it is in Java for example.
Otherwise, they keep reinventing the wheel and none of it you can
rely upon as a single version of your code.
Unfortunately, you need some equivalent of JVM to do it to shield
you from the O/S particularities.
But I think we are at the point where things like JVM or MVM
or that sucky .net are essentially what virtual machines are.
Processing power and memory limitations are no longer there.
It is understood that at a time of P-Machine (Pascal), which was meant
to significantly improve the performance of Pascal, it was unrealistic
to expect that the idea will be accepted, and it was not.
But now things are different.
Basically, the portability, a single way of saying something,
without worrying about the O/S, environment or anything for that
matter is what is needed more than anything else.
I personally think F# is a flop, no matter how many people join
the camp. It is a convoluted, over complicated pile of concoctions
that try to give you all sorts of bells and whistes to the point
that they even try to address the database issues and do some
the same idea of dynamically built code. Except complexities
and the very concepts are as flaky as it get from what I see.
Building a dynamic code that can go as far as dynamically construct
some other code is not exactly a new idea, going back to Forth,
But the very concept is flawed. The code becomes utterly unintuitive.
You can not even comprehend what comes out of it at the end.
problem related to this kind of stuff, good luck. Because it is
going to be a hell for you to fix it and you may have to spend
A while back, I had the same idea, except it was for database
applications. I asked a question: what prevents you from writing
a database stored program where you use the rows to store your
high level instructions? Well, nothing really. I implemented in
and it worked just fine. But then it withered away. Basically,
I stopped working with database.
Now they have it all over the place.
But there are plenty of disadvantages of such an approach.
It lacks the necessary structure. Yes, it is as portable as it
gets, but you don't have that "super-language" syntax. It is
all disassociated set of instructions, no matter how high level
and how powerful they are. It lacks the properties of high
So, my opinion on this is that people think "it would be nice"
to add the ability to construct the programs. But they seem to
fail to comprehend that your very language becomes a nightmare
in the modern world.
Again, people do not have neither time, nor interest to waste
hours of their time to either read some complicated goubledy
gook code, that takes hours just to understand what it does
essentially because of the most horrible, utterly unintuitive
language syntax constructs, and I specifically mean generics.
When and why do you need generics and what does it buy you?
Well, I can find only one place in my code, and that is a relatively
large piece of code, where "generics is a must". Lucky me,
I can not even use generics because it is not supported in
my development environment, thanx to these wars between
Microsoft and Sun.
So, I had to implement it using the "copy/paste antipattern" and
I have about 3 copies of exactly the same logic, dealing with
3 types or argument.
Do I regret it? - Nope. Not to the least.
Did I EVER have ANy problems with it? - Not that I know of.
I don't even notice this code. Works like a champ.
And each of those methods take about 10 lines of code.
Why would I bother to write some ugly code using generics?
I would not even THINK about such a think. UTTERLY usesless.
How many places in your code do you have that do very similar
things? Well, I bet ALL over the place. Would you need to
replace it with generics? Well, try.
One professor from France, a while back said:
Writing programs automatically is just a myth that will never
happen. Because each program is unique and has millions of
nasty little things that distinguish them from something
Otherwise, we would not have a software industry by now.
It would be all generated by the software robots.
And with all the "developments", interfaces, OO approach,
it is still a myth, just the same.
I do not think THIS is the priority of development and THIS
is what is going to imporve the sofware design.
And I do not think that introductions of more and more
complexities into syntax and notation is going to solve
ANYTHING. It is just going to create more and more headaches
as it becomes more and more unintuitive.
Language designers seem to be totally oblivious of the fact
that their language is not exactly what is going on in the
programmers or designer's mind. They need some specific
JOB to be done. Some specific CONCEPT to be implemented,
some specific ARCHITECTURE that will do such and such.
They could care LESS if your obscession with languages means
something to you as language designer. I do not recall many
cases, if any, where I thought: oh crap, I can not do this
and that because my language SYNTAX is screwed up, or my
espressive power is not enough.
But I do recall TONS of cases where I had to waste almost
half an hour of my time looking at some utterly ugly code,
written by some idiot with complex of inferiority, that
probably wasted DAYS of his time to write some generics
goubledy gook code that was not even needed to begin with.
I could do exact same thing with funken C code, not even C++.
And the hell would sooner get frozen before they can prove
ANY advantage of that "purist" code and all those compile
time "benefits" they get out of it.
But no. These suckers need to show the whole world how "smart"
they are. You see, they can OUTSMART you!
What a bunch of sickos, utterly brainless idiots, driven by
the complex of inferiority, forever trying to prove everybody
how "smart" they are. Why do you need to even bother with such
foolish things? I simply can not find a bettter term for it.
I at first put some effort into trying to get it to build from sources on
Windows, but was having far too many difficulties, and personally found the
code a bit nasty, so quickly enough gave up.
Hey. Thanx for your feedback. That is exactly the kind of thing
I need to hear. The last thing in the world I am interested in
wasting weeks, if not months of my time just to eventually realized
I was screwed again by some fools, selling my pussy in the sky with
I later started looking into writing my own .NET implementation, but this
petered out, as my frameworks' architecture started taking shape on its own,
but is not a whole lot like the .NET VM.
actually, my project is a lot more of a chimera (some parts influenced by
the JVM, others by .NET, others by GCC, others by LLVM, ...).
Well, would be interesting to see what kind of thing you came up with.
You can write an article on it. Don't worry about that "off topic" crap.
We'll fight if we have to.
however, I think its only real advantage is that I personally feel the role
of the VM is different, and so there are many "philosophical" differences.
You see, what I am beginning to sense more and more that the solution
to language and portability issues is that very VM as a concept.
And I think Java is a perfect example of it.
Because it demonstrated in practical terms that the whole language
becomes much more powerful (in my opinion) and MUCH more portable
and all sorts of portability related issues could be resolved,
and GUI, threads and garbage collections could be wired right into it.
So, once you have a VM that handles all those nasty details,
you are shielded from ALL sorts of problems and issues.
Yes, that VM probably have to have some web related functionality
wired right into it. Plenty people complain about very primitive,
low level support of web apps in Java, and I trust what they say
and I can see some of it, and I think the language and VM
designers need to pay MUCH closer attention to what they ask for
instead of inventing some ugly even even more complicated stuff
with language syntax and semantics, that turns out to be some
of the most useless thing at the end just because no one really
needs it in forseable future. It all just adds to conceptual fat
at the end.
personally, I rather dislike monolithic architectures. and so, much of the
architecture is based around loosely coupled "modules" or "components", and
some effort is put into making these compoents too specific, even to each
Sure, why not?
so, my beliefs here are that:
the world does not revolve around the VM, the VM framework should "assist"
the app, not "dominate" it;
Well, it does not have to DOMINATE it.
But it CAN assist it, so you don't have to worry inventing another
language to use some of those things, so necessary from the standpoint
of portability, such as GUI, filesystem layer, threads, GC and other
basic and universal mechanisms, needed by just about any app out there.
I don't think you can even argue the case of VM being "evil"
even on an embedded system, even though that is a stretch.
it should be possible to use which parts are needed, and discard the rest
(or supply alterantive implementations, if this is needed);
I totally agree. Dynamic system wiring is probably more beneficial
that most of bells and whistles I see.
the architecture should remain relatively open, as not to overly limit
possible use cases (consider if the VM is composed of lego blocks which can
be put together in different ways under the discretion of the frontend app);
I'd LOVE to see THAT kind of thing.
the VM should also play well with pre-existing technologies (I have tried to
base many of the components after fairly "standard" pieces, and although
imperfect at times, it is possible to use "off the shelf" apps for many
purposes, both to provide input or accept output);
so, I am at odds with both .NET and the JVM on philosophical grounds;
I don't want to even HEAR about .net or asp.
To me, that equates with profound evil, whose only purpose is
to dominate the world. The same thing as NWO, only in sw business.
That stuff is out the window for me, and for good.
From my end, it is RADICAL non acceptance of the whole underlying
philosophy of it, which is nothing more than maximization of the
rate of sucking of the blood of many by the few.
It is total NON portability.
It is a police state equivalent of the "matrix", the sowtware industry
version of it.
It is a dead end that will NEVER, under ANY circumstances,
will either solve any problems we are facing right now,
or make things EASIER in order to make some genuine progress.
It is nothing more than a giant speder web, whose square purpose
is to catch as many flies and get them entangled in a deadly dance.
It is UTTER NON cooperation. It is an idea of total control of destiny
of human kind that eventually translates into a two class society,
the "elite" and "slaves", and this is not just some "conspiracy
theory". This IS the reality of what is going on.
Those anti-globalists are not just some bunch of fools.
I just learned recently that their leader happens to be a former
supreme court justice. Someone who knows this thing so good, that
many sculls are going to get cracked to even comprehend what he knows.
Must be a person of total honesty to take SUCH a grand risk.
He can be killed ANY moment and he knows that all too well.
THESE are the kinds of people that need to be involved in politics,
if we are to get any benefit for ALL, and not just fattest parasites,
sucking every drop of blood they can find from the body of
and, I disagree with LLVM on architectural grounds (granted, I have a mess
here, but personally I just don't really like LLVM's architecture);
Sorry. Do not know what LLVM is.
however, I have tried to minimize creating "novel" parts when possible.
sadly, some level of "novelty" and "internal dependencies" are inevitable it
Sure. There is no way around it. That's the whole trip of it at the end.
thus far, much of the VM revolves around "good old C", both as the language
of implementation, and as the language of scripting. I have attempted to
move beyond C (Java and C# looked like good languages to try to add, and
C# - full stop.
Red siren: WARNING: You are entering the domain of The Head,
Microsoft, the Evil Most Profound.
Unless C# is accepted by everybody and unless it is not a subject
of copyrights and pattents, I would not touch it with a 6 foot poll.
There is simply no need for it to begin with.
C# does not solve anything so radical that is is worth even
bothering with, regardless of how many language "experts" say
it is salvation for mankind.
however, it is all a bit of a "trudging through mud" experience,
And forever so.
remains as the only really "usably complete" language in the mix
Indeed. It is the ONLY true "revolution" in the software industry,
that contributed more to it than all the other stuff combined.
compiler contains a few holes and failings, but for the most part it is
You mean you have your own C compiler? :--}
That made my day!
but, ideally, an app will "use" a framework, rather than be "built on top
What do you mean by that?
and it "should" be a component which can be integrated into a
project (or dropped again) without otherwise requiring significant
this is the ideal, although granted, it is much work to achieve these sorts
granted, nothing is perfect.
in general, I like C# though, as for the most part it seems a fairly
designed language (apart from that it seems to need some level of "black
magic" to be able to parse).
I am a little more hesitant about the rest of the .NET framework though,
would rather it was something capable of being statically compiled and
I just looked at some of it in passing.
Looks like some kind of equivalent of JVM underneeth.
C# is sort of like "Java's big brother" in terms of design. at its core,
they are in many ways fairly similar languages (just C# returns a little
closer to its C and C++ roots, re-adding many more features and
Well, I saw some of that stuff. Never had enough time to get into
it. And what I saw does not make that much of a sense to me.
Just another pile of complications and bells and whistles
that simply make my job MORE difficult and not less,
even though they'd take me up on spears for saying things these,
lil could I care though. Cause I know where I stand and what I need.
in a similar way, the .NET VM architecture is sort of like a "big brother"
to the JVM.
I bet it is a ripoff essentially.
there are many subtle aspects which are similar, but with one
notable and apparent difference:
..NET is FAR more complicated WRT its internal workings.
Well, that IS the very core strategy of Microsoft.
What it is is this: whenever you need to do ANY kind of improvement,
do it in the MOST complicated way possible. So it takes those goats
at least two years to feel comfortable with it.
If you need to add 2 and 2, do it in such a way, that you have five
layers of abstraction. Plug in universal-trans-gallactic,
super duper omnipotent wrapper that won't even run unless they
sign YOUR "protocols". Then document it as little as you can.
And release it under the slogan of "New Revolutionary Technology"
The square purpose of Microsoft is to get everyone entangled into
this gook, and once they are caught, there is no way out.
Then attach your sucking tubes to their body and suck as much blood
as you can manage. Until they can barely breath and walk.
That IS the very core of their "strategy".
The same thing is Google, the manifistation of evil even more
profound from what I know.
Recently I have heard that they have all these zombies running
arount the hallways at Microsoft with plastic smiles, stuck on
their faces, while thinking about ANY kind of crap they can
come up with so it could be "patented".
What Microsoft and Google do right now is to try to patent
ANYTHING they can imagine. They pay people a few hundred bux
if they come up with ANY crazy thing that could be patented.
Not that they have ANY plans to actually use thesse "invention".
But just to prevent ANYBODY from possibly doing it, and if they
DO intent to use it and if they DO invent something, you can
claim: sorry, you can only do it if I attach my sucking tubes
to your body and suck your blood.
The same thing is what Google is doing this very moment.
The consequences are simply horrendous. I just thought about
a couple of things and I had goose bumps, just to see what
could be result of it in my specific situation, even though
I don't think their zombies already patented some stuff I've
(the JVM has a few hairy bits, but in general it is "not that bad", and a
beating together a working basic implementation is a "reasonably" easily
That is ALL that counts at the end.
well, apart from the persisting lack of a class library
(writing Java code in a vacuum is not nearly so compelling).
Well, I even heard some people in Java world complaining that
Java has just WAY to much stuff, which should not belong to
From what I see, this C# stuff is mostly a ripoff of Java.
But that is another matter.
Just look at collections. They are rich enough to fill vast
majority of applications and their performance is as good as
it gets. All the algorithms that I saw are top notch
implementations that approach the theoretical limit of a given
And that is ALL I want to hear about collections.
And if you don't have something that is covered by collections,
well, that is what programmers are for. Keeps you gainfully
employed after all.
In other words, I can not agree with this one.
I'd like to see more substance to this argument.
A single fact that you need to agree with something to even
have your app to run under it, is a total no go for me.
You can not even deliver your J# app as a single executable
is simply berzerk. And now, you can not even compile Java
starting with VC 2008 and higher. Disaster.
little in the language particularly prohibits this, only that I am not
of any standalone C# implementation.
it is, at the moment, a little easier to write standalone Java, since
is both GCJ, and JBC is simple enough as to make it not particularly
difficult to trans-compile to C or ASM
Oh, interesting. Is there a way to generate Java code out
of C++/MFC by any chance?
"there be dragons there".
Java can be compiled to C without too much horror,
Well, I am talking about MFC specifically, and that is GUI
stuff to a large extent, that works totally different than Java way.
I don't think it is a trivial task.
since for the most part
JBC uses a clear subset of C's basic capabilities (although, the translation
is at a fairly low level of abstraction, for example, I operate "underneath"
the JVM's stack model, and essentially remap stack operations to local
variables via a kind of naive graph-conversion algo...).
Cool stuff. Why don't you publish more about it?
Some principles, architecture or what have you.
If you think you can do it or even interested in doing it...
I actually use a plain Java compiler to produce the class files, so that I
could them mostly focus on translating the bytecode to C.
however, C does not map nicely to the JVM (even in the simple case, it is
horridly inefficient, and even more horridly crappy), this much is not
likely worth the bother.
C++ -> Java, if possible, would likely be something too terrible to be
Too bad. Well, what to do? I was just trying to see if I could
save a couple of months of work if I had not rewrite it by hand.
But that's ok. We can live with that.
I would REALLY like to port my monitoring firewall to linux.
The problems are mostly GUI and low level network driver interface.
x86 -> Java or JBC should be possible, but I doubt would be of much
practical use (likely poor efficiency, and the languages would not be able
to really relate or share data at a meaningful level). likewise for just
writing an x86 interpreter.
Well, I did not expect to have much luck. But just in case.
The stuff doe not map from MFC to Java that well.
Baeically, you have to rewrite the whole thing.
But I bet it is going to be the easiest thing in the world,
going from C++/MFC to Java. It would probably be 3 times as hard
to go the other way around. MFC sucks pretty bad as far as sophisticated
GUI goes where you do not use the modal dialogs and where you dialogs
are not some dumb, single threaded, fixed size miniscule boxes,
just like about anything microsoft does, but are fully resizable,
multi-threaded, property sheet/page dialogs.
That thing would be a disaster to implement in MFC.
however, an interpreter would allow, potentially, compiling C++ code to x86,
loading the x86 in an interpreter and running it (at likely crap speeds),
No. Interpreters are totally out of the window for this job.
It is high traffic, high performance situation, where you have
to do all sorts of tricks to make sure you are not blown out
in some situations.
is it worthwhile?... probably not.
it is worth noting that low-abstraction machine-code like representations
(including JBC and x86 machine code) are generally easier to translate and
manipulate effectively, whereas with higher-level forms (such as source
code), one can generally do a much better job and has far more "power".
I don't know what is JBC.
however, JBC can be fairly faithfully converted to C (much easier than many
other possible paths), and does not tend to introduce all that many
hence, it works acceptably to convert Java to C by first compiling to JBC
(AKA: class files), and then translating.
I need C++, and specifically, MFC to Java.
however, this does not extend to the general case, and is very specific to
various internal properties of both Java and JBC.
(although, granted, there are still a few sharp edges, but these are
for example, Java requires that the stack have exactly the same layout at
both the source and destination of a jump, and that the layout of the stack
is required to be constant at a given bytecode position.
the implications of these simple restrictions are notable and drastic, and
without these particular rules, doing an effective translation would have
been a much uglier problem (essentially requiring "simulation", rather than
a value-flow graph-based translation, ...).
just imaging here that every push and pop pushes or pops an abstract
variable, rather than a value, and so the sequence of stack-based operations
can be compared to putting down and picking up the ends of tubes and
plugging them into operations, and then putting down the result-tube, ...
the process, though naive, is elegantly simple, and can convert a method
from a sequence of stack operations, into a graph of interconnected
operations, which can then be (fairly straightforwardly) converted back into
none of this holds with either C, C++, or x86 machine code, OTOH, and hence
such a conversion is not directly possible as such.
Hey. Good article. I really enjoyed it.
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
organized by major topics of language, tools, methods, techniques.