Board index » kylix » Re: Very Good news! Interview with Danny Thorpe

Re: Very Good news! Interview with Danny Thorpe


2005-06-25 11:00:57 PM
kylix1
Ed Purkiss wrote:
Quote
>
>Obviuosly you don't tried to work with databases.

Interesting attempt at a point, but in fact, I run 15 eStores all built
on Kylix with MySQL
I have worked through the workarounds and remain
very satisfied with the tool.
Do not confuse your own ingenuity and resourcefulness with usefulness
of Kylix as a RAD tool for database development. For what I know, in
a talented hands KWrite and an access to a compiler will do just fine.
Besides, you are talking here about Kylix web application so the
clunky Kylix layer is replaced by web server and browser. From my
experience it is not as easy as it looks (or one would expect it to
be) to create a desktop front-end to a more complex database with
Kylix as a RAD tool. Yes, you can do it, if you really want it, but
you mast apply a lot of workarounds, use third-party components, apply
patches, replace part of the mechanism with your own code and
essentially you are not using Kylix in a sense of a RAD tool.
Third-party components with source code helps a lot and for some
things it is just better not to use the dbExpress at all. The
dbExpress + suppled db drivers are limited, buggy and slow. They
appear to work well in a demo or a small application, but if you
interact with a complex relational database that is constructed from
many tables and the client application has to maintain several
interaction with the database in a real time the Kylix GUI front to
the database is unsatisfactory in the designer time in Kylix IDE. The
Kylix IDE is cumbersome this respect and simply it is not able to
handle correctly a large design and help in the design process, it
makes me wonder if it ever was tested or even went through some sort
of QA process. But, I agree that afterwards when everything is done,
all the workarounds are in place and the db connectivity is
streamlined with custom code the application may perform very well.
juliusz
 
 

Re:Re: Very Good news! Interview with Danny Thorpe

juliusz wrote:
Quote
Do not confuse your own ingenuity and resourcefulness with usefulness of
Kylix as a RAD tool for database development. For what I know, in a
talented hands KWrite and an access to a compiler will do just fine.
Besides, you are talking here about Kylix web application so the clunky
Kylix layer is replaced by web server and browser. [clip]
100% correct, and aptly pointed out (TY, BTW, for the compliment, but
I'm afraid that the ingenuity is more often that of great shoulders that
I stand upon...) You are right - I have used a variety of tools to avoid
that worst parts of Kylix and gave up on GUI apps long ago. I wrote
several with K1 & K2, but my limited knowledge of Linux seemed to cause
me troubles - clearly, ergo, all the other complaints in this news
group. I adopted a "Browser is the only GUI allowed" for my team about 3
years ago and a "Kylix cannot know about databases, the central server
via Apache/PHP does" methodology about 2 years ago (my rendering devprs
are only allowed to speak XML to the database, the PHP/MySQL team knows
nothing of the user interface). So I should be more straightforward: if
someone can demonstrate to me that Lazarus or Free Pascal or some other
Object Pascal dialect / compiler project attaches to Apache with the
same robust strength and reliability that my Kylix DSOs do, compile as
tightly and run as quickly, then Borland will lose even the last of us.
On the other hand, that certainly would cut down on my somewhat-annual
expense for the newest Enterprise Edition... ;-)
-EP
 

Re:Re: Very Good news! Interview with Danny Thorpe

