Re: kilyx

On 2007-02-09, Brian Moelk <bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Marco van de Voort wrote:
Do they have to mimic an existing library and designer etc ? 10:1 that they
built on top of some java stuff, which doesn't make sense for Delphi/FPC.

Why doesn't it make sense for FPC?

We already have the LCL, and a huge installed base in VCL (which LCL is
somewhat compatible with, for good reason)

Many languages hook GUI layers on top that aren't built in their native
tongue.

Usually the non critical scripting languages. How many C++ programs base
themselves on Swing?

In a way that's exactly what the VCL does: it wraps Win32 which is written
in C/C++.

But has a procedural interface which matches Pascal as well as C/C++. (since
even C/C++ need modification due to the requirement to support stdcall).

IOW, the win32 API was designed to be lowlevel accessable to a procedural
languages. Swing/AWT is not. It is an OOP Java implementation, and to access
it at all, you need to be Java, or compile to Java, or use JNI. (comparable
to COM)

I think it's very possible to side-step the whole "building your own GUI
designer" issue and support something like XUL, which is exactly what I
advocated.

XUL is dog slow, overly complex etc. The requirements for XUL (having an
infinitely configurable application GUI wise, read: Mozilla) are not
universal. It is possible that making an application that makes good/safe
use of XUL is more complex by a magnitude.

In regards to XUL, I suspect that some Java/C++ guys would be interested
in building designers as well...thus pascal guys don't have to do
*everything*.

I'm not interested in XUL, Swing, or other way too highlevel widget sets. I
already have doubts about QT.

Keep in mind that the focus of FPC is to write applications alike Delphi,
while e.g. Python GUI development seems to revolve about making as short and
simple possible controlapplet like programs for Linux distro's. (and they
change language every 2 years. Perl->Python-> Ruby)

So the main focus for FPC would be to build a suitable
IDE to write/debug code with.

We already have that.

These IDE frameworks already have tons of hooks for syntax highlighting,
intellisense/code insight, debugging, etc.

We already have that too, and the latter part is false. They don't have
debugging, but use GDB, just like we do.

This means you have to provide something that the others don't have.
Integrating into some framework of the competitors makes it awfully hard to
make a sustainable long term difference.

I disagree. There are those that are innovating on top of an IDE core
and do have distinctive products.

Sure. I don't say that is not possible, but not for a company the size of
Borland/CG.

They are merely frameworks and JBuilder 2007 is evidence that CodeGear
believes that this is a viable strategy.

IMO, JBuilder 2007 has other issues like pricing and feature set that
might prevent it from being successful, but I do agree with CodeGear
that it's a viable strategy.

The Java products favour a Java solution, and also IBM created a huge buzz
around Eclipse in the Java scene (and NetBeans is trying to do the same
for Sun). But that is not universal.

As viable as the other two, with the same problems.

Yes, but you might perceive it as less "bloated" and faster than
Eclipse. FWIW, I consider BDS somewhat bloated. :)

It's less the bloat. As you say BDS is bloated too, and I have seen
Lazarus/FPC use 1.5 GB to link a 40MB file. The trouble is more fitness for
the purpose. See the remarks about "integration".

Lazarus and Free Pascal existed before Eclipse afaik :-)

Which is yet another reason to question if Lazarus can get a critical
mass without corporate sponsorship to compete...

Lazarus/FPC already has a critical mass. Moreover, they are all volunteers,
and you can't simply reassign them. They'll be as reluctant as I am. What
you call "Not invented here", they'll call "throwing away the work of years
based on a marketing fad".

Actually George Birbilis has suggested stuff similar to you on the Lazarus
maillist, resulting in huge discussions, but had the same problem, "no time"
or "no skill" to backup the claims.

So if you want to create a second locus of activity around any of the
projects you name, you won't get away with talk, raising awareness, or
similar trivial advocacy. You really need to show something. Proof of
concept, or perfect, show something.

I think it would loose an enormous amount of critical mass, simply because
the implementation language would change to a language a certain percent of
the developers aren't as experienced in (or not at all)

Disagree. What happens is that there are more Java/C++/.NET developers
working on the IDE core, this means that overall, for IDE services it's
higher.

They said the same thing about the debugger and the linker, we are now
in the process of replacing these too. Superficial feature comparison does
no justice to the complexity of adapting something like that.

Having features and using them is a totally different thing. One might end
up spending more time trailing these "fast" C++/.NET/Java developers and
every new feature that requires changes to build system, system architecture
etc, and remain far from a stable IDE forever.

And the need for developers working on IDE stuff is less; IOW,
you can leverage existing work.

In theory.

I do agree that there will be less Pascal developers interested in
building IDE integration in Java/C++, but in the end it's all what works.

Correct. And Lazarus is there and working. None of the KDevelop/Eclipse
projects made it above the radar (and at least for KDevelop such initiatives
existed)

If a good IDE emerges, *more* people will use it. Most developers are
looking for good tools, give them good tools and in the end, more people
will be interested in moving things forward, not less.

How are you so _sure_ these are actually any good?
.

Relevant Pages

  • Re: Java-Rauschen (war: Re: Getter & Setter)
    ... also stimmst du mir zu dass Java ohne IDE schlecht nutzbar ist? ... Nun mal abgesehen dass man APIs nicht mehr lernt, sondern sich einfach auf Codecompletion verlässt und dabei Hilfsklassen vollkommen ignoriert, ... Oder wenn der Grad des Rauschen so unterschiedlich ist? ...
    (de.comp.lang.java)
  • Re: Java-Rauschen (war: Re: Getter & Setter)
    ... welche Perspektive hatten denn die Leute, die Java entworfen haben? ... Aber gehe ich recht in der Annahme dass du dann sagst, dass Java erst durch eine IDE "richtig gut" wird?... ... Ich sehe es allerdings für eine textbasierte Programmiersprache als Nachteil an, wenn sie aufgrund der "Umständlichkeit" der Sprache ohne IDE kaum nutzbar ist. ...
    (de.comp.lang.java)
  • Java-Rauschen (war: Re: Getter & Setter)
    ... aber bei HTML ist nicht so sehr der Source als viel mehr das was im Browser angezeigt wird wichtig. ... Ich finde, eine interessantere Frage ist, warum man ueberhaupt gegen eine IDE ist. ... Nur hängt das mit einer bestimmten Menge an Code zusammen und die erreicht man bei Java schneller als bei zum Beispiel Ruby. ... Ich sehe es allerdings für eine textbasierte Programmiersprache als Nachteil an, wenn sie aufgrund der "Umständlichkeit" der Sprache ohne IDE kaum nutzbar ist. ...
    (de.comp.lang.java)
  • Re: Codegear in the news
    ... FPC is unbelievable and has features Delphi developers had on their wishlist for years. ... Lazarus (GUI IDE) is still lagging behind, but the development pace is something Borland/CodeGear can only dream of. ... Although this is a Delphi forum, try using Java 6 and doing some GUI development with it on Linux/Unix/Windows. ...
    (borland.public.delphi.non-technical)
  • Re: Java-Rauschen (war: Re: Getter & Setter)
    ... Programmieren meinst, dass die IDE doch eh die ganze Zeit läuft, dann ... Eclipse ... Wenn du jetzt sagen würdest ich bin Java gegenüber Voreingenommen ... Groovy Java *braucht*, stört dich hingegen nicht. ...
    (de.comp.lang.java)