integration into java
Helmut
However it is also possible to target the java virtual machine.
Thinking more about this option, a seemless integration into java
would be possible (i.e. call java from Eiffel and Eiffel from java). A
good example of this type of "seemless" integration is scala.
Is that an interesting option?
ZuLuuuuuu
I don't have a professional opinion but it seems like CLR is becoming
more popular (and cross-platform because of Mono) and looks like the
way to go on Windows (and maybe on Gnome?) in the future. You think
about targeting a virtual machine instead of compiling to the native
code for Tecomp?
Oh and there is also coming Parrot Virtual Machine as the third
popular option, just to cheer up the discussion :)
Cesar Rabak
> Traditionally Eiffel compiles to C.
>
> However it is also possible to target the java virtual machine.
> Thinking more about this option, a seemless integration into java
> would be possible (i.e. call java from Eiffel and Eiffel from java).
Humm... 'calling' meaning what exactly? Java is single inheritance
without support for DbC. How would this calling be done in either
direction?
For available similar functionality in both languages/environments which
class hierarchies' one would be chosen?
Helmut
> Helmut escreveu:
>
> > Traditionally Eiffel compiles to C.
>
> > However it is also possible to target the java virtual machine.
> > Thinking more about this option, a seemless integration into java
> > would be possible (i.e. call java from Eiffel and Eiffel from java).
>
> Humm... 'calling' meaning what exactly? Java is single inheritance
> without support for DbC. How would this calling be done in either
> direction?
>
Calling java from Eiffel should not present obstacles, since single
inheritance and interface inheritance have 1:1 counterparts in Eiffel.
The other way round needs some adaption. Multiple inheritance in
Eiffel has to be implemented with java interfaces. Renaming require
some sort of proxies in case of naming conflicts. I have not yet done
a 100% analysis. But I don't expect showstoppers.
> For available similar functionality in both languages/environments which
> class hierarchies' one would be chosen?
That should be decided by the user. Java packages could be treated
like clusters. The Eiffel compiler would have to parse the class files
(not the code, but the structure) to generate the Eiffel counterpart
in order to check calls from other Eiffel classes and validate them.
If the user is required to generate "wrapper classes" (like it is done
currently for C-libraries), I don't expect good acceptance.
Helmut
> On Dec 6, 5:34 pm, Helmut <helmut.bra...@gmx.net> wrote:
>
> > Traditionally Eiffel compiles to C.
>
> > However it is also possible to target the java virtual machine.
> > Thinking more about this option, a seemless integration into java
> > would be possible (i.e. call java from Eiffel and Eiffel from java). A
> > good example of this type of "seemless" integration is scala.
>
> > Is that an interesting option?
>
> I don't have a professional opinion but it seems like CLR is becoming
> more popular (and cross-platform because of Mono) and looks like the
> way to go on Windows (and maybe on Gnome?) in the future.
I am not sure, whether Mono is really a good option for unix
platforms. In my opinion CLR is windows only and not (yet?) cross
platform. The java virtual machine is definitely cross platform and
because of the hotspot jitter has a good runtime performance compared
to code compiled to native.
>You think
> about targeting a virtual machine instead of compiling to the native
> code for Tecomp?
I do currently the planning for the backend. The options are
a) compile to C
b) use tecomp as a frontend for gcc
c) use tecomp as a frontend for llvm
d) generate class files (i.e. target the java virtual machine)
There are 2 questions:
1. Which options are reasonable (i.e. have a good chance to find wide
acceptance, maybe also some other options which are not listed above)
2. Which option shall be tackled first (some form of native
compilation shall be available, therefore one of a, b or c might be
mandatory, but not necessarly as the first ones. There are already
compilers which offer compilation to native like SmartEiffel and
EiffelStudio)
>
> Oh and there is also coming Parrot Virtual Machine as the third
> popular option, just to cheer up the discussion :)
I have heard of the Parrot Virtual Machine. Is it well maintained and
of good quality?
ZuLuuuuuu
> I am not sure, whether Mono is really a good option for unix
> platforms. In my opinion CLR is windows only and not (yet?) cross
> platform. The java virtual machine is definitely cross platform and
> because of the hotspot jitter has a good runtime performance compared
> to code compiled to native.
Again I don't have any experience on coding compilers so you know the
technical advantages/disadvantages better than me :)
I was actually pretty distant to Mono project because of .Net being a
Microsoft product. But it is becoming a reality that Mono is becoming
one of the main development environments on GNOME which is mostly
because Mono team is being lead by the very same guy who started the
GNOME project and the team is sponsored by Novell. So I start
accepting the fact that it is becoming a major player on Linux (and I
guess they also released Mono on Mac and iPhone) even if I like or
don't like .Net.
> I do currently the planning for the backend. The options are
>
> a) compile to C
>
> b) use tecomp as a frontend for gcc
>
> c) use tecomp as a frontend for llvm
>
> d) generate class files (i.e. target the java virtual machine)
>
As a superficial and not-strictly-unix programmer, all I would want is
to be able to compile my program into an .exe so that everyone can
install and use it easily. So all of the first 3 options and CLR
option would be fine with me. Java is not that scary either but having
a native, single .exe file is always preferable when it comes to
hobbyist programmers :)
Maybe you can prepare a poll (with multiple choice) on Tecomp site for
this subject?
> I have heard of the Parrot Virtual Machine. Is it well maintained and
> of good quality?
I have no idea whether it is of good quality. It is mostly being made
by Perl people, does not have as big development team as Java or Mono,
definitely, but being maintained actively. As you might know it was
for Perl 6 in the beginning but become targeted more generic
afterwards. It is more like for dynamic languages such as Python or
Ruby. It is a rather young project so the other VMs we talked about
are probably better options if you target serious programmers with
serious projects.
ccwu
> On Dec 6, 10:49 am, ZuLuuuuuu <canol.go...@gmail.com> wrote:
>
> I do currently the planning for the backend. The options are
>
> a) compile to C
>
> b) use tecomp as a frontend for gcc
>
> c) use tecomp as a frontend for llvm
>
> d) generate class files (i.e. target the java virtual machine)
>
> There are 2 questions:
>
> 1. Which options are reasonable (i.e. have a good chance to find wide
> acceptance, maybe also some other options which are not listed above)
>
> 2. Which option shall be tackled first (some form of native
> compilation shall be available, therefore one of a, b or c might be
> mandatory, but not necessarly as the first ones. There are already
> compilers which offer compilation to native like SmartEiffel and
> EiffelStudio)
>
I'd say targeting JVM would be great for those who want to do server
side web development.
Cesar Rabak
> On Dec 6, 10:58 am, Cesar Rabak <csra...@yahoo.com.br> wrote:
>> Helmut escreveu:
>>
>>> Traditionally Eiffel compiles to C.
>>> However it is also possible to target the java virtual machine.
>>> Thinking more about this option, a seemless integration into java
>>> would be possible (i.e. call java from Eiffel and Eiffel from java).
>> Humm... 'calling' meaning what exactly? Java is single inheritance
>> without support for DbC. How would this calling be done in either
>> direction?
>>
>
> Calling java from Eiffel should not present obstacles, since single
> inheritance and interface inheritance have 1:1 counterparts in Eiffel.
>
Technically feasible, but see comments below.
> The other way round needs some adaption. Multiple inheritance in
> Eiffel has to be implemented with java interfaces. Renaming require
> some sort of proxies in case of naming conflicts. I have not yet done
> a 100% analysis. But I don't expect showstoppers.
>
I wasn't thinking of showstopers but rather of the ROI of this effort.
>
>> For available similar functionality in both languages/environments which
>> class hierarchies' one would be chosen?
>
>
> That should be decided by the user. Java packages could be treated
> like clusters. The Eiffel compiler would have to parse the class files
> (not the code, but the structure) to generate the Eiffel counterpart
> in order to check calls from other Eiffel classes and validate them.
> If the user is required to generate "wrapper classes" (like it is done
> currently for C-libraries), I don't expect good acceptance.
>
I'm afraid this decision postponed to the user (given it will require
the development of solutions for both ways) plus the "paradox of choice"
(http://en.wikipedia.org/wiki/The_Paradox_of_Choice), would do more harm
than good.
A comment about this kind of efforts: more often than not these
solutions tackle the technical issues and leave by themselves the hell
of documentation. E.g., a rich set of classes in Java are available in
Eiffel but the docs are in Javadoc format (for Java syntax) all examples
are in Java, so the programmers have to have to be very keen in both
languages to attain their objectives.
Secondly, all this effort will bring to Tecomp the availability of a lot
of 'competive' classes, but the ones that would make the developer more
productive will still be lacking, like connection to databases (for
doing CRUD apps) and access to a good report generator, for example.
my 0.0199999...
--
Cesar Rabak
llothar
> I am not sure, whether Mono is really a good option for unix
> platforms. In my opinion CLR is windows only and not (yet?) cross
I'm with you on this one. And i predict it never will as the
mono community does not have the financial manpower to build a
high quality VM.
> platform. The java virtual machine is definitely cross platform and
> because of the hotspot jitter has a good runtime performance compared
> to code compiled to native.
Sorry but java is slow, thats the reason why i stick to Eiffel.
I'm not talking about about micro benches but application development.
With DbC there is already a huge speed problem you don't want to add
an additional factor for reasons internal to the compiler vendor.
How can you avoid the performance problems created for example by
the dynamic type casts which are polluting the java environment?
I could see a lot of problems performance wise.
With Java VM and with CLR. They are optimized for there special use
case
but for example the benefits of the whole system analysis is just
wasted.
> a) compile to C
>
> b) use tecomp as a frontend for gcc
>
> c) use tecomp as a frontend for llvm
>
> d) generate class files (i.e. target the java virtual machine)
Well i'm also currently working on my Eiffel compiler again
(thats why i'm in such a bitter angry mode with the ISE/Ecma guys).
And for me there seems to be only one option.
e) using C99 as backend language
In fact is that the people don't give a fuck what the backend is. They
are here (or better they deciced with there feets and are not here
anymore) to solve problems. Language incest is just the for university
teaching guys.
The only thing you can win with going Java/CLR is the (strange non
Eiffel style)
access to libraries. But why should people not go Java if this is the
main point?
If you don't wrap the libraries on a high level then you don't have
any advantage
of the Eiffel language and methodolgy. You are starting to write Java
Programs
in Eiffel and this just feels worse.
The reasons why i'm compiling to ANSI-C99
(with extensions based on the choosen backend compiler):
a) Eiffels type system and methodolgy allow you to
generate amazingly fast and native programs.
b) It is a high level level language.
c) It is an imperative procedural oo language, which is what most of
the people
learned in the last two decades. Raising functional languages might be
better
but i don't get warm with them.
There is currently no other language on the market this combines
all three points as perfectly as SmallEiffel did (and because
SmallEiffel
is running into limits i have to rewrite it).
C, Objective-C, D, C#, Go, Java, Modula3, Delphi all are lacking
something
(well Modula3 is closest but it is much more dead then Eiffel).
I voted for pure C99 for the following reasons:
- there will always be a C99 compiler around for my whole lifetime.
- gcc is a total large and documented beast nobody really wants to
hack into
it if they are not doing this on a permanent job.
It is complex and currently does not offer you relevant benefits
over C generation.
- If you go windows there is no gcc available. Sorry but this MingW
is
not a useable option here
- LLVM is not good supported on windows. Building it does not work out
of
the box - which says a lot how they look at the most important
operating
system platform.
It is complex and currently does not offer you relevant benefits
over C generation.
- OpenMP is a C based standard for parallel compilation.
Okay i have to explain this. One of the reasons i hate on the eiffel
guys is there
inability to accept the fundamental issue that mulitthreading is
important, much more
important then DbC and Multiple Inheritance, Conforming Type Rules
and all the other
theoretical language design shit together. So if you want to be a
future candidate
you have to obey to this demand. Thats one more reason why i'm
writing my own compiler.
The best base infrastructure for multithreading is C source code at
the moment.
Oh and yes, with an eye to the multithreading problem:
Go seems to be really interesting. With C99 as a backend it is not
that difficult to use
Go as the backend language in the future if Google is paying a lot
money on the
development of its runtime and language. Thinking about thousands of
lightwight threads
which don't even have contiguous stack areas is giving me my geek
organsm. But for the
next few years Go is not useable while C99 is.
Friedrich Dominicus
> On 6 Dez., 21:23, Helmut <helmut.bra...@gmx.net> wrote:
>
>> I am not sure, whether Mono is really a good option for unix
>> platforms. In my opinion CLR is windows only and not (yet?) cross
>
> I'm with you on this one. And i predict it never will as the
> mono community does not have the financial manpower to build a
> high quality VM.
Well I can't tell but it seems to work our pretty well for a lot of
areas. I don't know how good either .NET or Mono is but I saw an IDE for
developing games and it was all .NET and I did not believe how nice it
worked. I was more than impressed. However Mono is a very hackerish
solution absolutly underdocumented and it needs at least 3-6 months to
get into it. This code generation on the fly the tons of threads and
injectin code into running programs, heavens help it looks terrible and
I guess it's quite fragile.
>
> Sorry but java is slow, thats the reason why i stick to Eiffel.
I really would be suprised if that is really that worse these times.
>
> e) using C99 as backend language
>
> In fact is that the people don't give a fuck what the backend is. They
> are here (or better they deciced with there feets and are not here
> anymore) to solve problems. Language incest is just the for university
> teaching guys.
>
> The only thing you can win with going Java/CLR is the (strange non
> Eiffel style)
> access to libraries. But why should people not go Java if this is the
> main point?
Hm I just can see a lot of languages now targeting either the CLR or
Java VM. And the results do not look that worse.
>
> The reasons why i'm compiling to ANSI-C99
> (with extensions based on the choosen backend compiler):
>
> a) Eiffels type system and methodolgy allow you to
> generate amazingly fast and native programs.
Hm, isn't that true for Ocaml e.g also?
>
> b) It is a high level level language.
Ocaml, Haskell, Objective-C, Smalltalk?, Common Lisp, you name them.
>
> c) It is an imperative procedural oo language, which is what most of
> the people
> learned in the last two decades. Raising functional languages might be
> better
> but i don't get warm with them.
Yes that is a problem, however we do have the C-Q-Separation so we are
prepared for side-effect free functions....
>
> There is currently no other language on the market this combines
> all three points as perfectly as SmallEiffel did (and because
> SmallEiffel
> is running into limits i have to rewrite it).
>
> C, Objective-C, D, C#, Go, Java, Modula3, Delphi all are lacking
> something
> (well Modula3 is closest but it is much more dead then Eiffel).
If they can write a whole OS in Objective-C, than I can not see what's
that wrong with it.
> - gcc is a total large and documented beast nobody really wants to
> hack into
gcc documented. I'm sorry, where is the documentation about gcc? And
getting into gcc is surly not for the faint of heart....
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
llothar
> areas. I don't know how good either .NET or Mono is but I saw an IDE for
> developing games and it was all .NET and I did not believe how nice it
> worked.
Yes. I have no doubt that .NET might be a good future candidate.
At the moment my problem is that 3.5 Runtime is 350MByte and if you
want to distribute this with your App you are doomed in the mass
market.
We will see if they get the runtime problem under control. But my
critics
were about the Mono platform. Because i know that Helmut is working on
Unix.
> I really would be suprised if that is really that worse these times.
Well i think yes. It is a magnitude 10x difference compared to boosted
Smalleiffel. And the reason why this is a problem: The CPU speed is
on
its speed limit - a physical problem that i think will not be changed
in the future. CPU Cores are at 3 GHz for 5 years now - and the
optimizations are mostly done so i don't expect anything there except
multicores.
But the required functionality and data size is still growing and
there
i don't see an end. When multithreading is so complicated or even
impossible for many problems. The only way that buys you a few more
years is better optimized code.
And the ultra slow implementation of generics in Java shows me that
i don't expect so much from them either. It's there safety aspect but
i can just add -boost to the command line and get rid of it.
> > a) Eiffels type system and methodolgy allow you to
> > generate amazingly fast and native programs.
>
> Hm, isn't that true for Ocaml e.g also?
Yes, but every statement a "let" sorry i hate this.
> > b) It is a high level level language.
>
> Ocaml, Haskell, Objective-C, Smalltalk?, Common Lisp, you name them.
Yeah yeah, Haskell is even more functional then Ocaml.
Smalltalk is slow and dead, Common Lisp is not slow and compared to
Eiffel full of living but it's also not for me. My brain don't get
over
the lack of syntactical structuring. I simply do not believe that you
can read Lisp as fast as Eiffel code.
> Yes that is a problem, however we do have the C-Q-Separation so we are
> prepared for side-effect free functions....
Hmm, C-Q is IMHO more a problem then a solution. The problem with C-Q
comes with multithreading and that you require a result state
variable
in an object. You can put a mutex around your command but then when
the control flow returns to the client another client can kill your
results before you can read it. So you have to put the synchronization
somewhere out of the object into the client and not the supplier of
the command. Very bad design if you have to write your code like this
object.lock
object.do_the_action
if object.last_status then be_happy end
object.unlock
Add the terrible exception handling style in Eiffel. It gets much much
worse to write this correctly.
For me the solution was to get rid of the C-Q style programming many
years ago - the other solution would be allowing multiple return
values,
but this is something that i guess will never come to Eiffel for
various reasons. Maybe i add it to my compiler i don't know - buf for
sure
i will implement a "try-catch-finally" exception handling instead of
the rescue clause.
> If they can write a whole OS in Objective-C, than I can not see what's
> that wrong with it.
Yes Object-C in it's 3.0 version with Garbage Collector and
Grand Central Dispatch is very very good - but it's only on MacOSX.
There is a new FOSS project but i haven't checked it out yet. And
again a tiny few person project.