Re: C++ jobs down another 40%
In article <hh66vr$scn$1@news.albasani.net>, "BGB / cr88192" <cr88192@hotmail.com> wrote:
"tanix" <tanix@mongo.net> wrote in message
news:hh4vpq$304$1@news.eternal-september.org...
In article <hh4fo1$7p6$1@news.albasani.net>, "BGB / cr88192"
<cr88192@hotmail.com> wrote:
"tanix" <tanix@mongo.net> wrote in message
news:hh3nuq$14q$2@news.eternal-september.org...
In article <hh3ne4$7k2$1@news.albasani.net>, "BGB / cr88192"
<cr88192@hotmail.com> wrote:
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:xR9Zm.3013$8e4.2445@newsfe03.iad...
"tanix" <tanix@mongo.net> wrote in message
news:hh31vk$82i$1@news.eternal-september.org...
In article
<66e7b0f7-4c71-4db4-a9f1-3f9d7e4dc5a5@a32g2000yqm.googlegroups.com>,
James
Kanze <james.kanze@gmail.com> 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:
http://en.wikipedia.org/wiki/F_Sharp_%28programming_language%29
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:
http://www.mono-project.com
yep, in my case, I acknowledge that mono exists.
looking deeper into the project though, I am personally a little less
compelled:
it is, IMO, poorly architected and built on terrible code (and terrible
coding practices).
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.
Sounds horrible.
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.
Horrible stuff.
yep...
and one can also wonder why parts of the core VM (JIT, PE/COFF machinery,
....) need to be dependent on GTK and GLib (using GObject, ...).
Well, at least I do not have to worry about it.
Probably for historical reasons. After all GTK is one of the oldest
toolkits around.
granted, I guess there is a partial solution, which is to use basically a
stripped-down dummy version of GTK for building the VM, but I dislike this
having been needed in the first place.
I am not sure how easy it would be to do it with something else.
After all, almost anything I saw in terms of graphics on Linux/Unix
looked to me like a nightmare.
What a pitty.
I do not claim I am aware of all the "progress" that has been made,
but I think it is one of the weakest points of Linux/Unix.
Furthermore, from what I recall, it is not even a single layer
of abstraction. There is this dinasaur X11 stuff and on the top of it
some GTK and on the top of that is Gnome if you are talking the O/S
level user interface. But I am exactly a reference point on this.
I did try to look at some graphics related stuff, but every time
I had goose bumps just trying to figure out what is what and who is
who.
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.
agreed...
sadly, the best option in Mono's case is "Windows Forms", if anything
because it directs to GDI on Windows and GTK on Mono.
Windows forms immediately triggers the visual basic syndrome in me.
:--}
But what I do have to agree that it is pretty easy to graphically
design some of your GUI stuff with it. But that is about all the
good news about it.
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.
one can get "halfway there" via clean coding practices.
Well, may be. But when you start from scratch, the curve is too steep
in terms of time and effort for you to get something realistic done.
It is much easier to rely on things like swing or even awt.
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.
but, it is not good to waste them either...
many of us do write code where performance matters, and where seemingly very
little issues in the right spots can eat lots of clock cycles or memory...
Yep. No questions about it.
But at least if there was some lanugage facilities you could rely upon,
the stuff under the hood could be optimized as it forever happens.
I am not sure how much of a performace factor the GUI code would
be dependent on. Some key listeners, some event listeners, the async
processing and things like that.
I have pretty large dialogs I would say, probably with at least 50 components,
and in some cases 3 times as much. Never ever felt any kind of performance
issues with it. Sure, if you do real time graphics or 3D app, that could
be a totally different story. But I have no clue in those areas.
As long as it is not a real time stuff, I doubt GUI is subject to
performance issues.
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 disagree in the strict sense.
if the code can be rebuilt easily enough for the various target OS's, this
is often "good enough".
Fine with me. I am willing to take a source level portability.
For as long as I don't have to give an arm and a leg to sharks like
Microsoft or Google.
virtualization can help, but usually it is far from free either.
for example, neither JVM nor .NET will allow one to use the same code for
both a hosted and native build, and IMO this aspect is important as well...
Well, I am not even dreaming of that level of portability.
At the moment, we are just totally empty handed.
And if it takes several years for those "committies" to come up to some
kind of agreement, I'd rather take at least some of it, if it can be done
"real soon now". As long as they are not going to change it every day.
granted, if I compile a bunch of Java to a native EXE or DLL, it can't
really be expected to run on, say, Linux, but this much is not the issue.
Yep. Source level compatibility AND the ability to compile it to
a natural way things are executed on a given platform, is fine with me.
Actually, that was my argument with Java guys a while back.
I said: when I run a windows app, I expect it to be an .exe file
that I can simply click upon to run the app. Because THAT is the way
every runs under windows. Everybody knows it, and everybody is used
to it.
I do not even want to know that there are some funky portable .class
files underneeth, and those are the actual things that run.
And this is a fundamental conflict with the very concept of ?VM.
Because if you simply want to have an exe, then, by definition,
you need to compiler your ?VM either into a single executable,
or executable that simply loads some dll.
And that kinda breaks the whole idea behind the JVM at least
since class files are your final "executables".
JVM executes a pseudo code, not a native mode code.
it
would be better if one could compile it in both cases, rather than creating
yet another barrier:
Totally agreed. I want to see it compile into a single native mode
app that may or may not use the dlls under windows.
But then I am not sure how would you go about with the very
concept of ?VM.
Java code is, always, run in the VM;
native code is C and JNI.
there are at least several JVM's which ended up allowing running the C code
in a VM as well (just x86 based rather than JBC), but still using JNI to
interface them.
I am sure there are ways to solve these kinds of issues.
Exept everybody is busy erecting the castles on a see shore
from what I see.
Again, I am very displeased with the direction of language
development in general, no matter where you look.
I think is is a totally dead end approach.
They are not even looking at the most critical issues to a developer,
and "could care less" about what is happening in the world in terms
of it being more and more dependent on the information processing
aspect, such as web.
I doubt what people need is some "revolutionary" syntax.
Have not seen ANYTHING that excites me in F#, even though it looks
nice on paper. I have not seen things like GUI, threads or GC
even mentioned.
Why do you think PHP, Python, Ruby, Javascript, SQL and even HTTP
are so appealing.
Vast majority of web based apps are developed with PHP from what
I see. Most of CMS systems, bulletin boards and you name it use PHP,
even though Python and Ruby have much higher performance.
Just look at the very central idea of PHP that you can mix
your html code with php, however crazy it may sound, and it does
sound crazy to me. But it gives people so much power and flexibility,
that any kid cad deveop something working within days, even though
they might have never heard such things as synchronicity,
threading, acync processing events and things like that.
And THAT is what is happening in the world, and I bet you,
it is going to be happening more and more.
People do not even know about the portability issues.
Because they simply do not exist.
They could care less if you run JVM or anything for that matter.
They don't care how "pure" is your syntax and notation
from the standpoint of some "head".
They do not know what means static binding or dynamic binding
necessarily.
And yet, there is a tremendous amount of work being done
and it does what they want.
Why not look at it as an opportunity?
Especially if you have the underlying principles that allow
you to run orders of magnitude more efficiently?
Why not look at THESE things instead of sitting in an ivory tower
and keep inventing some new mental perversion that will make
people shiver when they look at it?
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
hacks of Javascript level where functions may include other functions
as parameters. It is a mix of Lisp and Javascript. Essentially
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,
Lisp, etc.
But the very concept is flawed. The code becomes utterly unintuitive.
You can not even comprehend what comes out of it at the end.
I talked to Javascript guys and they said once you hit a certain
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
months on it. I'd say I agree after looking at Javascript.
yeah.
dynamic languages tend to have a certain limit to their scalability.
For one thing. Except you need at specific app.
If it is a server end, yes, there is a need for scalability
and performance, and I think Java solved it quite nicely.
Not saying it is the "ultimate" solution. Because none exists in
principle.
some of their abilities are really nice and powerful at the small scale, but
the bigger a project gets, the harder it gets to manage.
many static languages tend to scale much better.
Sure they do. That is the whole point of them.
And that is why I'd like to see a STATICALLY scoped (typed :--})
languages to at least consider the modern world.
Because they don't even bother about anything else, but their own
lil sandbox in the scheme of things.
my intuition here is that probably C likely scales fairly well (if practices
are good), with C++ and Java likely comming close (again depending on
practices, Java will likely allow scaling easier at the "medium" scale).
Except it is used on the largest scale in banking, finance,
wall street, governments, etc.
JavaScript is not likely to scale well.
Well, it does not need to. It is a client end gizmo.
guestimate:
C (with poor practices), likely to turn into an ugly mess at around 30-50
kloc;
C++ (with similarly poor practices), maybe around 50-75 kloc;
Java (with 'generic' practices), likely at around 200-400 kloc.
in C and C++, the user is likely to end up stumbling around with globals and
memory objects...
in C++, the limit is likely to be a slight bit higher, due mostly to the
programmer trying to naively use namespaces, classes, and RAII as "magic
pendants".
I like this one:
"only real danger is that we simply forget to release the resource,
which, while it does happen, is something that should be quickly caught
in any code-review."
What a joke!
this would work for a little while, but ultimately these can't
save poor practices (for example, a global in a namespace is still a global,
....).
by adapting many coding policies, the situation is reversed, very possibly:
C (good practices), ~ 1 Mloc;
C++, ~800 kloc;
Java, ~ 500-600 kloc (?...).
reasoning:
in C, one is likely to have learned early on that fairly rigid coding
practices are needed to help code scale, and if followed make the natural
large-scale structure somewhat different from its smaller-scale form.
C++ is similar, but I suspect it is likely that there will be some
"aliasing" related to misusing some OO features in ways which create
"tangles" (very likely, the same features which tend to help at the smaller
scale).
actually, from my experience, a sufficiently large C or C++ project is
likely to start notably resembling an existing OS, such as Linux or Windows
(or at least, this was my experience...).
Java is not likely to help, since the language itself has a fairly
restrictive design, and it would be awkward to use a large-scale
architecture in conflict with the languages' built-in architecture. I could
be wrong though, not having had much significant experience in the language.
JavaScript is not likely to scale well much above maybe 10-25 kloc, and
attempting to adapt modular practices would make the language likely
somewhat unappealing.
the advantage if offers then is that, given it is likely to be used for
scripting rather than for infrastructure, code is likely to be small and
divided up into disjoint islands, which would help keep issues more-or-less
contained (the number of such islands should not be a significant factor
beyond the level of code one has to deal with).
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
level languages.
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.
ok.
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.
newer Java does support generics, FWIW.
I know. Except VS 2005 is the last version of IDE that supports
Java syntax. Beyond that, there is no concept of anything even
remotely related to Java. Thanx to these Sun vs. Microsoft wars.
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
similar.
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 realize
I was screwed again by some fools, selling me pussy in the sky with
diamonds.
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.
well, for the most part, it is not particularly "compelling".
So what?
You did spend some time thinking about these things.
Don't you think that the results of it is worth some value to others?
And even if you are "wrong" and they jump on you in bulk,
what is "wrong" with that? Who knows, may be some new insights
may come up out of it, for you and for them?
I do not think it is such a good idea to simply let your work
go to waste because you are aftaid of being condemend.
Screw that stuff. One of the most pitiful things.
I think if you have done some work, it is imperative you talk about it.
It may generate new ideas for others and for you, just be the shear
fact that you EXPRESS it. Take it from subconscious level to conscious.
Do not underestimate the significance of it.
it has nearly all of the parts of a traditional compiler:
preprocessor, frontend, IL, codegen, assembler, linker.
the input language is C, the IL is a little funky (and obscure Forth or
PostScript like language, sent between stages in a textual form), the ASM is
essentially a variant of NASM / YASM style syntax;
the assembler produces COFF, and the linker accepts COFF.
it "may" use a custom name-mangling scheme, which is largely a hybrid of
JVM/JNI naming, and IA-64. basically, it combines a lot of the notation from
IA-64 with the general syntax of JVM signatures, and then converts it to a
linker symbol with a convention based on that used in JNI (although, it has
special-cases for several additional characters, as well as a shorter escape
for chars in the 1-255 range).
this particular type-signature scheme is used by many internal components.
Look, I can host your project and ANY documentation you have.
We'll make a separate "site" for it that contains the interesting
projects in the area of language or system development.
You'll have your own top level link that will be shown in the
top level index.
That is what I can do.
This should not go to waste in my opinion.
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.
Like what?
both the JVM and .NET want to remake the world in their own image,
YES.
and set up "the one true VM to rule them all".
Well, except in case of microsoft, you'd have to say
"to rule them all as long as you are dealing with OUR stuff".
That makes a difference.
I disagree with this strategy.
a VM is, IMO, "a framework" not "the framework".
hence, in this sense, I am a little more closely aligned with Python or Lua.
(although, I personally don't have so many happy feelings towards Python
either).
The only thing that prevented me from geting into Python,
even when I needed to, was abscence of braces.
The very idea of using white space as indentation level is bizzare.
Just this single thing was enough to stop even bothering with it,
and when I read his arguments on WHY did he do it, it was just
a bad joke to me. To try to fit as much code on your scren as you
want by simply removing the most stable code block delimiters,
is simply insance.
On the top of it, when I read some of original documentation,
it seems like the guy has difficulties with comprehension skills,
jumping right into middle of such nasty things like regular
expressions and not being able to explain every step of the way.
Some syntax issues with regex are totally unintuitive.
Some other stuff like installation subsystem borthers on insanity
to me. When I looked at documentation, it was just like reading
a bible sized book with ALL sorts of blabber, just to copy some
stinky files around and set up some relatively simple things.
As a result, full stop on Python. Regardless how many people
say it the the solution to mankind's problems. Python is hack.
I like "real" languages developed by people, who has seen it
all in and out, and not by some smart "wizards".
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 of people complain about very primitive,
low level support for 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.
yep.
well, there are merits to VMs, and there are costs...
I'll take the merits and accept the costs.
What other options do I have?
I don't personally believe in aboloshing the JVM, only that I think the way
the overall architecture, and the way Sun is managing some things, are not
quite so ideal.
May be. But I'd be REALLY careful making these kinds of statements.
But if you have a better idea, why not?
granted, not everyone has the same needs or ideals, and what the JVM
addresses are a slightly different set of ideals than those I am trying to
address.
And those are?
granted, Apache Harmony and GCJ are both pseudo-JVM's, both of which adapt
both Java and much of the JVM architecture, but each varies in some notable
and fundamental ways:
Harmony seems better adapted as a script VM (for example, for the Apache
web-server);
GCJ can compile Java code to native machine code and link fairly directly
with C++.
Oh, now I remember about that GCJ thing. I think I looked at it
a while back, just in passing. At that time, I did not believe
they are really selling something real and I did not have any first
hand experience with it. So I had to abandon it.
Is it something worth looking at in your opinion?
what the JVM offers is OS abstraction via a virtualized architecture.
granted.
some people don't need this though, and instead want a good scripting VM
under the control of a host app, which is a role thus far best filled by
Python and Lua.
Well, then have two VMs. I could care less for as long as I know
when I do this and that, I have to type a different command line,
or something like that.
You keep mentioning Lua. Have no clue about that one.
another need is for good performance and powerful app extensions, which is
better filled by C (high level script languages are good for scripting an
app, but not so good for extending it).
I have some hope of being able to have JVM features available as well, but
my motivation has been lacking (the JVM facilities I have in place are not,
what I would call, "usably complete").
many notable VM features (such as exceptions) don't work, and I don't have a
class library (there was some attempt to port over GNU classpath, but this
petered out some and I have my doubts about using such a massive GPL'ed
component).
:--}
Yep, massive seems to the point.
Well, not sure what you have been cooking there and why did you
have to design your whole world to do things, but I guess you had
your own reasons to do it this way.
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
other.
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.
well, I am one of the rare VM developers who is probably not promoting yet
another new bytecode or programming language...
Well, I am not exactly an expert in this area.
Never quite grasped the idea behind the bytecode.
If someone tells it to me in few words, find, I'll look at it.
What is the primary motivation behind the bytecode?
for some things, I am using JBC, and for other things I have adopted 32-bit
x86 as a "bytecode" (good and bad points exist here...).
You seem to be gettin to deep into those nasty details.
Like designing your own world from the O/S level and up.
I wonder WHY do you need to poke THAT deep into this stuff.
Is there are philosphical reason behind it?
currently C and Java are the main "script" languages in use,
SCRIPT language?
:--}
I like that one!
however, I
can't currently compile Java on my own (I have ended up having to resort to
GCJ to do the first-half of this process).
I did try to plug Java support into my C frontend, but this turns into a big
mess, as my compiler backend can't really deal with Java's constructs
(trying to shove C and Java through the same compiler backend is not nearly
so easy as it would seem).
Oh, maaan! You must have some royal amount of free time
to dig THAT deep into it.
I may instead switch to an alternative strategy, and maybe get around to
writing a Java compiler which produces JBC / "class" files,
Jeez!
:--}
I feel sorry for you. What a task!
and then make
use of my JBC interpreter, or a translator, for plugging this into the rest
of the VM.
Are you trying to reinvent the software busines?
:--}
Your own VM, your own language, your own interpreter, your own translator.
Maaaan!
my JBC -> C translator had been mostly so that I could compile Java into
native DLL's via MSVC (mostly to avoid having to send it all through the
classloader, getting better performance, ...).
EXACTLY what I'd like to see.
however, issues popped up which stalled this effort.
the result is that Java has not made "significant" inroads into my codebase,
and so C remains as the primary VM language (as well as the implementation
language).
I am still left with doubts though, and if it goes anywhere may end up
either using Apache's class library (instead of GNU ClassPath), or maybe
writing my own mini class library ("java.lang" and maybe a few other areas,
but leaving out most of the rest).
Well, I definetely think you should organize your material
and make a good site to publish your findings.
You never know, you might find some other people, crazy enough
to join your club.
similarly, finding a "better" option than JNI could help (VM-based scripts
using JNI just seems horribly tacky...).
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
than most of bells and whistles I see.
yep.
this is all more a matter of coding practices and architecture though,
rather than any particular features.
often, native OS-level API's do this far better than nearly any VM I am
aware of.
Fine. So make a thin interface layer above it.
But make it platform independent.
What I, personally, want is a SINGLE way of writing something.
I want platform independence in STATICALLY scoped (typed :--})
languages. No matter what anybody says, I am still very hesitant
to jump into these dynamic languages. I did look at some of it,
but my heart is somehow not at rest with it. It says: nope,
it is a trap. Don't go there.
Most dynamic languages are way too limited.
I like to see ALL the bells and whistles of static approach,
such as threading, async handling, event structure, performance,
predictability of outcome, and things like that.
this is mostly since most VM's try to package everything into "one
size fits all" objects, and may end up with a big pile of different classes
for every possible use case.
Yep. I do not like that aspect of it.
If you could construct that VM on the fly, depending on what exactly
my app requires, that would probably make the whole thing leaner.
Not sure how realistic the whole excersize is though.
granted, generic facilities are often not as "nice" as in the "one size fits
all" strategy (often, the more control that is given, the more internal
patchwork that is visible), and having to bring up subsystems by getting and
setting lots of pointers isn't very nice, but it does have some merits.
I could care less about what kind of magic you need to do
while that thing is constructed at run time.
As long as it buys me something at the end.
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.
well, it is an ideal at least.
the tangled bits and need to mess around with crap sometimes clouds the
vision.
Just don't spread yourself too thin.
I am not sure you have resources to handle so many different aspects.
I guess it can be compared to trying to write an app making use of DirectX.
luckily, much of this internal plumbing work is hidden in the details, but
at the cost that this (doing initialization automatically), itself, creates
more internal dependencies and issues.
Well, what do you expect if you are trying to reinvent the world?
:--}
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
mankind.
ok.
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.
LLVM is another VM, but which mostly sets itself up as a generic compiler
lower-end.
my main complaint is that the design is very centralized, and also that the
whole thing is written in C++ and in a style I am not particularly fond of.
may seem odd, but I believe the lower-end compiler machinery should be,
hopefully, decentralized and C-friendly (C++ can be used, but one should not
expect any code which externally interfaces with it to do so by instancing
or extending classes, ...).
I am also not as fond of the single-class-per-file or manually including
"teh crapload" of class-specific headers, mostly because it means having to
open and dig through far too many files to really follow the code.
Well, Microsoft did not have that limitation, and I totally agree
with that one. But it seems to be some kind of necessity overall.
But what a royal pain it is. My main class source file is > 250k.
Not that it is such a big deal with modern IDEs. But still, I'd
prefer to see it split into smaller, logically related sections.
....
however, I have tried to minimize creating "novel" parts when possible.
sadly, some level of "novelty" and "internal dependencies" are inevitable
it
seems...
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
JavaScript and Scheme also have some interest).
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.
there is ECMA-334 and 335, which essentially mean that, as far as these
parts go, there is some level of openness. one can then implement which
parts are defined in these standards, and ignore most of the rest, and
technically MS is under their own legal obligations not to do anything about
it.
I just do not trust those guys ANY way you cut it.
From what I've seen so far, these are just different kinds of traps,
but you do eventually get trapped in that gook. And it is amazing,
they did not realize how much they are hated by just about anyone
for setting up all these traps and being totally closed, ignoring
the rest of the world, like they are the only ones that have a final
say on what is what.
granted, you wont get the whole ".NET framework" this way, but one can get
C# and MSIL, which have a few merits.
Well, I do not mind C# as such. I am looking at some things in passing,
and yes, it does make SOME sense. I just fail to see what it boils down
to at the end and what specifically does it buy me.
I think people are too obscessed with compile time issues.
For example, in Java generics, there is this type erasure thing,
which means you loose your type during the run time.
Well, I do not like the mechanisms like these in principle.
the problem, however, is that both are fairly complicated in their full form
(much more so than the JVM equivalents), and so would take a far higher
resource involvement to really implement effectively.
I just do not see what does it buy me at the end.
If your program is "incorrect", you can not be saved by compilers.
Those are just small things that won't make your program "better".
Because you prolly have holes in your architecture and design.
People still write plenty of code in straigt C.
For some strange reason, it is all over the place.
And the more stable, more performing code, the more you get to the
kernel level, the closer you tend to move toward C.
however, it is all a bit of a "trudging through mud" experience,
And forever so.
and C
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.
yep.
(my C
compiler contains a few holes and failings, but for the most part it is
adequate).
You mean you have your own C compiler? :--}
That made my day!
yep.
Wow!
I am impressed.
it is mostly used for scripting.
for most other things though, I am using good old static C compilers (GCC
and MSVC), which do most of the "heavy lifting" as it were.
my compiler is binary compatible with the static compilers (so I don't need
a FFI for C-based scripts).
but, ideally, an app will "use" a framework, rather than be "built on top
of" it,
What do you mean by that?
an app which uses something may continue to function without the object in
question, or may supply a substitute.
Cool. You are pretty inventive I'd say.
:--}
an app which is "built on top of" something, can't be reasonably expected to
function without it.
for example, an app may use a GUI toolkit, or several of them, and then some
way exists in which to "choose" which one to use (via build options, or even
at runtime), or the app could provide a fallback (no GUI is available, so it
falls back to a custom and more-simplistic interface, such as a
command-line, or simple custom-drawn widgets).
You are really something else, I tellya.
:--}
an app "built on top of" a GUI toolkit can't easily do this, and would
essentially need to be "ported" to the new toolkit, that or discarded and
rewritten.
Yep, I do like an idea of dynamic wiring.
many toolkits and frameworks though are written to assume such a level of
dependency, and are problematic to try to use in such a way which does not
in some way significantly impact the app with which they are used, and often
will not play well with another toolkit which does essentially the same
thing, since inevitably they will conflict over some or another "prized"
resource and would step on each other if one tried to use both.
and it "should" be a component which can be integrated into a
project (or dropped again) without otherwise requiring significant
modification.
this is the ideal, although granted, it is much work to achieve these
sorts
of ideals.
granted, nothing is perfect.
in general, I like C# though, as for the most part it seems a fairly
cleanly
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,
and
would rather it was something capable of being statically compiled and
operated standalone.
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
complexities...).
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.
Not them.
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.
historically, probably...
initially, MS implemented J# and their own customized (and MSified) JVM.
Sun did not take too keenly to their effort, and so there was a lawsuit.
shortly thereafter, MS made a new language: C#, which kept much in common
with Java (but added many syntax changes and new features).
That is what I meant.
I just saw too many Javaish things in C#, the whole MVM concept,
and I bet the whole .net trip is the same thing.
That is why I called them what I did.
And I would not doubt in my mind that they intend to screw Sun
at the end so they could suck in as many people into the webs
they weave and Sun, for obvious reasons, barked at that.
Not sure what I'd do in their place.
But to take upon the microsoft, even if you get paid tons of bux
at the end, was the end of Java, at least to vast majority of
boxes out there. I think ms dropping java is probably the most
monumental move in the entire history of sw industry.
they also created MSIL / CIL, which shares many commonalities with JBC, but
also differs in many ways as well.
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"
(of suckology).
yeah, a lot is just hacks and extensions of prior technologies.
MZ/EXE (from MS-DOS) and COFF (from Unix) were hacked together to produce
PE/COFF (used in 32-bit EXE's from Win95 and NT4 onwards).
Its a pitty that people who initially concieved and designed these
things did not even get a penny out of it.
It was all repackaged and stamped with "copyright" or "patent" stamp.
Simply disgusting.
I did have some direct experience with MS a while back.
What they asked me essentially is this: you give us your product
for FREE and we will include it in OUR package, the O/S.
And we won't pay you a penny in return.
But you do get to be "approved" by us and we will get more money
as a result of including more and more blood from the people and
companies like you.
I said: screw you and screw your whole trip. No deal.
Those suckers did not even offer a PENNY.
What a disgusting bunch of sickos, sucking blood from everyone
they can get their hands upon.
then a bunch more crap was hacked on to create MSIL Images, which are
basically PE/COFF with a bunch of relational tables and stuff added, and
MSIL bytecode thrown in.
I also ended up using PE/COFF, mostly for compatibility reasons, but most of
my metadata notably differs (my metadata is not based on a relational
structure, but is instead a heirarchical DB, mixed with some other parts
which are based on a TLV structure loosely similar to RIFF or PNG, although
by default a bit more compact...).
About the pittiest thing in this whole thing is that people
like Gary Kildall simply get slaughtered at the end, while these
parasites make a killing on the work of others.
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
been doing.
ok.
(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
achievable goal).
Well, good.
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
a language.
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
approach.
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.
as-is, I don't even really have "java.lang" in place, and so most of what
goes on would require plugging into C land
Coolio! :--}
(and at the moment, likely
writing far more JNI code than actual Java).
similarly, it looks like a hassle to plug classpath into my project, as I
would have to write a lot of machinery to glue it.
possibly, I could try to go and write some wrappers for some of my C based
APIs, and then build some of the core Java API's on top of these.
so far, I have not done much of the sort.
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.
yeah.
little in the language particularly prohibits this, only that I am not
aware
of any standalone C# implementation.
it is, at the moment, a little easier to write standalone Java, since
there
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.
yeah, probably a real horror that.
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...
it is fairly generic compiler stuff here.
a JIT is likely to be faced with many of the same issues.
just, translating stack operations into variable operations is a little
cheaper than faking the stack, and with JBC's restrictions, does not add
notably to the complexity.
a few of the ugly edge cases are mostly that there are a few opcodes which
assume a stack composed of 32-bit items and make some assumptions WRT item
size, which, errm, kind of turn ugly when dealing with an abstract stack.
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
described.
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.
ok.
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 does not map from MFC to Java that well.
Basically, 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.
I know. I am still struggling with some totally ridiculous stuff,
just trying to resize some nested GUI stuff. The stupidest thing
in the world and the amount of time I had to waste on it is just
monumental compared to the functionality I was after. That same
thing is a sneeze doing it in java and using nothing more than
gridbag layouts.
never really used MFC, though had used GDI+ some in the past.
mostly I use OpenGL and do my own widget drawing via GL, although there are
drawbacks.
Well, I used it from the day one. Basically, it is just an object
oriented C++ wrapper for win32. So, I started using it as my main thing.
Never regretted it, except when you have some nasty details
and primarily in the GUI end of it, if you are writing some
flexible GUI code.
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.
I mean the firewall app.
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.
ok.
....
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.
Java ByteCode.
Oh, Jeez!
:--}
Thats about the last thing I would even think about it.
I thought it is some kind of gadget.
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
"impedence" problems.
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.
ok.
can't much help here...
compiling code is a much simpler task than converting between API's...
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
managable).
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
C code.
none of this holds with either C, C++, or x86 machine code, OTOH, and
hence
such a conversion is not directly possible as such.
or such...
Hey. Good article. I really enjoyed it.
ok.
What can I say, it is a pitty, society does not support the guys
like you and give them some basic funding just to be able to exist.
Because I think people like you can contribute more to the whole
equation, that most of the big mouths out there, called "experts".
Good luck.
--
Programmer's Goldmine collections:
http://preciseinfo.org
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.