Home > Archive > Kylix > June 2006 > Development time
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Suppose you had a shed load of money,
and wanted to develop a similair product
to Kylix how long would it take?
I have looked at freepascal its flaky and
I thought why did Borland get Delphi so
right and Kylix not so good, and the only
alternative is freepascal and its taking
forever to get there.
I guess a whole rethink on a RAD pascal
IDE for Linux and other non win platforms
would be a complete rewrite without the win
baggage.
So before I start hiring compiler writers
and associated staff what would you like
to see ImaginePascal do that Kylix didnt.
Rita
| |
| Marco van de Voort 2006-05-31, 4:17 am |
| On 2006-05-31, Rita <spam@nospam.com> wrote:
> I have looked at freepascal its flaky and
> I thought why did Borland get Delphi so
> right and Kylix not so good, and the only
> alternative is freepascal and its taking
> forever to get there.
(Did you contribute to Free Pascal? If not, why not?
FPC and lazarus are simply limited by
(skilled) manpower, and less by "win baggage".
)
> I guess a whole rethink on a RAD pascal
> IDE for Linux and other non win platforms
> would be a complete rewrite without the win
> baggage.
> So before I start hiring compiler writers
> and associated staff what would you like
> to see ImaginePascal do that Kylix didnt.
- Compile VCL programs. CLX<->VCL was a major problem for most. Compability is King, if not Emperor.
Sacrifice compability, and you won't have any users left.
- The Unix side of things should be generic Unix. Kylix was too tied to
Linux/x86 in that particular version. Unit libc is a pure header translation
that doesn't even abstract pretty perpetual general POSIX functions from
Linux/x86 specific calls.
- Avoid as many library dependancies as possible for the base system to
avoid deployment problems. IMHO dependancies for the IDE are less important,
as long as you release new point releases if new major distro's (versions)
become available.
- Same for the widget set. From a design perspective, Borland made the same
mistake with Kylix (keeping not enough distance from the QT, as Delphi
with win32). I understand how it went as it went though due to business
realities. Theory and praxis :) A good test would be to make sure that
Carbon, QT and GTK are doable.
- You'll release often (say every 6 months) to move with the fast evolving
Linux + all its components. This both for the IDE part and the Compiler/RTL.
This can be tied to a software assurance businessmodel.
- Make sure there are a lot of components that wrap existing *nix libs. Of
course db support (commercial AND OSS) is very important. Don't limit the
support to one DB, developers can't always choose their db (managers and
existing dbs)
- Keep linking compability with compilers. At least GCC C,
preferably also Java and C++.
.... btw: I hope you are a billionaire :_)
| |
| Florian Klaempfl 2006-05-31, 7:17 pm |
| Rita wrote:
> Suppose you had a shed load of money,
> and wanted to develop a similair product
> to Kylix how long would it take?
5 years
5 million lines of code
50 developers
If it's not linux only but unix i.e. multiple widget sets and OSes.
| |
| Mat Ballard 2006-05-31, 7:17 pm |
| Rita wrote:
> Suppose you had a shed load of money,
> and wanted to develop a similair product
> to Kylix how long would it take?
Have a good long look at RealBasic:
http://www.realsoftware.com/
and multiply by about 3.
cheers,
Mat
| |
| Michael Schnell 2006-06-02, 8:11 am |
| Do you want to create a commercial product ?
If not you should work together with the Lazarus team. While Lazarus is
not "ready", I think it's very promising. And the Free Pascal compiler,
Lazarus depends on, seems quite mature. Lazarus problem parts are IDE
and LCL.
What I think is essential for a Kylix follow-up:
- not processor depending (ARM PDAs are a major target).
- enhanced Compatibility. Where Delphi programmers need to rely on
Windows API calls (e.g. when using messages for thread communication), a
decent multi-platform tool needs to provide platform independent
encapsulations (including Delphi versions).
- Michael
| |
|
|
| Michael Schnell 2006-06-17, 8:47 am |
| Do you want to create a commercial product ?
If not, you should work together with the Lazarus team. While Lazarus is
not "ready", I think it's very promising. And the Free Pascal compiler,
Lazarus depends on, seems quite mature. Lazarus problem parts are IDE
and LCL.
What I think is essential for a Kylix follow-up:
- not processor depending (ARM PDAs are a major target).
- enhanced Compatibility. Where Delphi programmers need to rely on
Windows API calls (e.g. when using messages for thread communication), a
decent multi-platform tool needs to provide platform independent
encapsulations (including Delphi versions).
- Michael
| |
| Marco van de Voort 2006-06-17, 8:47 am |
| On 2006-06-08, Michael Schnell <mschnell_at_lumino_dot_de@hotmail.com> wrote:
> Do you want to create a commercial product ?
> If not, you should work together with the Lazarus team. While Lazarus is
> not "ready",
Both implied truths are incorrect. Commercial applications using Lazarus
have been deployed already for a long time.
While Lazarus might not be a drop-in replacement for Delphi or Kylix is a
different matter all together. As a good software engineer one should first
ask for the exact project requirements and timeframes.
> What I think is essential for a Kylix follow-up:
> - not processor depending (ARM PDAs are a major target).
http://wiki.lazarus.freepascal.org/...ws_CE_Interface
> - enhanced Compatibility. Where Delphi programmers need to rely on
> Windows API calls (e.g. when using messages for thread communication), a
> decent multi-platform tool needs to provide platform independent
> encapsulations (including Delphi versions).
True. However that is pretty much an open door. The big question is how to
do this in practice:
There are several traps:
- emulation of Windows concepts on other platforms (Kylix is not entirely
innocent in this regard, QT maps pretty close to winapi, thus making the CLX
not really broadly applicable)
- Trying to abstract everything and loosing everything and the native feel
(Java Swing). Pretty much losing the possibility to make specialised native
versions of widgets in the process.
- Too little crossplatform (Kylix/Delphi again), and you'll have to use
platform dependant code to accomplish anything non trivial.
|
|
|
|
|