Re: kilyx

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? Many languages hook GUI layers on
top that aren't built in their native tongue. In a way that's exactly
what the VCL does: it wraps Win32 which is written in C/C++.

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.

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*. So the main focus for FPC would be to build a suitable
IDE to write/debug code with. These IDE frameworks already have tons of
hooks for syntax highlighting, intellisense/code insight, debugging, etc.

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. 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.

In the case of Eclipse, that would give us a bloated Java
based IDE, instead of the native, fast, IDE we have now. In
the case of VS.NET that would have given us a Microsoft only
IDE. So much for a cross platform strategy.
NetBeans is also a viable option.

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. :)

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...

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. And the need for developers working on IDE stuff is less; IOW,
you can leverage existing work.

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.

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.

--
Brian Moelk
Brain Endeavor LLC
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: Is linq the final straw for VB?
    ... RAD language VB is the better choice. ... Personally i believe that VB developers are overall more modest an logical ... is simply a lot more typing in VB. ... But the VB IDE team found something verry smart for that :-), ...
    (microsoft.public.dotnet.languages.vb)
  • Re: when is VB.Net getting anonymous delegates?
    ... Therefore Microsoft developers did not always understand the problems from those who are using their tools and the tool developers ware of course more biased on C# when they make samples. ... In terms of which language I like the best, my hat is always hanging on the VB.NET tree. ... the IDE problems with intellisense in VB are a valid problem. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Is linq the final straw for VB?
    ... C++ and all other mathmetatical syntax ... RAD language VB is the better choice. ... is simply a lot more typing in VB. ... The VB.NET IDE ...
    (microsoft.public.dotnet.languages.vb)
  • Re: dynamic type checking - a pauline conversion?
    ... Unit testing isn't incompatible with careful coding. ... DBC and static/manifest type checks. ... static checking in a language like Haskell, which has type inference, is ... I don't believe the IDE can do that. ...
    (comp.object)
  • Re: Still clinking to Java?
    ... I was toying with saving effort by making the C version a DLL and redoing the GUI in my portable Cello GUI. ... But there would be new work on the engine, and just trying to get a clean compile of the C version under VC++ I saw enough to remind me I would rather work in Lisp. ... IDE investments can simply be skipped. ... I just don't want to switch language _at that point_ and recode ...
    (comp.lang.lisp)