On 2005-06-24, Simon Kissel < XXXX@XXXXX.COM >wrote:
Quote
Linux distros are based on the assumption that all applications on the system
are built from source with the gcc version shipped with the distro.
That "shipped with the distro" is the clue. There is per distribution (+version) release
engineering going on, that you miss if you have one binary product spanning multiple distro's
and releases.
Free Pascal exactly has the same problem. GNU Pascal, another pascal
compiler and a gcc derivative, has similar, but different problems (they
absorb certain problems by being a gcc derivative, but migrating to a new gcc
version is a range of problems a magnitude worse, due to constant change)
People often forget that most Linux (or FreeBSD/ OS X) binaries from Unix
origin are prepared by dedicated per distro or OS maintainers, doing the
occasional fix, adaptation, calling the right configure parameters etc, for each
release of each distro again.
Quote
It's common that binary applications get broken all the time, interfaces
change etc.
Correct.
Quote
The only alternative that Borland had regarding this simply was: Not creating
Kylix.
Or having a customization system per distro. They tried to keep it as rigid
as possible (one binary fits all), and now pay the price. Maybe they should have
factored some parts that are prone to change out of the system, and to be post-upgradable
easily on a per-distro basis.
However I think also the relative short time was the problem. Linux' mills
grind slowly (is that an english expression too?), and keeping pressure on
the devels is important.
Quote
It's next to impossible to maintain such a big binary GUI application like
the Kylix IDE w/ de{*word*81} etc is.
IMHO Borland did the right thing. It's an OK decision to limit the IDE itself
to a selection of certified distros (of course this would need to get updated
from time to time with new product releases, which are missing), as long
as the applications created with the IDE run on current distros. I don't see
any reason why you need a specific Linux distro for your development platform.
I think that linux is for a large part to blame for the problems, and also
for the lack of sales. A large part of the problem is also that distro's
don't have a proper generation problem. E.g. version X only works with
kernel series Y, glibc version series Z etc, to get some stability in
interfaces. In reality, nearly all distro's deviate from this principle just
to be able to have the next KDE version first.
Kylix had flaws, but it was working, and being the only product in
its league should have made up for that, just like D1 did.
Quote
>I think the reason that CLX was so buggy is that it was not tested
>adequately. With the VCL, there was at least one big program using
>the VCL that could reveal bugs in the VCL: the Delphi IDE. If the
>Delphi IDE had an obvious bug that could be traced back to the VCL,
>that bug would probably be fixed. With CLX, there was never anything
>that forced the Borland developers to pay attention to bugs.

I agree. A native Kylix IDE written using CLX would have helped a lot.
Definitely. Which is one of the reasons why we compiler FPC with FPC,
instead of being a gcc derivative.
 

{smallsort}

Re:Re: Very Good news! Interview with Danny Thorpe

"Brion L. Webster" < XXXX@XXXXX.COM >wrote in message
Quote
Robby Tanner wrote:

>Nothing? Borland could have assigned resources to fix the Linux issue
and
>contribute to the open-source community. I'm not saying it SHOULD have
or
>faulting it for not doing so, just pointing out that there is almost
always
>something that can be done.

Do you remember how the Linux folks jumped all over Danny for suggesting
the loader might need some enhancement? Why would Borland get e{*word*277}d
about "fixing Linux" when the Linux folks are just going to disparage them
and not accept the contribution anyway?
No I don't. Nor did I suggest Borland should "get e{*word*277}d". Please read
original post.
Rob
 

Re:Re: Very Good news! Interview with Danny Thorpe

"Didier Largange" < XXXX@XXXXX.COM >wrote in message
Quote
>Please explain. On the one hand you think it's OK to "limit the IDE
>itself to a selection of certified distros" but you "don't see
>any reason why you need a specific Linux distro for your development
>platform". That sounds like a contradiction. I may be reading it wrong.
>

Meaning, as a developper you shouldn't care to be limited to a subset of
linux distros. This doesn't affect the software you produce.
Still confused (sorry). How is the "development platform" different from
the subset of distros the IDE is limited to?
Is the compiler provided for Kylix operable across all distros? If not, how
does one make applications for distros where it won't work?
Rob
 

Re:Re: Very Good news! Interview with Danny Thorpe

Quote
Still confused (sorry). How is the "development platform" different from
the subset of distros the IDE is limited to?

