C++ jobs down another 40%
Jon Harrop
The number of job adverts in the UK citing C++ has fallen 40% for the second
year in a row:
http://flyingfrogblog.blogspot.com/2009/12/c-is-dying.html
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
red floyd
> 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?
Branimir Maksimovic
> The number of job adverts in the UK citing C++ has fallen 40% for the second
> year in a row:
>
> http://flyingfrogblog.blogspot.com/2009/12/c-is-dying.html
>
Greets
Christof Warlich
> �I wish the C++ people would wake up and realize that C++
> is drowning in its own complexity.�
I was rather frustrated when I realized that C++0x will neither be
finalized in this decade and, even worse, will not include Concepts.
Many programmers just deny using even well designed templates like BOOST
just due to the unfortunate error messages being printed when passing in
an incompatible type.
What's really needed is a real leap in C++ usability, offering its full
feature set to the experts while giving decent directions to the average
library user. Concepts would have been the first step, a new standard
library making use of Concepts the second. The final vision must be to
make C++ as save and easy to use as Python for every-day tasks while
still offering its full power to the dauntless expert.
tanix
Kinda.
Those "purists" tend to think that by inventing more and more of kinky
things, they somehow, magically, make the language more powerful and
more flexible.
One of the MOST important parameters of language for me
is to be able to read it as a read a news article, often skipping
the whole paragraps.
With all these great "improvements", I have to read it as a Bible
and think about every funky delimiter as if were a word of God.
TOTAL waste of my time.
I do not accept most of these notation perversions.
Instead of concentrating on those things that do seem the most
significant in the modern world, the concentrate on some kinky
things that will require 10 times more brain processing power
and heat generation from your scull, than it necessary to do
the same exact thing with the same exact results overall.
--
Programmer's Goldmine collections:
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.
Balog Pal
"Stefan Ram" <r...@zedat.fu-berlin.de>
> - One can not really isolate a subset from the
> rest of the language, at many places the rest
> of the language leaks in.
>
> For example, one might try to use/teach �int� only
> (not �unsinged�, �short�, or �long�), but then,
> how does one explain the value and/or behavior of
> an evaluation of �-1 < 3000000000�?
What you explain in this behavior?
Btw never heard of the idea to use int *only*. There is a guideline to use
int as default, and anything else only for a good reason.
short can be dropped if you don't have situation where it is sufficient in a
structure you use by millions. long can be dropped unless there is an extra
range over int that the application needs. unsigned is no luck due to
size_t.
> - This idea is also based on the assumption that
> C++ programs are written. They are not. At least
> most of the time. Source code is more often /read/
> then written (in order to maintain/modify/reuse
> code - programs are modified more often than written
> from scratch). So, when I have learned only a subset
> of a language, it might not allow me to read many
> programs.
That is the nature of a subset. Guess whoever thinks of subset introduction
is aware of his existing code bases... You can also introduce distinct
rules for different code locations or people.
>
Balog Pal
> "Balog Pal" <pa...@lib.hu> writes:
>>>For example, one might try to use/teach �int� only
>>>(not �unsinged�, �short�, or �long�), but then,
>>>how does one explain the value and/or behavior of
>>>an evaluation of �-1 < 3000000000�?
>>What you explain in this behavior?
>
> Maybe someone could rephrase it?
Ok, let's start in little. Please explain the behavior if you don't have any
artificial restrictions, and mark the place where the explanation would be a
problem with restrictions.
Jon Harrop
Extrapolating the current trends, there will be more F# jobs than C++ jobs
in 2012:
http://fsharpnews.blogspot.com/2009/12/trending-f-jobs-in-uk.html
tanix
>
> �an interesting difference between "Effective Java" and
> "Effective C++" is that my reaction to the latter was to
> come up with a set of SOPs that mainly boil down to
> "don't use C++ feature x".�
> �����������������������
> Bjorn Borud
If I recall correctly, "Effective Java" is a MUNUMENTAL work.
><m3is1ti...@borud.not>
>
> However, the idea of defining a subset of C++ has at least
> two problems:
>
> - One can not really isolate a subset from the
> rest of the language, at many places the rest
> of the language leaks in.
>
> For example, one might try to use/teach �int� only
> (not �unsinged�, �short�, or �long�), but then,
> how does one explain the value and/or behavior of
> an evaluation of �-1 < 3000000000�?
>
> - This idea is also based on the assumption that
> C++ programs are written. They are not. At least
> most of the time. Source code is more often /read/
> then written (in order to maintain/modify/reuse
> code - programs are modified more often than written
> from scratch).
Yep. And that is exactly what most people forget, or do not
even realize, thinking that by writing as "advanced" code,
as they can come up with, is that this is all about.
Because READING that "sophisticated" code will take 10 times
longer, if you EVER will be able to see all the subtleties
of it.
> So, when I have learned only a subset
> of a language, it might not allow me to read many
> programs.
--
Balog Pal
>>>>>an evaluation of �-1 < 3000000000�?
> behavior is undefined (for example, I know one implementation
> yielding the value 0), otherwise, the value is 1.
Exactly, the so if 3G can be represented the expression is always true,
otherwise UB. This is the case regardless your guidelines would say not to
use short, long, unsigned.
So your original problem around the "how you explain" is still as moot as
originally, care to elaborate?
Marcelo De Brito
Guys, I think you should immediately read this:
http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html
Best regards!
Marcelo
Balog Pal
>>So your original problem around the "how you explain" is still as moot as
>>originally, care to elaborate?
>
> the set of integer types to �int�.
Indeed, the language was not built to be tuned that way ;-))). Guess we
could build a similar statement, how hard it is to restrict to not using the
String type.
> A student might observe,
> for example, that under his C++ implementation,
> �-1 < 3000000000� yields 0 and ask for an explanation.
And you explain him that his implementation is poor QoI-wise, as I see no
excuse to not issue a diagnostic for the case. You can explain that C++ as
C has a plenty of areas with Undefined behavior and using numbers beyond the
legal range is one of them.
> To correctly explain this, one might need to mention �long�
You may or may not mention long. Note that the expression was either an
error itself (too many zeroes) then has little to do with long just must be
corrected. Or you want to use 3G, and then your idea with ints is just bad.
> and possibly also �unsigned long� (in the case of this C++
> implementation).
LOL. Yes, the norm is that C++ has a number of integral types with
different range, and programmers use them to handle information in the
fitting range.
*If* your program does not ever need to leave the range 'int' has, you can
arrange for your arbitrary restriction.
Honestly I can hardly imagine a good field for that -- if you go without an
OS, you likely need low level things and use all the types; and if you have
API for an OS, then you must play along.
Balog Pal
>
> http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
James Kanze
There is one, albeit not as big as that for C++.
In practice, if you look at long term trends (and not short
swings), C++ is pretty safe for the future. With regards to F#,
it's too early to tell---the language hasn't been around long
enough to establish any long term trends,
--
James Kanze
Jon Harrop
> 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?
>
> There is one, albeit not as big as that for C++.
>
> In practice, if you look at long term trends (and not short
> swings), C++ is pretty safe for the future.
Are you saying that four years of rapid decline is a "short term swing" and
not a "long term trend"?
Brian
> The number of job adverts in the UK citing C++ has fallen 40% for the second
> year in a row:
>
I think C++ programmers are becoming more productive with the
abundance of tools and libraries at their fingertips. It's
possible today for one C++ programmer to accomplish what used
to take two C++ programmers.
Shalom
Brian Wood
http://webEbenezer.net
tanix
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. Meaning, it will be totally controlled
and dominated by Microsoft with all associated consequences,
such as everything under the Sun will be patented and copirighted.
It is going to cost you an arm and a leg if you ever touch anything
related to it.
It will NEVER be accepted by the world at large because of those
very arm twisting patents and heavy duty blood flows into the
black hole of "the head", if any of you know what it means.
Unless some new language is accepted by everybody and it is
portable and does not tie in to some mega-sucking corporation,
it is a no go for me no matter how you cut it.
Microsoft simply killed Sun when those guys sued them.
Then, being the rotten thieves they are, ms took the central
ideas of Java and all the associated development work, then
repackaged it and placed a sticker "Microsoft copyrighted
and patented" on it.
They were thiefs from the day one, raping and pillaging,
and they remain theiefs to this day and for any forceable future.
They were born on intellectual theft by taking the work of
Gary Kildall, the author of CP/M, buy purchasing some rip off artists,
who reverse egineered the CP/M operating system, and that was their
first contract with IBM, as a result of which these "lewser" fools,
who could only create a sickness called M-Basic and nothing more
than that, became what they are today.
This monster was born on Gary's blood.
I bet they did not even say thank you to him and he did not get
a penny in return, even though he, single handedly, was the
creator of the destop computer as far as its very heart, an O/S
goes.
To this day, everybody is using BIOS, which was Garys brilliant
insight.
The demise of Java is probably the biggest tragedy in the sw world.
By FAR, thanks to these servants of evil.
As soon as I see Microsoft lable on anything, it means death to me.
Microsoft is the very symbol of death and destrution,
and that "the head" thing is what its real meaning,
and that is evil raging as hell. Utterly unhumane. Utterly destructive.
Utterly dishonest and totally parasitic to the very body of mankind
as such.
In my opinion, unless there is a language that is accepted outside
of this blood thirsty "business" super-sucking model, there is no
hope for any genuine progress.
Simple as that.
tanix
>James Kanze 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?
>>
>> There is one, albeit not as big as that for C++.
>>
>> In practice, if you look at long term trends (and not short
>> swings), C++ is pretty safe for the future.
>
>Are you saying that four years of rapid decline is a "short term swing" and
>not a "long term trend"?
Well, you have to put things in perspective.
Just taking C++ as some isolated case is not correct.
The same thing is happening to Java, at least from the traffic
I am seeing and that traffic is generated by mostly professional
programmers from every single leading sw house or every single
biggest and baddest enterprise for that matter.
From what I see, the decay in non dynamically scoped languages
largely comes from the fact that other languages can fulfill
the requirements in more and more situations.
More and more of sw engineering is web related nowadays,
or information related. Just the fact that Google got so arrogant
as to challenge the Microsoft in their stronghold, the O/S
business by trying to obliterate the very concept of O/S as
something being inherently necessary in your box, says more
about it than anything else.
To challange WHO? Nothing less than Microsoft?
And in their MAIN game? What does it tell you?
Chris M. Thomasson
news:hh31vk$82i$1...@news.eternal-september.org...
> In article
> <66e7b0f7-4c71-4db4...@a32g2000yqm.googlegroups.com>, James
> Kanze <james...@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:
tanix
Well, that's something that looks promising,
and the pricing structure what I need is quite reasonable.
I just hate to see things like .net, or asp.net cause that immediately
triggers the Microsoft syndrome in me and all red lights start flashing.
I try to stay away from that stuff like a plague cause I know trouble
is just around the corner, at least from my experience so far.
That is why I feel MUCH more comfortable with Java overall.
Much safer environment any way you look at it.
I'd be willing to pay those guys money if they asked.
It is unfortunate Sun did not come up with some realistic and
reasonable prices structure that I would not have to givem and arm
and a leg, but, at the same time, they could recover some of their
expenses. That would make me feel much happier than to simply get Java
for free, knowing nothing in this world is free.
It is too unfortunate they ended up being bought out by Oracle.
Cause that is probably the end of Java. Oracle is not to far from
all those other big sharks. Pretty much the same camp.
Anyway, can you do GUI with this thing? All I saw so far is GTK
mentioned.
Is there a threads support?
How good is their IDE? Code completion is one of major things for me.
And how good is debugger?
Thanx for a pointer though.
BGB / cr88192
> In article <ItSdnThEINvlcqnW...@brightview.co.uk>, Jon Harrop
> <j...@ffconsultancy.com> wrote:
>>James Kanze 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?
>>>
>>> There is one, albeit not as big as that for C++.
>>>
>>> In practice, if you look at long term trends (and not short
>>> swings), C++ is pretty safe for the future.
>>
>>Are you saying that four years of rapid decline is a "short term swing"
>>and
>>not a "long term trend"?
>
> Well, you have to put things in perspective.
> Just taking C++ as some isolated case is not correct.
> The same thing is happening to Java, at least from the traffic
> I am seeing and that traffic is generated by mostly professional
> programmers from every single leading sw house or every single
> biggest and baddest enterprise for that matter.
>
> From what I see, the decay in non dynamically scoped languages
> largely comes from the fact that other languages can fulfill
> the requirements in more and more situations.
>
"dynamically typed" is the correct term here. "dynamically scoped" means
something different which, no, most of these languages don't do (lexical
scope being far more common).
> More and more of sw engineering is web related nowadays,
> or information related. Just the fact that Google got so arrogant
> as to challenge the Microsoft in their stronghold, the O/S
> business by trying to obliterate the very concept of O/S as
> something being inherently necessary in your box, says more
> about it than anything else.
>
> To challange WHO? Nothing less than Microsoft?
> And in their MAIN game? What does it tell you?
>
that google is in for a cold shower once people, in general, come to realize
what it is they are looking at...
granted, a lot is done on the internet, but I personally would not give up
on using a real computer with a real OS. even though I have and use a
netbook, what is more notable than this is that I run a full-featured Linux
on the thing (Ubuntu), rather than the shipped gimped distro (Xandros).
in the same way, I would not likely consider something like Chrome unless it
were at least as capable as a full Linux distro (even if I have noted that
the thing is too slow to really build or run any of my major projects on).
BGB / cr88192
"Chris M. Thomasson" <n...@spam.invalid> wrote in message
news:xR9Zm.3013$8e4....@newsfe03.iad...
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).
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.
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 (I have done so in the past in my
case). although, I don't presently like my current "ABI", but attempts to
design a newer/more efficient ABI ran into a few issues.
or such...
tanix
You can not imagine how much would I like to see THAT show. :--}
>granted, a lot is done on the internet, but I personally would not give up
>on using a real computer with a real OS.
I would not even DREAM of such a think even if Google paid me
trice as much as my box is worth and for so many reasons, that I could
write a book about it. EASILY. You know my writing style by now, right?
:--}
> even though I have and use a
>netbook, what is more notable than this is that I run a full-featured Linux
>on the thing (Ubuntu), rather than the shipped gimped distro (Xandros).
Actually, I do like Ubuntu quite a bit.
It was a breath of fresh air for a couple of months
after my win box was rooted and I simply could not use it.
It is almost there. In fat it IS there, and for all I do,
I could easily switch to it without loosing a thing.
Except JVM under Linux runs about 2 times as slow for what I do.
Have no idea why. Sounds a bit weird to me.
Seconly, I can not run my monitoring firewall on it,
which is a total show stopper.
And finally, I do not like the NetBeans and Eclipse that much.
Pretty clumzy stuff, I'd say. Plus horrible code completion
functionality. Too convoluted everything.
The way I have it right now is a breeze for me.
But, as soon as I see a real good IDE, which could already
be there, except I did not see it, and I see my JVM running
as fast, I'd be willing to totally switch even before I
rewrite the firewall driver. The program code should be easy
to port. But the network driver interface could be a major
pain. I do need an equivalent of NDIS intermediate device
driver that sits as the lowest thing on the stack, just
above the netowork card driver.
I am WAY too fed up with this windows trip.
The most unstable thing in the world, even compared with pub domain
Linux.
>in the same way, I would not likely consider something like Chrome unless it
>were at least as capable as a full Linux distro (even if I have noted that
>the thing is too slow to really build or run any of my major projects on).
I am not even reading any of that hype.
First of all, I am not going to switch anything, especially on the O/S
level, until it had at least 2 years to run and most nasty things
are fixed.
Secondly, considering the fact that microsoft is in the game since
yearly eighties and have megatons of stuff developed, just to
go with some arrogant, greedy out of their mind monsters, and quite
literally at that, would be not only suicidal but outright stupid.
And I did have to deal with them on a much closer basis than
most people. Probably the most disgusting feeling I ever had.
"I don't care" lessness is at stratospheric level.
tanix
Uggh. That one is going to wait then.
>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.
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 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?
>(I have done so in the past in my
>case). although, I don't presently like my current "ABI", but attempts to
>design a newer/more efficient ABI ran into a few issues.
>or such...
--
BGB / cr88192
it was metaphorical.
>>granted, a lot is done on the internet, but I personally would not give up
>>on using a real computer with a real OS.
>
> I would not even DREAM of such a think even if Google paid me
> trice as much as my box is worth and for so many reasons, that I could
> write a book about it. EASILY. You know my writing style by now, right?
> :--}
>
I don't follow.
>> even though I have and use a
>>netbook, what is more notable than this is that I run a full-featured
>>Linux
>>on the thing (Ubuntu), rather than the shipped gimped distro (Xandros).
>
> Actually, I do like Ubuntu quite a bit.
> It was a breath of fresh air for a couple of months
> after my win box was rooted and I simply could not use it.
>
> It is almost there. In fat it IS there, and for all I do,
> I could easily switch to it without loosing a thing.
>
yeah...
I still mostly use Windows, even though there is not a whole lot keeping me
there.
mostly I do so, since a larger potential userbase exists on Windows.
sadly, my project has been having MS-style technologies gradually creep in,
but nothing which would particularly hurt portability (only stuff which
would seem slightly "odd" on Linux...).
> Except JVM under Linux runs about 2 times as slow for what I do.
> Have no idea why. Sounds a bit weird to me.
>
> Seconly, I can not run my monitoring firewall on it,
> which is a total show stopper.
>
> And finally, I do not like the NetBeans and Eclipse that much.
> Pretty clumzy stuff, I'd say. Plus horrible code completion
> functionality. Too convoluted everything.
>
> The way I have it right now is a breeze for me.
>
> But, as soon as I see a real good IDE, which could already
> be there, except I did not see it, and I see my JVM running
> as fast, I'd be willing to totally switch even before I
> rewrite the firewall driver. The program code should be easy
> to port. But the network driver interface could be a major
> pain. I do need an equivalent of NDIS intermediate device
> driver that sits as the lowest thing on the stack, just
> above the netowork card driver.
>
> I am WAY too fed up with this windows trip.
> The most unstable thing in the world, even compared with pub domain
> Linux.
>
I don't exactly do whole lots of Java development, and what little I have
done has not been for a "proper" JVM anyways. (some minor stuff for a
mockup/mini VM within my own projects).
so, alas, not much comment here.
>>in the same way, I would not likely consider something like Chrome unless
>>it
>>were at least as capable as a full Linux distro (even if I have noted that
>>the thing is too slow to really build or run any of my major projects on).
>
> I am not even reading any of that hype.
> First of all, I am not going to switch anything, especially on the O/S
> level, until it had at least 2 years to run and most nasty things
> are fixed.
>
> Secondly, considering the fact that microsoft is in the game since
> yearly eighties and have megatons of stuff developed, just to
> go with some arrogant, greedy out of their mind monsters, and quite
> literally at that, would be not only suicidal but outright stupid.
> And I did have to deal with them on a much closer basis than
> most people. Probably the most disgusting feeling I ever had.
> "I don't care" lessness is at stratospheric level.
>
ok.
tanix
>I don't follow.
I mean google trying to get into O/S business essentially.
I don't know much about it, but some time ago I have heard
that Google wants to go for Microsoft's throat in the O/S business.
Not that I would pay any attention to this kind of arrogance.
Google got so arrogant and obnoxious with ther "suck-cess" trip,
that they seem to even think: hey, what is miscrosoft?
Lets bully them out of the market with our horns.
And from what I have seen, they really think they've got some
"ace" card to do it with.
They want nothing less then "revolution" in computing!!!
Brrrrrr.
BGB / cr88192
what they are building hype for is, AFAICT, Linux -X11 +Chrome (the
browser).
I guess they are building a custom GUI based around the browser's UI, and
essentially the browser will be the main UI for the OS.
I guess the idea is that pretty much all software for the OS will be
streamed net applications (presumably apart from the kernel and browser,
which will be proprietary?...).
personally, the idea does not sound particularly appealing.
I would personally much rather see internet-related facilities better
integrated with the OS, while still allowing a more conventional development
model. this would be, for example, if the OS itself came with a good-quality
JavaScript engine (which played well with C), and maybe an HTTP-based
network filesystem which had something analogous to a web-cache (but less
crappy). in this way, full applications could be "pulled down" and run
locally (but, otherwise, packaged and put online).
then again, MS has half-assedly done some of this already (errm, only that I
have my doubts that they are good enough to be worth using...).
(using a funky API and/or having to mount a WebDav account as a local drive
letter is not ideal...).
I guess though having direct access to a web-backed cache via plain file IO
requests would just be too convinient though.
in the past, I had an HTTP client and server, but the code eventually broke
away and I never really bothered to revive it (not having any clear or solid
need for it thus far I guess...).
(actually, a lot of my network code broke up some-odd years back, when I had
at the time essentially redesigned my VFS system in a way which broke most
of my sockets-related code, since sockets were routed via the VFS API, which
I mostly redesigned as a cleanup effort).
recently, I had partially started work on re-implementing this, but didn't
really go much further (I have an x86+POSIX based interpreter which itself
has sockets, but they are purely "local" at present, since they were more
added for internal IPC and client/host communication than for
networking...).
<snip> (doesn't seem anything more was commented on, ok).
BGB / cr88192
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, ...).
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.
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, ...).
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.
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.
so, my beliefs here are that:
the world does not revolve around the VM, the VM framework should "assist"
the app, not "dominate" it;
it should be possible to use which parts are needed, and discard the rest
(or supply alterantive implementations, if this is needed);
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);
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;
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);
...
however, I have tried to minimize creating "novel" parts when possible.
sadly, some level of "novelty" and "internal dependencies" are inevitable it
seems...
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).
however, it is all a bit of a "trudging through mud" experience, and C
remains as the only really "usably complete" language in the mix (my C
compiler contains a few holes and failings, but for the most part it is
adequate).
but, ideally, an app will "use" a framework, rather than be "built on top
of" it, 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...).
in a similar way, the .NET VM architecture is sort of like a "big brother"
to the JVM. there are many subtle aspects which are similar, but with one
notable and apparent difference:
.NET is FAR more complicated WRT its internal workings.
(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, apart from the persisting lack of a class library
(writing Java code in a vacuum is not nearly so compelling).
> 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, 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...).
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.
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.
however, an interpreter would allow, potentially, compiling C++ code to x86,
loading the x86 in an interpreter and running it (at likely crap speeds),
...
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".
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.
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...
tanix
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.
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
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.
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.
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
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 realized
I was screwed again by some fools, selling my 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.
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?
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
>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.
>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
mankind.
>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
>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.
>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.
>(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!
>but, ideally, an app will "use" a framework, rather than be "built on top
>of" it,
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
>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.
> 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).
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.
>(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.
>> 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.
> 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
>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.
>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
>"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.
>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.
BGB / cr88192
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, ...).
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 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.
> 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.
> 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...
> 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".
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...
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. it
would be better if one could compile it in both cases, rather than creating
yet another barrier:
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 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.
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.
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).
JavaScript is not likely to scale well.
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". 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 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
> 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".
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.
> 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, and set
up "the one true VM to rule them all".
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).
> 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.
>
yep.
well, there are merits to VMs, and there are costs...
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.
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.
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++.
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.
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).
>>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...
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...).
currently C and Java are the main "script" languages in use, 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).
I may instead switch to an alternative strategy, and maybe get around to
writing a Java compiler which produces JBC / "class" files, and then make
use of my JBC interpreter, or a translator, for plugging this into the rest
of the VM.
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, ...).
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).
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
> that 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. 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.
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.
>>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.
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.
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.
>>....
>>
>>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.
granted, you wont get the whole ".NET framework" this way, but one can get
C# and MSIL, which have a few merits.
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.
>>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.
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.
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).
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.
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.
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).
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).
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...).
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 (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 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.
>
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.
>>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.
>
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.
>>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...
ok.
tanix
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,
>....).
>ok.
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.
>....
>>>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?
:--}
>ok.
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.
>>>....
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.
>>>>>granted, nothing is perfect.
>historically, probably...
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.
>ok.
Coolio! :--}
>>>yeah.
>ok.
>> 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.
>ok.
>>>or such...
>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.
BGB / cr88192
yeah.
>>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.
>
this is not even for the graphical code.
if it were only the graphical code, I would have less reason to complain
about it...
> 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.
>
yep, except that on Windows GTK can work via GDI (though it does so in a
very X11-like manner, namely creating a window and dumping graphics into
it...).
I just dislike GTK though as it has a bad habit of not really working on
Windows (as well as not exactly being a very clean API).
X11 abstracts over the graphics hardware and facilitates multiplexing and a
"window manager".
>>> 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.
>
yes, ok.
>>> 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.
>
granted, but it is not so bad when after one has a 10+ years old codebase,
and so most of the basic stuff is already working. granted, there are good
and bad points here.
>>> 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.
>
yeah.
one of my annoyances with the JVM though is using UTF-16 for character
strings, since this makes strings-heavy code waste memory (I personally
prefer UTF-8 for most things).
> 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.
>
I do both 3D and soft-real-time apps.
in some kinds of apps, performance is fairly critical to usability, as lag
makes the app unusable.
>>> 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.
>
ok.
>>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.
>
ok.
>>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.
>
yep.
> 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 nice to have an option is all, especially for mixed Java and C /
C++ apps.
at present, mixing Java and C code is "not exactly nice", which is sad...
it would be nicer if, say, one could write parts in C, and parts in Java,
and not have to worry about using magic rituals needed to get them to play
together.
>> 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.
>
well, not all VM's are the JVM or .NET style.
consider the Python VM:
the main part of the app is typically C or C++, and then it links against
the VM, which in turn loads python scripts or bytecode files.
the goal and use case is very different, and my VM is, in many respects,
closer to the Python VM (in purpose) than it is to the JVM.
so, there is a cost:
my strategy does not allow avoiding rebuilding an app for various target
OS's;
it is a tradeoff, but it is acceptable enough for my uses.
although, it is not mandated by my design, this is just how I am currently
using it (otherwise, I would have to migrate much of the codebase to run on
top of the 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.
>
worth mentioning here is LiquidVM, which runs both Java and C in a VM.
no new language is created here.
errm...
I am not trying to build a "new ivory tower", as I already dislike this
strategy...
more, I am building stuff to do what I want to do with it...
I have no new language, no fudamentally new architecture, ...
actually, it is a set of very conservative designs, in that nearly every
part is based on things that are already fairly well established, such that,
for the most part it is invisible.
once as a joke, I considered calling the whole VM project "Silverfish", and
went as well as to make a glossy metallic logo image for this (depicting one
of these critters partly in a circle).
the idea is a VM more like the silverfish, which lives in ones' laundery and
eats lint and stuff...
however, in general I call it 'BSCC'.
>>> 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.
>
yes, ok.
>>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.
>
well, they work fairly well for what they do.
static languages make up most of the code which does actual work;
and dynamic code usually does specific tasks for the benefit of a particular
app.
it all works out well enough I think.
>>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.
>
ok.
>>JavaScript is not likely to scale well.
>
> Well, it does not need to. It is a client end gizmo.
>
it is also gaining popularity in non-browser settings...
>>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!
>
yep.
ok.
ok...
maybe a paper of rational and design explanations?...
>>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.
>
well, I have some stuff here:
http://cr88192.dyndns.org/bscc.html
it has a general rationale, a partial spec of some of the data, and some
project dumps (most recent from around 4 months ago...).
>>> 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.
>
yep.
granted, yes.
I don't so much like the Python language, but I suspect my goals are a
little more closely aligned, granted, the technology is itself a slight bit
different...
>>> 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?
>
granted.
>>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?
>
well, as noted, I don't intend to abolish it.
instead, goals can be addressed partly via alternative implementations which
address alternative use cases, but which allow for architectural
differences.
examples:
Apache Harmony (different workings and internal organization);
GCJ (native code support);
Dalvik (essentially a different VM technology);
...
granted, Suns ideal can only be universally true if there is a universal
implementation, which at this moment is generally held to be Sun's JVM.
similarly, Sun has historically tried to be fairly "Iron Fisted" with
maintaining this status quo.
this is the extreme opposite of, say, C, where there is no such
implementation (MSVC is no more "the true C compiler" than is, say, "GCC").
there are standards, but a standard is neither a reference implementation
nor a direct authority figure.
however, if it is allowed that implementations freely diverge and only
remain compatible by consensus, then one can no longer claim that apps are
entirely portable, "lowering" it to the level of C (which is often demeaned
by supporters as being a low-level and generally unportable language, ...).
so, most of this is a lot more philosophical and political than
technological.
one can actually leverage a very large amount of power from otherwise small
details, or waste huge amounts on effort on something which hardly amounts
to much of anything.
>>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?
>
some want a portable platform, and others want to script an otherwise
native-code app.
some want high-level scripting (JavaScript and Flash), whereas others want
app extension and high performance (such as LLVM).
in my case, I mostly want high-performance, app-extensions, and scripting.
the platform is not, however, an icon of universal portability (as is, my
project would fail miserably on this front...).
>>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?
>
well, if one is using GCC and C++, it is probably an acceptable option.
otherwise, these are its main merits.
I think it is fairly "hit or miss" WRT its class library, and only really
works "impressively" on Linux (mostly because on Linux, it offloads a lot of
the "heavy lifting" to Eclipse, but on Windows the Eclipse components are
not present, and so what it implements is a little less complete...).
it should be fine though if one does not demand that generics work, or that
one has a generally complete class library...
>>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.
>
Lua is basically a simplistic VM for a vaguely Pascal-like language.
http://en.wikipedia.org/wiki/Lua_%28programming_language%29
it competes some with Python, where Python is much bigger and full-featured,
and Lua is a lot smaller and light-weight.
>>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.
>
well, it doesn't seem like nearly so much when one starts out...
it was a whole world of implementing one feature, then the next, ...
until years of effort have been eaten up and one has some huge monstrosity
of a codebase...
I did not plan this all at the outset, it just sort of turned out this
way...
it is always, at the moment "well, this looks cool / useful / ..., I think I
will implement it".
many steps along the way were, as well, missteps and severe miscalculations,
but oh well...
the bytecode is some binary representation of a compiled or semi-compiled
program.
it is closely related to an IL (Intermediate Language), except that an IL
may refer to any number of possible representations (such as text and tree
structures...), whereas bytecode is usually much more specific: a stream of
individual byte-based opcodes which drive an interpreter or a JIT backend.
http://en.wikipedia.org/wiki/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?
>
because I built it all from the low-levels and work upward...
I don't personally seem to either think "top down", nor about the distant
future (I suspect my "future" usually tends to be maybe a few days or weeks
or so, then it is all in the land of vague uncertainties...)
I just keep going on and stuff happens, although why and how, I don't
know...
none the less, I do have opinions, and what stuff tends to happen (at least
as far as projects go), tends to somehow / magically go in about the
direction I would want it to go, so no real need to complain too much I
guess.
except that in some areas, very little tends to happen (my code goes
forwards and gradually gets more "impressive", but mostly just bigger), but
other aspects of life, not so much.
how I see progects, and how I see the world, is mostly what all I have
already done, and my memories of how it all works.
even though I have been surprised in a few cases, finding that my memories
of long-past technical trivia sometimes differ in surprising ways from the
actual facts (usually though, this has tended to be order transpositions,
such as which order items were placed in a struct, or in an array, ...).
for example, I had fairly solidly remembered Quake1 having used "pitch,
roll, yaw" angle ordering, yet checking back on the code (after issues with
Quake2) I had discovered it to be "pitch, yaw, roll", and I was at a loss to
explain why. another such difference had been in the coordinate-space
organization, where I had "clearly" remembered 'X=right, Y=forward, Z=up',
but had found
'-X=forward, Y=right, Z=up'.
>>currently C and Java are the main "script" languages in use,
>
> SCRIPT language?
> :--}
>
> I like that one!
>
yeah, they are not designed as such, and not traditionally used for these
purposes, but I use them for these purposes...
going back a few years, I was like "hmm, if I kludge this here
JavaScript-like script-language interpreter of mine with JIT capabilities
into compiling C, I can so totally not need to go through all the usual
hassles of a FFI".
in retrospect, this may have been a very ill-founded idea (it has resulted
in FAR more needed effort in the long run than it has saved).
but, OTOH, it has reduced most of my scripting dillemas to "just use C", so
I guess it pays off...
>> 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.
>
current running rime on this whole compiler mess:
~ 4 years now (actually, more about 3.8 or so...).
I had gone from the point of having the idea of a C compiler, to having it
working, in about 6 months (initially, I thought it would be a few weeks or
similar). subsequent years, mostly piles and piles of hacking on it
(eventually supporting x86-64, then adding Win64 and SysV calling-convention
support, ...).
the project sort of has a baloon-like inflation pattern...
>>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!
>
possibly, but I can probably reuse enough code that it "should" be more a
task of hackery...
as-is, I already have a C-compiler frontend (partly hacked for both Java and
C# style syntax), as well as a "Jasmin" clone, so going direct would likely
be less of an issue than trying to force Java through my backend.
"should" be mostly rewriting the frontend to produce Jasmin-like output,
rather than RPNIL output, and using said jasmin-like tool to produce
bytecode and class files (actually, I would probably ram it together with my
JBC interpreter, since it has a class loader which would also be rather
useful in this case).
or, IOW, force a few parts together, do some ugly hackery with the
internals, and, presto...
>> 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!
>
it is all stuff which piles up...
each part is not nearly so amazing in and of itself...
>>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.
>
yep, dunno...
>>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.
>
yep.
my past experience is that code ends up turning into dirt.
one can write it quickly enough, but it likes to blow away in the wind.
C is more like rocks in my case. they may be ugly and hard to work with at
times, but at least they fall to the ground and generally stay there.
enough rocks and one has a mound...
it stays there, but as a downside it is really heavy...
> 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.
>
ok.
>> 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.
>
yep.
it depends a lot on which parts are needed though, since there are annoying
dependency issues.
if all one needs is an assembler+linker or a GC, that is fairly easy...
if one wants (in my case), VFS, dynamic types, Class/Instance OO facilities,
... then they also end up needing to include the assembler and the GC.
the C compiler needs all of the above.
...
the x86 interpreter can operate standalone, but really likes to have the
former facilities (I ended up making it take the "back-roads" approach of
trying to load the DLLs and grab the interfaces, although I am generally
displeased with this strategy since it goes against my usual aesthetic...).
>>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.
>
ok, fair enough.
I have some "pseudo-COM" stuff going on (if you have seen JNI, this is a
fairly good idea of what I am talking about). some parts are plugged
together with function-pointer structs, ...
>>>>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.
>
hell, I don't think I have the resources either...
however, I hesitent of pruning anything either, so this is sort of a
dillema...
>>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?
> :--}
>
ok.
in the LLVM case, most of the headers and source files are too small...
so, maybe one opens a file to find it contains maybe 100 lines, 15-20 are
maybe header inclusions, and or a single class declaration, or maybe a few
methods. trying to follow the code is difficult as lots of time goes into
mostly opening and closing text editor windows...
I think it may be though a result of people using Eclipse as an IDE, and
Eclipse likes doing things this way?...
yes, ok.
>>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.
>
yes, ok.
>>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.
>
yes, it is odd.
I had liked it, since in theory it could offer a good tradeoff between C and
Java.
nevermind that it is big and complicated.
the usual strategy is to provide fallbacks.
something being missing causes it to use the fallback, which may be either a
simpler OS-provided facility, or if needed, a no-op facility.
this actually works fairly well in the majority of cases.
a lego by itself is still a lego, even if it doesn't necessarily do a whole
lot.
this is partly an "interesting" side effect of trying to keep code highly
modular, and plugging it together with interfaces:
in many cases, a component can be pulled or replaced, and other code will
often compensate automatically.
>>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.
> :--}
>
it is not that novel.
for example, many games will often do something similar, possibly trying
several different methods of getting the video and sound up and running
before ultimately giving up.
it can also be compared to how the OS uses drivers...
how flexible would an OS be if everything were hard-coded?...
so, usually most major components may have alternatives and fallbacks, and
most APIs can be designed as abstract interfaces where the machinery can be
replaced.
if OS kernels were written like how many apps were written, then the mess
which we would have would be horrible...
>>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.
>
yep.
yes, ok.
yes, ok.
well, I think some amount of the Windows NT line was based on grabbing up a
bunch of source from BSD.
I found it mildly ammusing to have been looking at one of their SDKs, and
noting a copy of both the zlib and libjpeg liscense agreements...
>>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.
>
well, CP/M was ripped off to make MS-DOS, and DOS was extended with a MacOS
immitation to make Windows 3.x, and was fused with DOS to make Windows 95.
elsewhere, the BSD codebase was grabbed up and largely reworked into NT,
some parts of which were common with Win95.
MS-DOS MZ-EXE header + BSD's COFF binaries became PE/COFF (replacing the
Win3x NE format, which was partly a horridly hacked DOS EXE I think with an
alternate entry point for Win16 code, and also LE which had been used I
think for Win32s and early Win95, ...).
...
well, no one ever really said they had to be original...
"embrace and extend", as the story goes, as one "rides on the shoulders of
giants"...
yes, ok.
>>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.
>
yeah.
I mostly used GL since I do a lot of 3D stuff...
apparently, this is the same kind of thing as most 3D modeling packages, ...
>>>>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.
>
'k.
>>> 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.
>
yes, ok.
yes, ok.
io_x
"tanix" <ta...@mongo.net> ha scritto nel messaggio
news:hh6heo$2lo$1...@news.eternal-september.org...bla bla bla
again
one general language
1) using a portable thypes
eg u8 == unsigned 32 bits
u32== unsigned 32 bits
i32== int 32 bits
etc and operation on them
2) eliminate all the undefinited behaviour on the languages
--------------------
1) or use one PC virtual machine (all x86 + hardware of one pc, all virtual)
that rapresent x86 PC and whatever you want: eg compiler etc
and install that in each machine even if have different cpu and hardware
Bo Persson
Nothing stops you from writing code that is limited to x86 machines.
Specifying the language as x86 only, stops these guys from using it:
http://www-03.ibm.com/systems/z/
Hardly a great idea!
Bo Persson
tanix
>>>> Sounds horrible.
>>>yep...
>yeah.
>>>agreed...
>yes, ok.
>ok.
>ok.
>yep.
>> you need to compile in 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 nice to have an option is all, especially for mixed Java and C /
>C++ apps.
>at present, mixing Java and C code is "not exactly nice", which is sad...
>it would be nicer if, say, one could write parts in C, and parts in Java,
You mean ala PHP?
:--}
Well, not sure I like to go THAT far.
It would be fine with me if it could be achieved on a level of
a routine or a class as far as granularity is concerned.
Interfaces are already there.
And yes, this IS one of those things I'd LOVE to have.
If one language turns out to be more efficient for whatever reason,
that would be great if you can just switch to a different language
in a different module to do it.
But then, since both of them rely upon the same VM, unless you can
come up with some trick to avoid it, I am not sure if it is doable
in realistic terms. Otherwise, your whole concept is flawed as far
as VM goes because in one instance you use the VM, and in another,
you go directly to O/S. But then, what is the whole point of VM
and how are you going to achieve that portability?
>and not have to worry about using magic rituals needed to get them to play
>together.
>>> 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 this is probably like a dream that never happens in reality.
:--}
>> But then I am not sure how would you go about with the very
>> concept of ?VM.
>well, not all VM's are the JVM or .NET style.
>consider the Python VM:
>the main part of the app is typically C or C++, and then it links against
>the VM, which in turn loads python scripts or bytecode files.
>
>the goal and use case is very different, and my VM is, in many respects,
>closer to the Python VM (in purpose) than it is to the JVM.
Is it a fairly complete design?
In terms of threads support, synchronisity issues, events and things
like that?
Cause if it is, I'd be curious to see it.
>so, there is a cost:
>my strategy does not allow avoiding rebuilding an app for various target
>OS's;
Non issue for me. Source level compatibility if fine.
After all, if the same source compiles for a different environment,
what does it cost you to compile compared to the benefits?
>it is a tradeoff, but it is acceptable enough for my uses.
Well, everything is a tradeff at the end.
>although, it is not mandated by my design, this is just how I am currently
>using it (otherwise, I would have to migrate much of the codebase to run on
>top of the 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.
>worth mentioning here is LiquidVM, which runs both Java and C in a VM.
Interesting. Never heard about it.
I did not spend any time on looking at VM grade issues.
>no new language is created here.
Oh, I like that one. I kinda have enough of those languages
to bother about.
>> They are not even looking about 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 can deveop something working within days, even though
>errm...
:--}
>however, in general I call it 'BSCC'.
Which is?
>>>> 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 with 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.
>yes, ok.
>>>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.
>well, they work fairly well for what they do.
>static languages make up most of the code which does actual work;
>and dynamic code usually does specific tasks for the benefit of a particular
>app.
I think it should be doable to have the same system that has
multiple behavior with the help of some scripting mechanism
when you need to run in interpretive mode need be.
But, using the same system can run at a performance of static
languages as a core.
Do not see a fundamental problem with it.
>it all works out well enough I think.
>>>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.
>ok.
>>>JavaScript is not likely to scale well.
>> Well, it does not need to. It is a client end gizmo.
>it is also gaining popularity in non-browser settings...
Well, could be. I am not exactly a Javascript guy.
I just have a rough idea about it. Never had time to actually
get into the nasty side of it and I am not even excited with
that idea because I have a feeling I'll get entangled in
those nasty surprises where you have to waste weeks to fix
something, like those js guys say.
Plus the most advanced part of it is simply weird to me.
>> I like this one:
>> What a joke!
>yep.
Hey, watch that line lenght. Do you see what happens after a couple
of followups?
:--}
>>>ok.
>ok.
Btw, is there any IDE that is as powerful as VS and supports
Java latest JDK? I tried Borland once. Did not like it a whole
lot. Even though it is kinda ok-ish. Except it works in strictly
Sun's way and produces the .class files at the end. So, during
the run time, my code runs 2 times slower with Sun's version
of JVM.
Secondly, Borland is generally a hacky to my eye.
Not very clean overall. That is why in my view VS beats all others
hands down from any standpoint I can think of.
>>>....
>> It may generate new ideas for others and for you, just by the shear
>> fact that you EXPRESS it. Take it from subconscious level to conscious.
>> Do not underestimate the significance of it.
>ok...
>maybe a paper of rational and design explanations?...
Sure. Why not? That is how it starts.
Why did you even decide to go this way?
What do you see as advantages of approach?
What kind of benefit you get at the end?
How is system architectured?
There are PLENTY of things you can spill out.
Because it looks like you've got something working actually.
It is not just a matter of mental excersize.
Plus, it will help YOU to see some things that are still
carried inside of you on a subconscious level without being
expressed, and that tends to make some things fuzzy.
Again, my personal opinion is this:
NO work should just go to waste, unless it is just an idle
excersize by some kids that have nothing better to do with
their lives but to forever be superficially curious.
We can not afford this any longer.
It is a grandast waste of all - waste of creative potential,
that is actually at work.
That is why I suspect plenty of work is actually being done,
but people just let it go to waste either because of fear
of condemnation of for the inferiority complex, thinking
their stuff is not as great as some Strousrup.
Screw that.
I don't want to challenge the very foundation of C++,
even though it could be. But trust me, it is not exactly
the word of God, omniscient.
Objective C is still live and kicking.
In fact, I just read the other day, that it is now used
heavily by Apple, and I would not underestimate ANYTHING
that Apple does.
So...
>http://cr88192.dyndns.org/bscc.html
Ok, I just looked at it.
I do like the idea of components as such.
Once you have such a concept, your hands are untied to do much
more creative things dynamically wiring it in.
I like this one:
"Instead, I try to incorporate things which already exist".
Totally agreed. This should be done as much as possible.
And this one is really cool:
"Why dynamic compilation? Because C just really needs eval..."
I LIKE that kinda stuff!
:--}
..
Jeez! You do have ALL sorts of things worked out by now.
Impressive.
I looked at it. But it is going to take some time to have a deeper
look.
One thing I suggest is to create some graphic stuff, like boxes,
diagrams, a system architecture or whatever you feel comfortable with.
I wish I could support you financially. Except I am not exactly a
"rich" man.
Do you happen to have a Paypal account?
You probably need at least 3 to 10 people working on this thing.
I am not sure you can handle it all by yourself.
>it has a general rationale, a partial spec of some of the data, and some
>project dumps (most recent from around 4 months ago...).
Well, one page is not enough.
Do not underestimate the documenation end of it.
The more things you can spill out in detail, the more benefit
to the whole project it is.
First of all, if things are understood on a more detailed level,
then even if you decide "I had enough of this", the other people
may decide to take it over and there is enough information to
continue the work.
The documentation for this one should be at least 30 fat pages.
The subsystems need to be described in much more detail.
I suggest it to be fully tagged, meaning well cross referenced
well, interlinked, with detailed table of contents.
That should take somewhere in the range of 2 weeks to a month.
Once that is done, you are in a much better shape I think.
At that point, you are going to have something that is not just
going to go away. Because others may be able to pick it up and
go on.
Basically, I do like this kind of thing.
>>>> 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.
>yep.
>>>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 screen 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 a hack.
>> I like "real" languages developed by people, who have seen it
>> all in and out, and not by some smart "wizards".
>granted, yes.
>I don't so much like the Python language, but I suspect my goals are a
>little more closely aligned, granted, the technology is itself a slight bit
>different...
I do not mind Python in principle.
There are some very flexible feature and pretty rich set of
expressive power. No question about it.
The guy IS pretty clerver I'd say.
Plus, once he's got this thing compilable, and on the fly,
that thing does deserve some attention to be paid.
May be I should have spent more time looking at it.
Except you never seem to have enough time to look at all the stuff
around.
>>>> 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?
>granted.
I think you are cheating here.
:--}
I bet you do not agree...
:--}
>>>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?
>well, as noted, I don't intend to abolish it.
>instead, goals can be addressed partly via alternative implementations which
>address alternative use cases, but which allow for architectural
>differences.
Too general for me. But if you had it all written down on a much
more detailed level, that would help to understand your position.
(wink, wink)
>examples:
>Apache Harmony (different workings and internal organization);
>GCJ (native code support);
>Dalvik (essentially a different VM technology);
>....
>granted, Suns ideal can only be universally true if there is a universal
>implementation, which at this moment is generally held to be Sun's JVM.
>similarly, Sun has historically tried to be fairly "Iron Fisted" with
>maintaining this status quo.
That is true in my opinion.
And that eventually lead to disaster.
Were they more flexible in their approach and tried to cooperate
with ms, instead of posing as messangers of God, omniscient,
who knows, with their size, they could have struck the deal
with ms that would eventually produce more benefit to all,
and to them included, than this warfare stance.
I know those guys at Sun are arrogant. Seen it first hand.
And it WAS disgusting to deal with some of them. No questions about it.
But not to be able to comprehend what it means to fight with
ms? That is beyond all stupidity to me.
What is the result?
There is no longer Sun?
A BIG funken achievment!
>this is the extreme opposite of, say, C, where there is no such
>implementation (MSVC is no more "the true C compiler" than is, say, "GCC").
>there are standards, but a standard is neither a reference implementation
>nor a direct authority figure.
Correct. But I'd have to argue that whatever you have at the end
must be supported by a standard. After all, that IS one of the main
strenghts of the approach to just about anything in the USA.
Once things are standartized, you can rely upon it without fear
that things may DRASTIALLY change tomorrow, which may go as far,
as putting you out of your business or what have you.
But creating standards in such complex areas as software and
system architecture and design is nothing less than nightmare.
The overhead is WAY too much, and it takes YEARS for all those
high tower priests to agree on anything, and even after you do
agree, it is not even clear you genuinely have some breakthrough.
>however, if it is allowed that implementations freely diverge and only
>remain compatible by consensus, then one can no longer claim that apps are
>entirely portable, "lowering" it to the level of C (which is often demeaned
>by supporters as being a low-level and generally unportable language, ...).
I do not know how far you can take this claim of "entirely portable",
and, to tell you the truth, it is now what I am concerned with.
Because I have my own something and I do not want to sweat
if I want to make it work on at least MAJOR platforms, such as
Windows and Linux. I am not even looking at system level portability.
Meaning some low level device driver related code,
even though that would be REAL nice if that was possible.
I recall numega (softice) guys did some work in that direction.
But I did not spend that much time looking at it.
It did generate some stub code. But I was not impressed with
the overal value of it.
>so, most of this is a lot more philosophical and political than
>technological.
>one can actually leverage a very large amount of power from otherwise small
>details, or waste huge amounts on effort on something which hardly amounts
>to much of anything.
Yep.
>>>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?
>some want a portable platform, and others want to script an otherwise
>native-code app.
Well, these are two different aspects.
Portability and performance/scalability.
If you can achive BOTH of them with the same system,
that is ideal.
>some want high-level scripting (JavaScript and Flash), whereas others want
>app extension and high performance (such as LLVM).
>in my case, I mostly want high-performance, app-extensions, and scripting.
Well, but scripting IS a portable approach.
So, you are saying you can handle both of these things
and it is going to reconcile?
Then you have a home run!
:--}
>the platform is not, however, an icon of universal portability (as is, my
>project would fail miserably on this front...).
Do not know what you mean.
But the buzzword, which is my main concern, is portability.
Then, portability at high performance.
And THEN only, scalability.
>>>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?
>well, if one is using GCC and C++, it is probably an acceptable option.
>otherwise, these are its main merits.
>I think it is fairly "hit or miss" WRT its class library, and only really
>works "impressively" on Linux (mostly because on Linux, it offloads a lot of
>the "heavy lifting" to Eclipse, but on Windows the Eclipse components are
>not present, and so what it implements is a little less complete...).
Well, there IS Eclipse version for windows.
Except I did not quite like it.
Last time I used it was probably a year ago.
It is pitty they can not learn from VS.
Cause it all works like a champ.
Just look at the visual space utilization efficiency.
On smaller screens, there is nothing that even compares to VS
in terms of absolutely necessary things to be seen on the screen,
the size of all gui elements, the ease of navigation between
major aspects of your IDE, and the overall amount of visual
clutter.
Sure, on bigger screens this may no longer be applicable.
But even working with things is MUCH more intuitive and much
more simple in VS.
I did like NetBeans better in this respect.
It looked much cleaner and some Java experts do love it.
Except the code completion is simply horrible.
Primitive as it gets. You have to essentially continuously
scroll all over the place to find the exact symbol you need
to use. Code completion is WAY too primitive.
Why don't these guys learn from that which already exists?
>it should be fine though if one does not demand that generics work, or that
>one has a generally complete class library...
Well, I am perfectly happy with Java in that respect.
It is complet enough for me.
I do think that languages need to include much larger set
of things that were developed by competent people.
So you couold just drag and drop or copy/paste stuff
or simply link it in, without worrying about things like this is
all just a cludge or a hack.
Understood, it takes much more effort to support a rich set
of something. But I generally like to stay away from all sorts
of "toolkits" or what have you.
It all looks nice on paper, but when you start dealing with it,
it is either a grand headache or some weird limitations or ALL
sorts of things.
I like flexibility and freedom of expression.
It is a bit weird that once I hear "toolkit", I am about to
freak out. Seems like well, it should make things easier for
you as you have MORE tools to work with. But either there
is a bible sized pile of concoctions and I have to spend
another couple of years learning their weirdness, as they
put the whole world upside down and I have to learn another
language on the top of what I already know, which is too much
as is, or there is such a weird way to do something, that I
could care less if those "great designers" exist.
I have no time to learn another universe that is totally
different from the Universe I know already. Go to hell!
I need simplicity.
I need clarity.
I need expressive power.
I need flexibility.
And I do NOT need another pile of crap on my shoulders,
no matter how grand it looks on the paper.
I could care less if F# exists.
The look I took at it just yesterday was enough to put that thing
on a back burner for at least a year.
I am not interested in chasing some new "fasion"
and get sucked in into a "revolutionary" "new paradigm".
Enough of THAT kind of crap.
I saw so many "paradigms" already, that I wish I could unwind
some of it and make a deal with God to give me my years of
life back and erase some of that grand bullshit from my record.
In that respect, I am as "conservative" as it gets.
I give a flying dead chicken about "new technologies".
It is all an old story to me.
I give a funk about some "breaktrough" language.
I want something that will fit nicely into my cockpit
with all the stuff I already know,
and is easy enough to INCREASE power, portability and flexibility.
I give a flying dead chicken if generics exist.
And about the LAST thing I care about is those "design patterns".
Makes me puke.
Sure, if you don't have brains, you need some recepie
and a "good programming practice", some desing "template"
for the zombies, so they do not get lost in this giant forest
of ultimate logic.
>>>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.
>Lua is basically a simplistic VM for a vaguely Pascal-like language.
Jeez!
So, we have this Pascal P-Machine biting back?
Is that what I am hearing?
It never died?
>http://en.wikipedia.org/wiki/Lua_%28programming_language%29
Sorry, I can not do any more reading right now.
Ok, let me see just for a couple of minutes...
Funky stuff, I tellya. I wish I had luxury to afford to get into
these kinds of things.
:--}
>it competes some with Python, where Python is much bigger and full-featured,
>and Lua is a lot smaller and light-weight.
I light light-weight buzzword!
:--}
>>>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.
>well, it doesn't seem like nearly so much when one starts out...
I know, I know.
:--}
Until you get your feet wet!
>it was a whole world of implementing one feature, then the next, ...
>until years of effort have been eaten up and one has some huge monstrosity
>of a codebase...
Yep. That is what I peddle:
"We do not know what information truly is".
Long story.
>>>> Sure, why not?
>> If someone tells it to me in few words, fine, I'll look at it.
>> What is the primary motivation behind the bytecode?
>the bytecode is some binary representation of a compiled or semi-compiled
>program.
>it is closely related to an IL (Intermediate Language), except that an IL
>may refer to any number of possible representations (such as text and tree
>structures...), whereas bytecode is usually much more specific: a stream of
>individual byte-based opcodes which drive an interpreter or a JIT backend.
Well, that much I know. I just did not get into nuts and bolts of it.
>http://en.wikipedia.org/wiki/Bytecode
Well, we'd have to leave it for another time.
I am not a revolutionary to bother about things like these
and have no plans to rewrite Java or anything of that kind.
They say it works? - Fine with me, whatever it is.
They say BECAUSE of it, things are nearly as slow as interpreters
are? Well, I doubt it is THAT bad, but yes, I can see your point.
Do you have something better that provides as much portability
as bytecodes, being the language of VM?
Fine, lemme see it.
That is the extent of me being involved with this stuff.
Never ever cared about it one way or another.
>>>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?
>because I built it all from the low-levels and work upward...
Gosh. You ARE one of those dedicated few.
:--}
I am just more interested in information as such.
I've been through the whole trip, from electronics, theory
and up.
But from times when I was young enough and heard this thing
when I was studying at the university:
"Sinusoid does not carry any information"
It was a shock to me.
I could never agree with such a thing.
So I started looking at what IS this thing called information.
And the more I looked at it, the more it was clear to me,
we just do not know what information is PERIOD.
And to this day, we simply have no clue.
Different story altogether.
>I don't personally seem to either think "top down", nor about the distant
>future (I suspect my "future" usually tends to be maybe a few days or weeks
>or so, then it is all in the land of vague uncertainties...)
That's fine. One does not need to take it in fanatical terms.
Whatever fits your fancy is fine with me.
As long as you use YOUR brain, and not just copycatting someone
elses ideas.
I like freshness, no matter how "practical" it is.
I like something that boggles my mind,
not because of some additional complexities,
but because of something radically "efficient",
radically fresh,
something that really means something at the end.
I hate crowds of goats, forever incrementally polishing
someone elses crap and calling it a "progress".
Ugggh.
I stay away from these kinds of people.
They make me shiver.
It simply numbs my by its deadness and staleness.
>I just keep going on and stuff happens, although why and how, I don't
>know...
Cool. I like that kind of stuff.
That means to me you are still innocent.
You are still not corrupt.
You are still fresh.
You are still young.
You are till that fresh leaf on the tree of life.
What a joy.
After all, what all this big farse about "languages" and
any of these "great", "revolutionary" "technologies" is all about.
Well, a dead mosquito fart at the end
in the grand scheme of things
of Infinite, all pervading Intelligence.
Just like a wind.
"Dust in the wind...
All we are is dust in the wind...
Dust in the wind...
All we are is dust in the wind..."
A VERY good song.
Beautiful.
>none the less, I do have opinions, and what stuff tends to happen (at least
>as far as projects go), tends to somehow / magically go in about the
>direction I would want it to go,
That IS the very "magic" of it.
Blessed are thou.
> so no real need to complain too much I guess.
>except that in some areas, very little tends to happen (my code goes
>forwards and gradually gets more "impressive", but mostly just bigger), but
>other aspects of life, not so much.
Well, but who knows, may be this IS "THE" Aspect!
:--}
>how I see progects, and how I see the world, is mostly what all I have
>already done, and my memories of how it all works.
>even though I have been surprised in a few cases, finding that my memories
>of long-past technical trivia sometimes differ in surprising ways from the
>actual facts (usually though, this has tended to be order transpositions,
>such as which order items were placed in a struct, or in an array, ...).
>for example, I had fairly solidly remembered Quake1 having used "pitch,
>roll, yaw" angle ordering, yet checking back on the code (after issues with
>Quake2) I had discovered it to be "pitch, yaw, roll", and I was at a loss to
>explain why. another such difference had been in the coordinate-space
>organization, where I had "clearly" remembered 'X=right, Y=forward, Z=up',
>but had found
>'-X=forward, Y=right, Z=up'.
:--}
>>>currently C and Java are the main "script" languages in use,
>> SCRIPT language?
>> :--}
>> I like that one!
>yeah, they are not designed as such, and not traditionally used for these
>purposes, but I use them for these purposes...
Jeez!
:--}
>going back a few years, I was like "hmm, if I kludge this here
>JavaScript-like script-language interpreter of mine with JIT capabilities
>into compiling C, I can so totally not need to go through all the usual
>hassles of a FFI".
>in retrospect, this may have been a very ill-founded idea (it has resulted
>in FAR more needed effort in the long run than it has saved).
>but, OTOH, it has reduced most of my scripting dillemas to "just use C", so
>I guess it pays off...
>>> 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.
>current running rime on this whole compiler mess:
>~ 4 years now (actually, more about 3.8 or so...).
Well, long enough to get something "out the door".
>I had gone from the point of having the idea of a C compiler, to having it
>working, in about 6 months (initially, I thought it would be a few weeks or
>similar). subsequent years, mostly piles and piles of hacking on it
>(eventually supporting x86-64, then adding Win64 and SysV calling-convention
>support, ...).
>the project sort of has a baloon-like inflation pattern...
>>>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!
>possibly, but I can probably reuse enough code that it "should" be more a
>task of hackery...
>as-is, I already have a C-compiler frontend (partly hacked for both Java and
>C# style syntax), as well as a "Jasmin" clone, so going direct would likely
>be less of an issue than trying to force Java through my backend.
>"should" be mostly rewriting the frontend to produce Jasmin-like output,
>rather than RPNIL output, and using said jasmin-like tool to produce
>bytecode and class files (actually, I would probably ram it together with my
>JBC interpreter, since it has a class loader which would also be rather
>useful in this case).
>or, IOW, force a few parts together, do some ugly hackery with the
>internals, and, presto...
I do suggest to document this stuff in much more detail
with pictures.
>>> 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!
>it is all stuff which piles up...
I almost feel jealous!
I also had a trip with languages while back.
But then I gave up.
It was Forth and Lisp.
Spent a few years extending that stuff quite a bit.
Not sure if I can even find that code.
Then it was expert systems and AI.
Did some interesting stuff.
And then I gave up on the whole thing. I just went away.
Looked like an excersize in futility, so immense the task was,
and, as I said before, I got a feeling we do not even know
what information is and keep digging all sorts of things
and concocting all sorts of "systems", and all it is is empty,
signifying nothing at the end.
I did dig into database theory and stuff like that.
Played with that one. Looked interesting up to a point.
Then I saw a dead end with that one also.
>each part is not nearly so amazing in and of itself...
All I want is SYSTEM.
Don't even know how to describe it to others.
But I do know what I am after.
>yep, dunno...
>>>yep.
>yep.
Exactly.
>C is more like rocks in my case. they may be ugly and hard to work with at
>times, but at least they fall to the ground and generally stay there.
No questions about it.
>enough rocks and one has a mound...
>it stays there, but as a downside it is really heavy...
True. But I think people were simply blindly following some
incremental "imporvements", feeling comfortable like in a herd.
Secondly, we, as mankind, did have to go through all those
manifestations, just in order to see that is all nothing more
than fragmented views.
Now it seems the time is ripe to make something genuinely
exciting and I do not think guys like microsoft or sun can
stand on the way any longer.
For one thing, the open source idea gained WAY too much weight,
to the point that ms is getting challanged by linux world,
and specifically Ubuntu.
That guy from Africa seems to be a brilliant mind.
There is one other guy in the XML stage that is doing something
really impressive.
His name is Uche Ogbuii.
And amazing guy.
He's been working on his Akara/Amara stuff for quite a while,
and now it seems he's got a group of people who got interested
in it enough to give him some substantial help with it.
I bet we are in the middle of seeing something that will ring
some bells.
I am on the developers list even though I do not participate
in any way, and what I am seeing is lots of emails. All sorts
of work is being done and they've got this thing pretty much
humming by now.
I am keeping an eye on it, at least looking at some of those
emails. I think it is going to plug in at some point into
the system. It is a Python world. But what to do.
Gosh!
Why do they do python?!?
>> 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.
>ok.
But. Running totally portable like all these dynamic languages.
:--}
>>> 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.
>yep.
>it depends a lot on which parts are needed though, since there are annoying
>dependency issues.
>if all one needs is an assembler+linker or a GC, that is fairly easy...
>if one wants (in my case), VFS, dynamic types, Class/Instance OO facilities,
>.... then they also end up needing to include the assembler and the GC.
So what?
>the C compiler needs all of the above.
>....
>the x86 interpreter can operate standalone, but really likes to have the
>former facilities (I ended up making it take the "back-roads" approach of
>trying to load the DLLs and grab the interfaces, although I am generally
>displeased with this strategy since it goes against my usual aesthetic...).
>>>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.
>ok, fair enough.
>I have some "pseudo-COM" stuff going on (if you have seen JNI, this is a
>fairly good idea of what I am talking about). some parts are plugged
>together with function-pointer structs, ...
The thing I saw in these kinds of things is extreme complexity
on the code writing end.
There does not seem to be a way to make it simple and you have to
waste years on yet another way of saying it. Too much of plumbing
work is exposed to program writer. It should be all nicely hidden
to my taste. It gets under your skin after a while, every time
they invent something "powerful".
It simply translates into you needing to learn yet another bible
worth of crap with all those lice, just waiting to get under your
skin.
>>>>>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.
>hell, I don't think I have the resources either...
>however, I hesitent of pruning anything either, so this is sort of a
>dillema...
Well, one more time:
Get it WELL documented to sufficient enough degree of details.
Put some pictures in.
You won't be able to handle it all by yourself,
That much I don't have much doubt about.
You need more hands and brains involved.
And don't be worried that you are not a big gun, and "who cares".
How do you know that no one does?
Just right here, on this very group, there are people sitting
and wasting away pretty much from what I see, and their minds
are pretty much idling, just looking into someone elses pockets.
What a royal waste!
And that is NOT the end of the world.
You never know what might appear out of the blue.
You may not even know what you are working on and why.
Just TRUST.
Trust yourself in the MOST minute manifestation,
and do not worry about that big world. It is not as big as it looks.
>ok.
>>>ok.
I do like the idea of the include files.
It is just another layer that does some useful things to you.
I asked the Java experts why is it they have gotten away with
include files. Do not recall hearing anything that made any kind
of sense to me.
>so, maybe one opens a file to find it contains maybe 100 lines, 15-20 are
>maybe header inclusions, and or a single class declaration, or maybe a few
>methods. trying to follow the code is difficult as lots of time goes into
>mostly opening and closing text editor windows...
>I think it may be though a result of people using Eclipse as an IDE, and
>Eclipse likes doing things this way?...
Well, not sure about this one.
>>>>>....
>yes, ok.
>yes, ok.
>yes, it is odd.
>>>> And forever so.
>>>yep.
>>>yep.
>> Wow!
>> I am impressed.
I like that one.
>this actually works fairly well in the majority of cases.
>a lego by itself is still a lego, even if it doesn't necessarily do a whole
>lot.
>this is partly an "interesting" side effect of trying to keep code highly
>modular, and plugging it together with interfaces:
>in many cases, a component can be pulled or replaced, and other code will
>often compensate automatically.
Cool.
>>>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.
>> :--}
>it is not that novel.
>for example, many games will often do something similar, possibly trying
>several different methods of getting the video and sound up and running
>before ultimately giving up.
>it can also be compared to how the OS uses drivers...
>how flexible would an OS be if everything were hard-coded?...
>so, usually most major components may have alternatives and fallbacks, and
>most APIs can be designed as abstract interfaces where the machinery can be
>replaced.
>if OS kernels were written like how many apps were written, then the mess
>which we would have would be horrible...
Yep. That is one of the core priciples of O/S,
which separates things to user and kernel mode.
Once you are at a kernel leval, you are the king
and you know things are clean.
And you provide the interface to all sorts of crazy people with
their user apps, so they clearly know which kinds of things they
are allowed to touch in the system.
Else, the whole thing is nothing more than insane asylum.
>yep.
>>>>>>>granted, nothing is perfect.
>>>historically, probably...
>> And I would not doubt in my mind that they intended to screw Sun
>yes, ok.
>yes, ok.
I just can not see why people are so much obscessed with money.
Why do they think it is an ULTIMATE measure of ANYTHING?
What is this "fear of survival" as I call it?
I could never see the point of it, even though I saw ALL sorts of things.
And I can comprehend how "horrible" it looks,
if you can not "survive".
So people resourt to licking the rear end of those "powerful",
just be allowed to be in the herd.
Brrrr.
>>>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.
>well, CP/M was ripped off to make MS-DOS, and DOS was extended with a MacOS
>immitation to make Windows 3.x, and was fused with DOS to make Windows 95.
>elsewhere, the BSD codebase was grabbed up and largely reworked into NT,
>some parts of which were common with Win95.
Well, at one point I had a full souce to Win2k and had a chance
to see some of it. Not that it was of any use.
>MS-DOS MZ-EXE header + BSD's COFF binaries became PE/COFF (replacing the
>Win3x NE format, which was partly a horridly hacked DOS EXE I think with an
>alternate entry point for Win16 code, and also LE which had been used I
>think for Win32s and early Win95, ...).
>....
>well, no one ever really said they had to be original...
>"embrace and extend", as the story goes, as one "rides on the shoulders of
>giants"...
Well, it is all nice and dandy.
But how come the society did not find a way to compensate those,
that do the real work and create things that eventually get wired
into the "real" products and gazillions of bux are made off it,
while the original creators do not get a penny?
Are we THAT dumb?
And I know we are. Too much zombification is no good for you.
But it is time to put an end to this.
LONG time due in fact.
tanix
What is this?
BGB / cr88192
"Bo Persson" <b...@gmb.dk> wrote in message
news:7pouah...@mid.individual.net...
yeah, x86 only is pretty weak...
even with x86 only, there is still 32 vs 64 bit x86, which creates all sorts
of troubles...
using 32-bit x86 and either interpreting or JIT'ing it, is a little better,
but still kind of a nasty option...
however, doing some of the code in 32-bit x86 and JIT'ing it for the 64-bit
case has been something I had been considering, even if it is nasty...
MSIL / CIL is possibly a little better option, but CIL is a big and
complicated format.
JBC (Java ByteCode) is also available, but JBC is hardly general-purpose
(can't really do C, ...).
if possible, I would want to avoid creating for the world "yet another"
("portable") bytecode (we already have too many of these).
this is also why I am not trying to make a "new" prog-lang either, and
instead leveraging C and Java and friends. ideally, all should be open, and
"porting" largely little more than a matter of copy and paste...
>
> Bo Persson
>
>
BGB / cr88192
<snip>
going to see if all this can be cut down this mountain of text some.
>
>>> 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 nice to have an option is all, especially for mixed Java and C
>>/
>>C++ apps.
>>at present, mixing Java and C code is "not exactly nice", which is sad...
>
>>it would be nicer if, say, one could write parts in C, and parts in Java,
>
> You mean ala PHP?
> :--}
>
> Well, not sure I like to go THAT far.
> It would be fine with me if it could be achieved on a level of
> a routine or a class as far as granularity is concerned.
> Interfaces are already there.
>
> And yes, this IS one of those things I'd LOVE to have.
> If one language turns out to be more efficient for whatever reason,
> that would be great if you can just switch to a different language
> in a different module to do it.
>
yep.
> But then, since both of them rely upon the same VM, unless you can
> come up with some trick to avoid it, I am not sure if it is doable
> in realistic terms. Otherwise, your whole concept is flawed as far
> as VM goes because in one instance you use the VM, and in another,
> you go directly to O/S. But then, what is the whole point of VM
> and how are you going to achieve that portability?
>
well, it is not quite a VM in the traditional sense, in that there is no
singular or unified architecture, and no centralized design (instead it all
being composed of bunches of components).
rather, the goal of the system is to try to be able to glue enough stuff
together to make it all work.
granted, in practice it hasn't been quite so nice.
this is part of why there is a big "metadata database" in the mix. it sits
around and tries to keep track of all the data, functions, and types. other
code sits around which does little more than tries to figure out how to
resolve requests, sometimes generating glue code in the process.
so, in this respect, it is a little nasty...
this is also part of why there is a (mostly) unified naming and
type-signature system.
these signatures are also used by the automatic code generators, ... as
well.
<snip>
as far as portability, well, I don't make the claim that it will work
anything near like what the JVM does...
for now, it works on 32 and 64 bit x86, but for anything else, well then,
there is a problem.
the idea I had before was that for other archs, most of the
not-really-portable parts would be rewritten, and only really the APIs would
be kept intact.
(the idea would be that hopefully all of the parts and APIs could be
specified sufficiently as that clone parts could be written without too many
compatibility issues).
for some newer parts, I have been trying to address portability better, for
example, the x86 interpreter is generally written to try to avoid itself
depending on x86, ...
but, I don't really have a good or clean solution here.
I guess it will be "portable" in the same manner as POSIX tries to be
portable.
generally, one will find minor issues and incompatibilities, for example,
code written naively for Linux may not build right on FreeBSD or vice versa,
but generally it is possible to make code which works in both cases.
no provisions then are made for code which is not written portably, which I
guess is something Sun does fairly well (since Java largely enforces that
code written for their VM will also work elsewhere...).
>
>>consider the Python VM:
>>the main part of the app is typically C or C++, and then it links against
>>the VM, which in turn loads python scripts or bytecode files.
>>
>>the goal and use case is very different, and my VM is, in many respects,
>>closer to the Python VM (in purpose) than it is to the JVM.
>
> Is it a fairly complete design?
> In terms of threads support, synchronisity issues, events and things
> like that?
>
> Cause if it is, I'd be curious to see it.
>
it has threads, and synchronization is via good old mutexes.
I provide API wrappers for both threads and mutexes, partly to abstract over
the OS APIs, and partly to make GC aware of them.
events, well, not sure what exactly is in question here...
exceptions are not really workable at this point, since exception handling
is a big ugly mess in C land (since C doesn't have exceptions). I have some
API calls though which do them, and on Windows mostly hack into the Win32
and Win64 SEH mechanisms.
Linux has thus far been addressed mostly by "pretending" that Win32 SEH
exists.
I had designed a new EH mechanism to unify it all (based partly on both
Win64 SEH and Java's EH mechanism), but haven't really implemented it as of
yet...
it really doesn't help much that typically several different EH mechanisms
are in use on each OS as it is (Win32/64 have SEH, VEH, MSVC++ exceptions,
...), and Linux as well has several mechanisms (although g++ uses libunwind,
which has become de-facto).
none of this is well tested though, so I am hesitant to assert that the EH
actually works.
>>so, there is a cost:
>>my strategy does not allow avoiding rebuilding an app for various target
>>OS's;
>
> Non issue for me. Source level compatibility if fine.
> After all, if the same source compiles for a different environment,
> what does it cost you to compile compared to the benefits?
>
>>it is a tradeoff, but it is acceptable enough for my uses.
>
> Well, everything is a tradeff at the end.
>
yep.
>>although, it is not mandated by my design, this is just how I am currently
>>using it (otherwise, I would have to migrate much of the codebase to run
>>on
>>top of the VM...).
>
<snip>
>
>>worth mentioning here is LiquidVM, which runs both Java and C in a VM.
>
> Interesting. Never heard about it.
> I did not spend any time on looking at VM grade issues.
>
ok, but FWIW it is mostly a special purpose JVM, although I am not certain
its exact intended use case.
>>no new language is created here.
>
> Oh, I like that one. I kinda have enough of those languages
> to bother about.
>
yep.
>
>>once as a joke, I considered calling the whole VM project "Silverfish",
>>and
>>went as well as to make a glossy metallic logo image for this (depicting
>>one
>>of these critters partly in a circle).
>
>>the idea is a VM more like the silverfish, which lives in ones' laundery
>>and
>>eats lint and stuff...
>
> :--}
>
>>however, in general I call it 'BSCC'.
>
> Which is?
>
'BGB Scripting C Compiler'.
the name partly comes from its direct (codebase) ancestor:
BS1 (BGB Script / 1).
which was a short-lived (late 2006) implementation rewrite of BS (BGB
Script), which was a loosely JavaScript derived script language originally
written in about 2004.
it had replaced Lang/BGB (LB), which was in use from around 2001-2003 and
was a Scheme variant (but with a number of additions/alterations).
LB was where I had first started messing around with non S-Expression
syntax, one of my early examples having beat a Python-like syntax on top of
Scheme, but I soon came to the conclusion that this was a poor idea (it was
less fun messing with the indentation than with the parens...)
BS1 had originally been written because BS was too slow and used the GC too
much (so, BS1 was mostly a redesign and optimization effort). BS1 was then
mutated into my original C compiler.
both LB and BS1 had use S-Exps internally for the parser / ASTs.
BS had originally use XML DOM-style trees.
the early C compiler used S-Exps as well, but eventually switched back to
DOM (me re-grabbing some amount of code from the BS interpreter)
>
>>well, they work fairly well for what they do.
>>static languages make up most of the code which does actual work;
>>and dynamic code usually does specific tasks for the benefit of a
>>particular
>>app.
>
> I think it should be doable to have the same system that has
> multiple behavior with the help of some scripting mechanism
> when you need to run in interpretive mode need be.
> But, using the same system can run at a performance of static
> languages as a core.
>
> Do not see a fundamental problem with it.
>
ok.
well, the project is decentralized, so little stops different parts from
working in different ways.
>
>>>>JavaScript is not likely to scale well.
>
>>> Well, it does not need to. It is a client end gizmo.
>
>>it is also gaining popularity in non-browser settings...
>
> Well, could be. I am not exactly a Javascript guy.
> I just have a rough idea about it. Never had time to actually
> get into the nasty side of it and I am not even excited with
> that idea because I have a feeling I'll get entangled in
> those nasty surprises where you have to waste weeks to fix
> something, like those js guys say.
>
> Plus the most advanced part of it is simply weird to me.
>
yes, ok.
well, I have had at least some experience with a JS-style language (after
having written and used it for a while).
>
>>>>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).
>
> Hey, watch that line lenght. Do you see what happens after a couple
> of followups?
> :--}
>
yep...
>
>>> 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.
>
>>ok.
>
> Btw, is there any IDE that is as powerful as VS and supports
> Java latest JDK? I tried Borland once. Did not like it a whole
> lot. Even though it is kinda ok-ish. Except it works in strictly
> Sun's way and produces the .class files at the end. So, during
> the run time, my code runs 2 times slower with Sun's version
> of JVM.
>
> Secondly, Borland is generally a hacky to my eye.
> Not very clean overall. That is why in my view VS beats all others
> hands down from any standpoint I can think of.
>
not much used IDEs in a long time...
mostly Notepad + Windows Explorer + shells...
hard time seeing what an IDE really buys me, for the most part.
although, I guess IDE's have a few nice points, I don't know.
granted.
well, documenting and rationalizing everything is a thought.
I guess it is better than "well, it all just happened...".
"well, I threw the gold in the fire, and out came the calf...".
>
>>> That is what I can do.
>
>>> This should not go to waste in my opinion.
>
>>well, I have some stuff here:
>
>>http://cr88192.dyndns.org/bscc.html
>
> Ok, I just looked at it.
> I do like the idea of components as such.
> Once you have such a concept, your hands are untied to do much
> more creative things dynamically wiring it in.
>
yep.
like a textual assembler...
one can generate assembler nearly anywhere from anything, and send it to the
assembler.
this works out fairly well, much better than directly forging machine
code...
> I like this one:
> "Instead, I try to incorporate things which already exist".
>
> Totally agreed. This should be done as much as possible.
>
> And this one is really cool:
> "Why dynamic compilation? Because C just really needs eval..."
>
> I LIKE that kinda stuff!
> :--}
>
> ..
>
> Jeez! You do have ALL sorts of things worked out by now.
> Impressive.
>
> I looked at it. But it is going to take some time to have a deeper
> look.
>
ok.
> One thing I suggest is to create some graphic stuff, like boxes,
> diagrams, a system architecture or whatever you feel comfortable with.
>
> I wish I could support you financially. Except I am not exactly a
> "rich" man.
>
> Do you happen to have a Paypal account?
>
not personally.
eventually, at some point I could use a job, but for now I am mostly a
college student...
> You probably need at least 3 to 10 people working on this thing.
> I am not sure you can handle it all by yourself.
>
possibly, yes.
but, as-is, it is just myself.
I am not sure how I would go about organizing an actual "project" as such.
actually, all is hosted from a server in my room at present, mostly because
for a long time I had fairly slow internet (when I was libing around Asia),
and trying to get anything up on sourceforge or similar was just WAY too
slow...
even then, interest was not terribly great for prior stuff.
>>it has a general rationale, a partial spec of some of the data, and some
>>project dumps (most recent from around 4 months ago...).
>
> Well, one page is not enough.
> Do not underestimate the documenation end of it.
> The more things you can spill out in detail, the more benefit
> to the whole project it is.
>
> First of all, if things are understood on a more detailed level,
> then even if you decide "I had enough of this", the other people
> may decide to take it over and there is enough information to
> continue the work.
>
> The documentation for this one should be at least 30 fat pages.
> The subsystems need to be described in much more detail.
>
> I suggest it to be fully tagged, meaning well cross referenced
> well, interlinked, with detailed table of contents.
>
> That should take somewhere in the range of 2 weeks to a month.
> Once that is done, you are in a much better shape I think.
>
> At that point, you are going to have something that is not just
> going to go away. Because others may be able to pick it up and
> go on.
>
> Basically, I do like this kind of thing.
>
well, it is an idea...
even if no one likes the source, I guess it all could be of help if there
were any similar projects, since with a sufficiently "open" project, it
shouldn't matter as much who writes the components.
<more snip>
>
>>granted, yes.
>
>>I don't so much like the Python language, but I suspect my goals are a
>>little more closely aligned, granted, the technology is itself a slight
>>bit
>>different...
>
> I do not mind Python in principle.
> There are some very flexible feature and pretty rich set of
> expressive power. No question about it.
> The guy IS pretty clerver I'd say.
> Plus, once he's got this thing compilable, and on the fly,
> that thing does deserve some attention to be paid.
>
> May be I should have spent more time looking at it.
> Except you never seem to have enough time to look at all the stuff
> around.
>
agreed...
lots of skimming in this world it seems, people everywhere doing potentially
interesting stuff.
>
>>>>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?
>
>>granted.
>
> I think you are cheating here.
> :--}
>
> I bet you do not agree...
> :--}
>
well, I don't personally use Java or the JVM as such, but I can understand
why other people would do so.
personally, I don't expect everything to be homogenous, the world just
doesn't work this way.
my effort spawned I guess because I always just did things like how I wanted
to do them (well, and how I had always done them).
maybe about 1998/1999 I had looked into Java, but at the time I was not much
pleased with the experience, so I returned to C, which is what I had been
using before.
later on, I ended up mostly looking into Scheme (initially a Lisp
implementation I forget the name of, later Scheme via SCM and Guile...).
Guile was giving me trouble, so I looked some at the source and wrote my
own. this was the origins of my ventures into VM land...
it was much of a decade before I really started looking at it again, but by
this point I was already well versed in the underlying technology...
>>>>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?
>
>>well, as noted, I don't intend to abolish it.
>>instead, goals can be addressed partly via alternative implementations
>>which
>>address alternative use cases, but which allow for architectural
>>differences.
>
> Too general for me. But if you had it all written down on a much
> more detailed level, that would help to understand your position.
> (wink, wink)
>
ok.
>>examples:
>>Apache Harmony (different workings and internal organization);
>>GCJ (native code support);
>>Dalvik (essentially a different VM technology);
>>....
>
>>granted, Suns ideal can only be universally true if there is a universal
>>implementation, which at this moment is generally held to be Sun's JVM.
>
>>similarly, Sun has historically tried to be fairly "Iron Fisted" with
>>maintaining this status quo.
>
> That is true in my opinion.
> And that eventually lead to disaster.
> Were they more flexible in their approach and tried to cooperate
> with ms, instead of posing as messangers of God, omniscient,
> who knows, with their size, they could have struck the deal
> with ms that would eventually produce more benefit to all,
> and to them included, than this warfare stance.
>
> I know those guys at Sun are arrogant. Seen it first hand.
> And it WAS disgusting to deal with some of them. No questions about it.
>
> But not to be able to comprehend what it means to fight with
> ms? That is beyond all stupidity to me.
>
> What is the result?
> There is no longer Sun?
>
> A BIG funken achievment!
>
yeah...
>>this is the extreme opposite of, say, C, where there is no such
>>implementation (MSVC is no more "the true C compiler" than is, say,
>>"GCC").
>>there are standards, but a standard is neither a reference implementation
>>nor a direct authority figure.
>
> Correct. But I'd have to argue that whatever you have at the end
> must be supported by a standard. After all, that IS one of the main
> strenghts of the approach to just about anything in the USA.
>
> Once things are standartized, you can rely upon it without fear
> that things may DRASTIALLY change tomorrow, which may go as far,
> as putting you out of your business or what have you.
>
> But creating standards in such complex areas as software and
> system architecture and design is nothing less than nightmare.
>
> The overhead is WAY too much, and it takes YEARS for all those
> high tower priests to agree on anything, and even after you do
> agree, it is not even clear you genuinely have some breakthrough.
>
granted...
luckily, MSVC and GCC "mostly" agree...
only that MSVC I suspect is living mostly in C90 / C95 land, whereas GCC is
in C99 land...
so, one can write C which works on both, granted, but it can be observed
that there are many slight differences between their notions of the
standard, and of standard components available in the compiler.
dunno why MS doesn't really seem to bother with C99 though, after all,
someone could have uses for things like complex numbers, ...
>>however, if it is allowed that implementations freely diverge and only
>>remain compatible by consensus, then one can no longer claim that apps are
>>entirely portable, "lowering" it to the level of C (which is often
>>demeaned
>>by supporters as being a low-level and generally unportable language,
>>...).
>
> I do not know how far you can take this claim of "entirely portable",
> and, to tell you the truth, it is now what I am concerned with.
>
> Because I have my own something and I do not want to sweat
> if I want to make it work on at least MAJOR platforms, such as
> Windows and Linux. I am not even looking at system level portability.
> Meaning some low level device driver related code,
> even though that would be REAL nice if that was possible.
>
> I recall numega (softice) guys did some work in that direction.
> But I did not spend that much time looking at it.
> It did generate some stub code. But I was not impressed with
> the overal value of it.
>
ok.
>>so, most of this is a lot more philosophical and political than
>>technological.
>
>>one can actually leverage a very large amount of power from otherwise
>>small
>>details, or waste huge amounts on effort on something which hardly amounts
>>to much of anything.
>
> Yep.
>
>>>>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?
>
>>some want a portable platform, and others want to script an otherwise
>>native-code app.
>
> Well, these are two different aspects.
> Portability and performance/scalability.
>
> If you can achive BOTH of them with the same system,
> that is ideal.
>
yeah...
my stuff mostly works without too much issue on Windows and Linux, and 32
and 64 bit x86.
beyond this?...
dunno...
I had loosely considered other archs, but this was not really a goal I have
much reason to pursue for now...
>>some want high-level scripting (JavaScript and Flash), whereas others want
>>app extension and high performance (such as LLVM).
>
>>in my case, I mostly want high-performance, app-extensions, and scripting.
>
> Well, but scripting IS a portable approach.
>
> So, you are saying you can handle both of these things
> and it is going to reconcile?
>
> Then you have a home run!
> :--}
>
yep.
well, it is as portable as C is portable, more then a matter of the
implementation...
most of the implementation portability is a matter of the codegen, as well
as finding better alternatives than directly producing ASM.
sadly, there are too many tasks where the code needed to be produced is too
low-level to use C or RPNIL, and so much direct ASM is produced...
the issue with then is that these low-level fragments generally need to be
rewritten for each CPU and OS, which is not very nice...
>>the platform is not, however, an icon of universal portability (as is, my
>>project would fail miserably on this front...).
>
> Do not know what you mean.
> But the buzzword, which is my main concern, is portability.
> Then, portability at high performance.
> And THEN only, scalability.
>
Win32 and Win64, and Linux x86 and x86-64.
any further, at the moment, would be a problem.
granted, many of the components could be ported easy enough, but many others
would break.
mostly, the components which would have problems are those directly related
to working with machine code (such as the assembler, linker, and codegen).
actually, I originally intended the codegen to be replacable, but ended up
hacking it onto x86-64 rather than doing a full replacement (as it ended up
as a much more complex component than originally imagined).
some adjustments were made though to potentially later address the
transition to non-x86 systems.
I can't say really...
>>it should be fine though if one does not demand that generics work, or
>>that
>>one has a generally complete class library...
>
> Well, I am perfectly happy with Java in that respect.
> It is complet enough for me.
>
> I do think that languages need to include much larger set
> of things that were developed by competent people.
> So you couold just drag and drop or copy/paste stuff
> or simply link it in, without worrying about things like this is
> all just a cludge or a hack.
>
> Understood, it takes much more effort to support a rich set
> of something. But I generally like to stay away from all sorts
> of "toolkits" or what have you.
>
> It all looks nice on paper, but when you start dealing with it,
> it is either a grand headache or some weird limitations or ALL
> sorts of things.
>
yep.
> I like flexibility and freedom of expression.
>
> It is a bit weird that once I hear "toolkit", I am about to
> freak out. Seems like well, it should make things easier for
> you as you have MORE tools to work with. But either there
> is a bible sized pile of concoctions and I have to spend
> another couple of years learning their weirdness, as they
> put the whole world upside down and I have to learn another
> language on the top of what I already know, which is too much
> as is, or there is such a weird way to do something, that I
> could care less if those "great designers" exist.
>
> I have no time to learn another universe that is totally
> different from the Universe I know already. Go to hell!
>
> I need simplicity.
> I need clarity.
> I need expressive power.
> I need flexibility.
>
> And I do NOT need another pile of crap on my shoulders,
> no matter how grand it looks on the paper.
>
yep.
> I could care less if F# exists.
> The look I took at it just yesterday was enough to put that thing
> on a back burner for at least a year.
>
> I am not interested in chasing some new "fasion"
> and get sucked in into a "revolutionary" "new paradigm".
> Enough of THAT kind of crap.
>
> I saw so many "paradigms" already, that I wish I could unwind
> some of it and make a deal with God to give me my years of
> life back and erase some of that grand bullshit from my record.
>
> In that respect, I am as "conservative" as it gets.
>
> I give a flying dead chicken about "new technologies".
> It is all an old story to me.
>
> I give a funk about some "breaktrough" language.
>
> I want something that will fit nicely into my cockpit
> with all the stuff I already know,
> and is easy enough to INCREASE power, portability and flexibility.
>
> I give a flying dead chicken if generics exist.
>
> And about the LAST thing I care about is those "design patterns".
> Makes me puke.
>
> Sure, if you don't have brains, you need some recepie
> and a "good programming practice", some desing "template"
> for the zombies, so they do not get lost in this giant forest
> of ultimate logic.
>
yes, ok.
>>>>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.
>
>>Lua is basically a simplistic VM for a vaguely Pascal-like language.
>
> Jeez!
> So, we have this Pascal P-Machine biting back?
>
> Is that what I am hearing?
>
> It never died?
>
Pascal never dies...
>>http://en.wikipedia.org/wiki/Lua_%28programming_language%29
>
> Sorry, I can not do any more reading right now.
> Ok, let me see just for a couple of minutes...
>
> Funky stuff, I tellya. I wish I had luxury to afford to get into
> these kinds of things.
>
> :--}
>
ok.
>>it competes some with Python, where Python is much bigger and
>>full-featured,
>>and Lua is a lot smaller and light-weight.
>
> I light light-weight buzzword!
> :--}
>
maybe.
>
>>> 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.
>
>>well, it doesn't seem like nearly so much when one starts out...
>
> I know, I know.
> :--}
>
> Until you get your feet wet!
>
pretty much.
>>it was a whole world of implementing one feature, then the next, ...
>>until years of effort have been eaten up and one has some huge monstrosity
>>of a codebase...
>
> Yep. That is what I peddle:
> "We do not know what information truly is".
>
> Long story.
>
ok.
>>I did not plan this all at the outset, it just sort of turned out this
>>way...
>>it is always, at the moment "well, this looks cool / useful / ..., I think
>>I
>>will implement it".
>>many steps along the way were, as well, missteps and severe
>>miscalculations,
>>but oh well...
>
>
>>the bytecode is some binary representation of a compiled or semi-compiled
>>program.
>>it is closely related to an IL (Intermediate Language), except that an IL
>>may refer to any number of possible representations (such as text and tree
>>structures...), whereas bytecode is usually much more specific: a stream
>>of
>>individual byte-based opcodes which drive an interpreter or a JIT backend.
>
> Well, that much I know. I just did not get into nuts and bolts of it.
>
ok.
>>http://en.wikipedia.org/wiki/Bytecode
>
> Well, we'd have to leave it for another time.
> I am not a revolutionary to bother about things like these
> and have no plans to rewrite Java or anything of that kind.
>
> They say it works? - Fine with me, whatever it is.
> They say BECAUSE of it, things are nearly as slow as interpreters
> are? Well, I doubt it is THAT bad, but yes, I can see your point.
>
> Do you have something better that provides as much portability
> as bytecodes, being the language of VM?
>
> Fine, lemme see it.
>
> That is the extent of me being involved with this stuff.
> Never ever cared about it one way or another.
>
for some parts, I am using JBC.
for other things, I am mostly compiling directly from source and caching the
results...
JBC is not "that bad", since JBC is typically JIT'ed into machine code
anymore.
I may do this eventually as well...
>>>>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?
>
>>because I built it all from the low-levels and work upward...
>
> Gosh. You ARE one of those dedicated few.
> :--}
>
> I am just more interested in information as such.
> I've been through the whole trip, from electronics, theory
> and up.
>
> But from times when I was young enough and heard this thing
> when I was studying at the university:
>
> "Sinusoid does not carry any information"
>
> It was a shock to me.
>
> I could never agree with such a thing.
>
> So I started looking at what IS this thing called information.
> And the more I looked at it, the more it was clear to me,
> we just do not know what information is PERIOD.
> And to this day, we simply have no clue.
>
> Different story altogether.
>
yeah, not as much into electronics...
>>I don't personally seem to either think "top down", nor about the distant
>>future (I suspect my "future" usually tends to be maybe a few days or
>>weeks
>>or so, then it is all in the land of vague uncertainties...)
>
> That's fine. One does not need to take it in fanatical terms.
> Whatever fits your fancy is fine with me.
> As long as you use YOUR brain, and not just copycatting someone
> elses ideas.
>
> I like freshness, no matter how "practical" it is.
> I like something that boggles my mind,
> not because of some additional complexities,
> but because of something radically "efficient",
> radically fresh,
> something that really means something at the end.
>
> I hate crowds of goats, forever incrementally polishing
> someone elses crap and calling it a "progress".
>
> Ugggh.
>
> I stay away from these kinds of people.
> They make me shiver.
>
> It simply numbs my by its deadness and staleness.
>
yes, ok.
>>I just keep going on and stuff happens, although why and how, I don't
>>know...
>
> Cool. I like that kind of stuff.
>
> That means to me you are still innocent.
> You are still not corrupt.
> You are still fresh.
> You are still young.
> You are till that fresh leaf on the tree of life.
> What a joy.
>
> After all, what all this big farse about "languages" and
> any of these "great", "revolutionary" "technologies" is all about.
>
> Well, a dead mosquito fart at the end
> in the grand scheme of things
> of Infinite, all pervading Intelligence.
>
> Just like a wind.
>
> "Dust in the wind...
> All we are is dust in the wind...
>
> Dust in the wind...
> All we are is dust in the wind..."
>
> A VERY good song.
> Beautiful.
>
ok.
>>none the less, I do have opinions, and what stuff tends to happen (at
>>least
>>as far as projects go), tends to somehow / magically go in about the
>>direction I would want it to go,
>
> That IS the very "magic" of it.
> Blessed are thou.
>
>> so no real need to complain too much I guess.
>
>>except that in some areas, very little tends to happen (my code goes
>>forwards and gradually gets more "impressive", but mostly just bigger),
>>but
>>other aspects of life, not so much.
>
> Well, but who knows, may be this IS "THE" Aspect!
> :--}
>
well, there are all these ideals:
marry, get a job, ...
but none have happened...
so, much is as it was years ago, not so ideal.
ok.
ok, ok.
hmm...
>>each part is not nearly so amazing in and of itself...
>
> All I want is SYSTEM.
> Don't even know how to describe it to others.
> But I do know what I am after.
>
yes, ok.
why Python, dunno...
lots of people use it, but personally I don't know the reason...
>>> 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.
>
>>ok.
>
> But. Running totally portable like all these dynamic languages.
> :--}
>
agreed, would be nice.
textual C source can be portable, much more so than binary code.
however, for some things, we don't want C...
for example, I would have my doubts about it comming off a web-page, or at
least if not sandboxed.
sandboxing is something I had also looked into.
>
>>yep.
>
>>it depends a lot on which parts are needed though, since there are
>>annoying
>>dependency issues.
>>if all one needs is an assembler+linker or a GC, that is fairly easy...
>
>>if one wants (in my case), VFS, dynamic types, Class/Instance OO
>>facilities,
>>.... then they also end up needing to include the assembler and the GC.
>
> So what?
>
>>the C compiler needs all of the above.
>>....
>
these are internal dependencies...
ideally, dependencies should be avoidable, but they are not always so...
then again, a compiler makes little sense without having an assembler
around, so I guess it is justified...
>
>>I have some "pseudo-COM" stuff going on (if you have seen JNI, this is a
>>fairly good idea of what I am talking about). some parts are plugged
>>together with function-pointer structs, ...
>
> The thing I saw in these kinds of things is extreme complexity
> on the code writing end.
>
> There does not seem to be a way to make it simple and you have to
> waste years on yet another way of saying it. Too much of plumbing
> work is exposed to program writer. It should be all nicely hidden
> to my taste. It gets under your skin after a while, every time
> they invent something "powerful".
>
> It simply translates into you needing to learn yet another bible
> worth of crap with all those lice, just waiting to get under your
> skin.
>
well, there are some unique powers to these kind of things, admittedly, they
can be a bit ugly...
>
>>> Just don't spread yourself too thin.
>>> I am not sure you have resources to handle so many different aspects.
>
>>hell, I don't think I have the resources either...
>>however, I hesitent of pruning anything either, so this is sort of a
>>dillema...
>
> Well, one more time:
> Get it WELL documented to sufficient enough degree of details.
> Put some pictures in.
>
> You won't be able to handle it all by yourself,
> That much I don't have much doubt about.
>
> You need more hands and brains involved.
>
> And don't be worried that you are not a big gun, and "who cares".
>
> How do you know that no one does?
>
> Just right here, on this very group, there are people sitting
> and wasting away pretty much from what I see, and their minds
> are pretty much idling, just looking into someone elses pockets.
>
> What a royal waste!
>
> And that is NOT the end of the world.
> You never know what might appear out of the blue.
>
> You may not even know what you are working on and why.
> Just TRUST.
> Trust yourself in the MOST minute manifestation,
> and do not worry about that big world. It is not as big as it looks.
>
yes, ok.
I could write more, but these posts are getting long, and I have stuff
needing to do.
>
>>in the LLVM case, most of the headers and source files are too small...
>
> I do like the idea of the include files.
> It is just another layer that does some useful things to you.
> I asked the Java experts why is it they have gotten away with
> include files. Do not recall hearing anything that made any kind
> of sense to me.
>
well, getting away from them does allow optimizing the compiler some, since
this is one of the biggie issues which slows down C compilation:
processing the huge piles of stuff pulled in by headers...
>>so, maybe one opens a file to find it contains maybe 100 lines, 15-20 are
>>maybe header inclusions, and or a single class declaration, or maybe a few
>>methods. trying to follow the code is difficult as lots of time goes into
>>mostly opening and closing text editor windows...
>
>>I think it may be though a result of people using Eclipse as an IDE, and
>>Eclipse likes doing things this way?...
>
> Well, not sure about this one.
>
ok.
agreed.
I like to divide things up similarly if possible.
>
>>well, I think some amount of the Windows NT line was based on grabbing up
>>a
>>bunch of source from BSD.
>
>>I found it mildly ammusing to have been looking at one of their SDKs, and
>>noting a copy of both the zlib and libjpeg liscense agreements...
>
> I just can not see why people are so much obscessed with money.
> Why do they think it is an ULTIMATE measure of ANYTHING?
>
> What is this "fear of survival" as I call it?
>
> I could never see the point of it, even though I saw ALL sorts of things.
> And I can comprehend how "horrible" it looks,
> if you can not "survive".
>
> So people resourt to licking the rear end of those "powerful",
> just be allowed to be in the herd.
>
> Brrrr.
>
hmm... dunno...
well, I really don't know how this particular issue can be addressed...
usually, the one doing the selling is the one getting the money, but I guess
it is the mystery of what of the people who do the actual work...
hmm...
Bo Persson
And it also needs a hardware assist to run Java properly on the
mainframes. :-)
http://www-03.ibm.com/systems/z/advantages/zaap/index.html
Using the "implementation defined" loopholes in the C++ standard, C++
runs natively on these machines.
Bo Persson
BGB / cr88192
can't say I know much about IBM's technology...
>
> Using the "implementation defined" loopholes in the C++ standard, C++ runs
> natively on these machines.
>
C and C++ run natively on lots of machines, likely due, in part, to the
language being "flexible" in order to bend to some extent to whatever HW it
is running on, whereas the JVM is very specific and assumes that all code
should run "about the same".
for example, one may note when implementing a JIT for JBC, there are a few
edge cases where the bytecode assumes 32-bit memory spots (for both the
locals and the stack), and it requires a bit of ugly hackery to work around
these (for example, if JIT'ing on a 64-bit processor, or converting the
bytecode into an SSA-like form, ...).
in this case, it would have been better had the bytecode been working with
abstract "stack items".
well, that and the lack of type declaration for local variables, ... (one
has to instead figure out the type of a variable via the operations applied
to it, ...).
then again, it is far less nasty than x86 would be, and still much simpler
than MSIL (even if MSIL is cleaner in a few ways).
>
>
> Bo Persson
>
>
Richard
ta...@mongo.net (tanix) spake the secret code
<hh3at8$j6s$1...@news.eternal-september.org> thusly:
>I just hate [...]
Yeah, we got that.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
tanix
>[Please do not mail me a copy of your followup]
>
>ta...@mongo.net (tanix) spake the secret code
><hh3at8$j6s$1...@news.eternal-september.org> thusly:
>
>>I just hate [...]
>
>Yeah, we got that.
Who is WE?
:--}
You are pretty creative at taking it to the levels beyond obscene,
aren't ya?
Jerry Coffin
says...
[ ... ]
> Then, being the rotten thieves they are, ms took the central
> ideas of Java and all the associated development work, then
> repackaged it and placed a sticker "Microsoft copyrighted
> and patented" on it.
What complete nonsense. First of all, Java hardly had a single
original idea to start with -- it was little more than weird
imitation of Smalltalk implemented using a weird imitation of Pascal
P-code (by somebody who apparently understood P-code a lot better
than Smalltalk).
> They were thiefs from the day one, raping and pillaging,
> and they remain theiefs to this day and for any forceable future.
>
> They were born on intellectual theft by taking the work of
> Gary Kildall, the author of CP/M, buy purchasing some rip off artists,
> who reverse egineered the CP/M operating system, and that was their
> first contract with IBM, as a result of which these "lewser" fools,
> who could only create a sickness called M-Basic and nothing more
> than that, became what they are today.
Still more nonsense. Microsoft had been around for quite a while
before MS-DOS came along. At the time, their assemblers, compilers,
etc., were quite well respected.
MS-DOS 1.0 clearly derived from CP/M, though there's no evidence that
any code was actually copied. Then again, CP/M just as clearly
derived from DEC RT/11, though there's no evidence that any code was
copied in that case either.
> This monster was born on Gary's blood.
>
> I bet they did not even say thank you to him and he did not get
> a penny in return, even though he, single handedly, was the
> creator of the destop computer as far as its very heart, an O/S
> goes.
More nonsense. In reality, MS BASIC acted as the O/S of _far_ more
personal computers than CP/M ever did. Just for an obvious example,
the Commodore 64 alone almost certainly outsold all CP/M machines put
together -- and the Commodore 64 was only one of many machines that
booted into MS-BASIC and ran it essentially full-time.
> To this day, everybody is using BIOS, which was Garys brilliant
> insight.
The nonsense continues unabated. Gary may have invented the name (I'm
not sure), but the idea predated his involvement by many years --
just for example, MULTICS had a module called the GIM (GIOC Interface
Module) that talked to the GIOC (Generalized I/O Controller). See,
for example _Communications and Input/Output Switching in a Multiplex
Computing System_ by Ossamma, Mikus and Dunten, which discusses the
General I/O Controller (GIOC) Interface Module (GIM).
> The demise of Java is probably the biggest tragedy in the sw world.
> By FAR, thanks to these servants of evil.
Despite John Harrop's trolling, neither C++ nor Java is anywhere
close to dead. In any case, as Alexander Stepanov's commented on
Java:
I spent several months programming in Java. Contrary to
its authors prediction, it did not grow on me. I did not
find any new insights - for the first time in my life
programming in a new language did not bring me new
insights. [ ... ] it might be a profitable thing for all
your readers to learn Java, but it has no intellectual
value whatsoever.
[http://www.stlport.org/resources/StepanovUSA.html]
While I think he may have overstated the situation a _little_, I'm
not even sure of that, and in any case it's only a little.
--
Later,
Jerry.
Balog Pal
Tanix filled the group with nonsense for the last few months, you'd better
PLONK ahead... Resistance is futile.
> More nonsense. In reality, MS BASIC acted as the O/S of _far_ more
> personal computers than CP/M ever did. Just for an obvious example,
> the Commodore 64 alone almost certainly outsold all CP/M machines put
> together -- and the Commodore 64 was only one of many machines that
> booted into MS-BASIC and ran it essentially full-time.
Fulltime ;) Was it really used for anything beyond LOAD, RUN, SYS? C64 had
a fine build, you could unmap its ROMs or plug in cartridges to shadow.
Everyone I saw loaded something and executed that instead of the built-in
basic, and whoever actually wanted BASIC, used Simon's.
Certainly the original wasn't worth or better compared to the other machines
of the era.
> Despite John Harrop's trolling, neither C++ nor Java is anywhere
> close to dead. In any case, as Alexander Stepanov's commented on
> Java:
> I spent several months programming in Java. Contrary to
> its authors prediction, it did not grow on me. I did not
> find any new insights - for the first time in my life
> programming in a new language did not bring me new
> insights. [ ... ] it might be a profitable thing for all
> your readers to learn Java, but it has no intellectual
> value whatsoever.
>
> [http://www.stlport.org/resources/StepanovUSA.html]
>
> While I think he may have overstated the situation a _little_, I'm
> not even sure of that, and in any case it's only a little.
Overstated? IME Java has an extreme mind-*narrowing* effect, especially if
used as the only thing. So its "intellectual value", if I get it right
from the quote, is way in the negatives.
Certainly in most situations a language/system is used for a different
motivation and goals. And many practicioners are actually glad to have a
single way and no options to think -- with some luck it fits the purpose, or
there is no one responsible for doing good anyway.
>
> --
> Later,
> Jerry.
tanix
>In article <hh31vk$82i$1...@news.eternal-september.org>, ta...@mongo.net
>says...
>
>[ ... ]
>
>> Then, being the rotten thieves they are, ms took the central
>> ideas of Java and all the associated development work, then
>> repackaged it and placed a sticker "Microsoft copyrighted
>> and patented" on it.
>What complete nonsense.
You mean every single word of it?
:--}
> First of all, Java hardly had a single original idea to start with
I simply have to strip the rest of your profound wisdom.
Because it is so utterly uninteresting.
To make such claims, you have to be either utterly "out of this word",
or simply corrupt, to the bone and marrow.
All those jacks that claim that java was not "intellectually
challenging enough" are just bluffing.
First of all, when you work on something, would you like it to
be as hard as impossible, or would you rather have some tools
that make your job EASY?
:--}
Are you masochists?
Those stoopid cockpits, stuffed with ALL sorts of garbage,
being driven by the complex of inferiority, forever need
"intellectually challenging" things, so it make them look
"superior". Simple as that.
Java was SPECIFICALLY designed in such a way as to avoid the
unnecessary complexities that do not give you anything of a
real value beyond headaches.
When I do some development work, the first thing I want is
for it to be easy and simple, while, at the same time,
providing me power and flexibility of a static languagages.
Why static languages? First of all, performance and ability
to do most advanced things related to multithreading,
synchronization, events, asynchronous processing and things
like that.
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP,
Jerry Coffin
[ ... ]
> Tanix filled the group with nonsense for the last few months, you'd
> better PLONK ahead... Resistance is futile.
Probably.
[ ... MS BASIC on the C64 ]
> Certainly the original wasn't worth or better compared to the other
> machines of the era.
No, but it wasn't a lot worse either -- and most of the other
machines at the time came with and used Microsoft BASIC interpreters
as well (TRS-80, Atari, Amiga, Mac, etc.)
[ ... ]
> Overstated? IME Java has an extreme mind-*narrowing* effect,
> especially if used as the only thing. So its "intellectual
> value", if I get it right from the quote, is way in the negatives.
You could be right -- I neither used, nor associated with people
who've used, Java enough to really say with any certainty about that.
One apparent intent of Java was to "level the playing field", by
allowing average programmers to be reasonably productive. As a
result, the difference between an average programmer and a superb
programmer should be much smaller than with many other languages.
To an extent it succeeds in this respect -- the difference between
average and superb programmers _is_ much smaller with Java than with
C++. Unfortunately, it does this in the opposite of the intended
direction: rather than improving the productivity of average
programmers, it limits the productivity of the best.
It is true that Microsoft's .NET is generally quite similar to Java,
including this respect.
Personally, I suspect this is largely intentional. Sun and Microsoft
are both very large companies who depend largely on hiring a huge
number of programmers. In fact, the number is so large that neither
can even hope that their overall skill level is much above average.
Programming environments that favor a large number of average
programmers instead of a few really superb ones are greatly to the
advantage of these companies. They already have lots of average
programmers, and hire more all the time.
C++ favors excellence over numbers -- so a small team (even a single
programmer in his spare time) stands a much better chance of
producing something that competes with (or even clearly beats) what
their army of average programmers can produce. For a company like Sun
or Microsoft, preventing that is clearly a positive thing. Yes, they
do have a few really superb programmers of their own who can be
called upon in an emergency -- but preventing such emergencies is
better management.
--
Later,
Jerry.