Kylix IDE is not native (Wine based), it depends on compatibility with
libraries on your linux distros.
Quote
Is the compiler provided for Kylix operable across all distros? If not, how
does one make applications for distros where it won't work?
Linux distros are binary compatible, especially if you provide the
needed deployment libraries with your app.
Didier
 

Re:Re: Very Good news! Interview with Danny Thorpe

Didier Largange < XXXX@XXXXX.COM >wrote in
Quote
Kylix IDE is not native (Wine based)
IIRC it uses the winelibs, but is an ELF based executable.
--
Iman
 

Re:Re: Very Good news! Interview with Danny Thorpe

He seems to claim that Delphi .NET generated assemblies run on Mono.
AFAIK, this is not true for any non-trivial project (at least not for
Mono/Linux).
-Michael
 

Re:Re: Very Good news! Interview with Danny Thorpe

Michael Schnell < XXXX@XXXXX.COM >wrote in news:42d11e1a$1
@newsgroups.borland.com:
Quote
He seems to claim that Delphi .NET generated assemblies run on Mono.
AFAIK, this is not true for any non-trivial project (at least not for
Mono/Linux).
Indy 10 already runs on Mono, and its built using Delphi 2005.
Blogs: www.hower.org/kudzu/blogs
 

Re:Re: Very Good news! Interview with Danny Thorpe

On Sun, 10 Jul 2005 23:43:01 +0300
"Chad Z. Hower aka Kudzu" < XXXX@XXXXX.COM >wrote:
Quote
>He seems to claim that Delphi .NET generated assemblies run on Mono.
>AFAIK, this is not true for any non-trivial project (at least not for
>Mono/Linux).

Indy 10 already runs on Mono, and its built using Delphi 2005.
"non-trivial" as in, at least, involving GUI components, which is, you have to admit, one of the key concepts in Delphi.
Micha
 

Re:Re: Very Good news! Interview with Danny Thorpe

Micha Nelissen wrote:
Quote
"non-trivial" as in, at least, involving GUI components
That would rely on WinForms support in Mono being up to speed.
--
Dave Nottage [TeamB]
 

Re:Re: Very Good news! Interview with Danny Thorpe

Micha Nelissen < XXXX@XXXXX.COM >wrote in
Quote
>Indy 10 already runs on Mono, and its built using Delphi 2005.

"non-trivial" as in, at least, involving GUI components, which is, you
have to admit, one of the key concepts in Delphi.
WinForms is progressing well. There are limitations, but I presented to the .NET user group here a
session on Mono. Someone asked about Winforms, I made a new Winforms, dropped a button and
coded a few things - and it ran on Mono on Linux just fine.
Blogs: www.hower.org/kudzu/blogs
 

Re:Re: Very Good news! Interview with Danny Thorpe

"Dave Nottage [TeamB]" < XXXX@XXXXX.COM >wrote in news:42d31e4b$1
@newsgroups.borland.com:
Quote
That would rely on WinForms support in Mono being up to speed.
Mono also supports GTK+ and in total about 4 window libraries, and since Mono runs on Windows
too...
Blogs: www.hower.org/kudzu/blogs
 

Re:Re: Very Good news! Interview with Danny Thorpe

Chad Z. Hower aka Kudzu wrote:
Quote
>That would rely on WinForms support in Mono being up to speed.

Mono also supports GTK+ and in total about 4 window libraries, and
since Mono runs on Windows too...
So could a Delphi for .NET app use GTK+ (or the other window libraries)
on Mono?
--
Dave Nottage [TeamB]
 

Re:Re: Very Good news! Interview with Danny Thorpe

"Dave Nottage [TeamB]" < XXXX@XXXXX.COM >wrote in news:42d358f1
@newsgroups.borland.com:
Quote
So could a Delphi for .NET app use GTK+ (or the other window libraries)
on Mono?
Yes. I dont know the status of design time support though.
Blogs: www.hower.org/kudzu/blogs