http://delphi.org/

Very nice attempts, but -IMO- they're just wasting their time. :p Why don't they switch to and support FPC/Lazarus instead of doing that? :p

-Bee-

has Bee.ography at
http://beeography.wordpress.com

I fully agree!!!

Regards,
- Graeme -

http://delphi.org/

Sorry... stupid mistypo. :P It should be:

http://opendelphi.org/

:D

-Bee-

has Bee.ography at
http://beeography.wordpress.com

http://delphi.org/ Very nice attempts, but -IMO- they're just wasting their time. :p Why don't they switch to and support FPC/Lazarus instead of doing that? :p

And totally unrealistic.

- price is way to low (50 times that is more reasonable I think)
- not just the source is not for sale, but the whole division.

They try a Blender copycat, but Borland is a bit heavier. Way heavier.

http://delphi.org/ Very nice attempts, but -IMO- they're just wasting their time. :p Why don't they switch to and support FPC/Lazarus instead of doing that? :p

You're kidding me right? Maybe if you made that assertion about Kylix, but not Delphi!! The Delphi.Net compiler alone, and the VCL (full VCL), and defacto support for all (not just a subset) of Delphi features. Delphi 2006 for Win32 also incorperates a lot of the innovations nade in Delphi.Net.

I'm sure Lazerus is a fine IDE, but it is not on a par with BDS.

What he meant is that supporting fpc/lazarus development is a quite more tangible task than trying to buy and support delphi.

That depends on the POV. Lazarus has a lot of things Delphi/BDS doesn't have like multiplatform support and a good optimizing compiler etc, so you can also easily say BDS isn't on a par with FPC/Lazarus :)

However only the time to get anything building of that codebase is probably a horrible task. It is written to be operated by an horde of fulltime programmers + QA department.

The whole idea that OSS programmers can take over this is IMHO nuts. Specially now the number of serious delphi devels are dwindling, and since they always had a no-nonsense mentality.

See how many devels FPC has. That is the same magnitude you can get for Open Delphi. At best, and part-time. And these are battle hardened veterans for a decade and longer. A newly formed OSS team would take at least 1,2 years to even do a maintainance release, at besxt.

See e.g. how long it took for Mozilla to become releaseworthy.

You're kidding me right? Maybe if you made that assertion about Kylix, but not Delphi!! The Delphi.Net compiler alone, and the VCL (full VCL), and defacto support for all (not just a subset) of Delphi features.

The idea is that it´s much, much cheapier to invest on Lazarus and Free Pascal and pay people to implement the missing functionality you need then to buy the whole IDE division of Borland.

thanks,

Who gets the $22,000 they have raised so far, if their plan doesn't work out?

They haven't raised any money yet. The money will only be collected if Borland were to accept an offer from these folks. The amount so far is more akin to pledges.

Mark

L505 wrote

Who gets the $22,000 they have raised so far, if their plan doesn't work out?

With 22.000 dolares we could have, in less then a year:

* PalmOS support for Free Pascal and Lazarus

* A great Carbon widgetset

* Perhaps even full COM and OLE support

FPC is Ok but a few years ago I examined Lazarus
codebase and I saw Lazarus is hacking Class parents on-the-fly for its normal operations so I immediately lost my interest.
Is this changed recently?

__________________________________________________ Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

On Wed, 15 Mar 2006 15:57:23 -0800 (PST)

If you mean creating the VMT at runtime, then the answer is: yes, it still does.
What are the alternatives?

Mattias

What do you mean hacking class parents? What I noticed was tons and tons of abstraction and tons and tons of layering. So much layering that when I try to find a bug, I go into the code and start chasing hundreds of units looking for the real piece of code where the bug exists, but since there are so many snippets that inherit from other snippets and objects, you don't really know where to begin.

Delphi 2006 for Win32 also incorperates a lot of the innovations nade in Delphi.Net.

.Net? Though I had suggested FPC to also implement some new Delphi language features which I think very usefull, but I agree with FPC core team that we don't need to support .Net yet.

IMO, .Net is just a bussiness buzz from M$ to attract their customers and prevent them from switching to Un*x systems. Speaking technically, I saw nothing new in the .Net technology. It's just a combination of Java (on the system architecture) and Delphi technology (on the system language), with extra resource requirements as the consequences. :p

And if we study the FPC compiler architecture, IMO it's very possible to support .Net. Adding .Net assembly generator on the FPC assembler generator layer would make FPC able to produce .Net executable. CMIIW. But, I think we don't need to do this now. :D

-Bee-

has Bee.ography at
http://beeography.wordpress.com

That's exactly the point. If .Net really gets important, we can easily make a .Net back end. But for now we won't support M$'s bs bingo. However, as long as MS Office isn't written in .Net I see no need to do see even if M$ tries permanently to tell people this is a different story :)))

Frankly, all that stuff is still early 80s then
they just hadn't the computing power to actually do it.

Information technology hasn't changed too much since then. They just invented a lot of new TLAs[0]. The only question is who has the better sales people hired.

Vinzent.

[0] TLA: Three Letter Acronym.

While I'm not a .NET lover (I wrote the FPC section on .NET), but while we all know that .NET is at best M$'s copy of Java, that doesn't mean that .NET is not a danger:

- it is reasonably well implemented and integrated.
- the framework is huge. This is more important than it seems. Less components to buy, more people using a standarised set of components. It has its attraction.
- Managers still believe in managed languages, and might for some time to come
- training and sales
- About each and other shrinkwrap development tools vendor is dead or nearly dead. The few left are into .NET and M$ can easily keep them at arms length technically forever
- Microsoft can also keep them at arms length on price forever (with VS being coveniently priced
at 3/4 of the corresponding but poorer Delphi version) forever
- Microsoft hardly has to do sales anyway. As OS and Office vendor it already has a foot in the door. Strategic developers and educational institutions are given licenses often near free
- Also the massive MS training operations automatically generate MS developer tools sales.

IMHO it is less .NET itself, but the alarming conversion rates of businesses to MS tools (and that is often not a technical choice).

(Oh, and the fact that memory prices have sunk much lately also doesn't propel my enthusiasm for .NET)

From slashdot <http://it.slashdot.org/it/06/03/16/0015253.shtml>

In a classic example of "Do as I say, not as I do", Richard Grimes analyses the ratio of native to managed code in Microsoft's upcoming Vista Operating System. According to the analysis at Microsoft Vista and .NET, "Microsoft appears to have concentrated their development effort in Vista on native code development. Vista has no services implemented in .NET and Windows Explorer does not host the runtime, which means that the Vista desktop shell is not based on the .NET runtime. The only conclusion that can be made from these results is that between PDC 2003 and the release of Vista Beta 1 Microsoft has decided that it is better to use native code for the operating system, than to use the .NET framework."

Regards,

Adriaan van Os

Nice post,

Tottaly agree, this has been microsoft's legacy to computing: standards.

I know this analysis but before I throw it into a discussion I wanted to wait for the Vista release if it's the same :)

Well, I agree with that too.

Is there any way to simplify that and still be multi-platform very easely? Indeed, that is very much hard to track down the units. (In comparison, Delphi is cleaner, but it is not as multi-platform / multi-GUI as laz is.)

Regards.

How can you check Delphi's source for cleanness ? It is not available, except for a few modules like RTL,VCL.

Alexandre Leclerc wrote

Is there any way to simplify that and still be multi-platform very easely? Indeed, that is very much hard to track down the units. (In comparison, Delphi is cleaner, but it is not as multi-platform / multi-GUI as laz is.)

This kind of reorganization cannot be done without a detailed view of how LCL code works.

Maybe we need a general map of how things are connected to each other on LCL, but this can take some time to build and very few people know LCL well enougth to create it.

Marco van de Voort wrote

How can you check Delphi's source for cleanness ? It is not available, except for a few modules like RTL,VCL.

Well Marco, I was talking about the "RTL, VCL" part, not the source of the actual devel tool, interface, etc. Only from the point of vien of the developper and the toolkit to develop. (Just try to go down the roots of a simple TButton... you quickly fall in 'includes' files and so on.

Sorry for the confusion.

Wel,, I must say that only a map would help a remember my old vcl chart from delphi 3 that was showing all the vcl components and their organisation. We could have something similar, then something also like that for the actual source structure.

I think it could be possible by looking at the code and the use clauses, even if we don't know that much the lcl. Is there any good tool to create a centralized point for many people to work on this?

Includefiles are not evil. Sure Delphi doesn't use them much, but that doesn't mean there is something wrong with them when somewhat properly used.

Note that there have been discussions in the past that e.g. for release purposes could be generated per platform that has the necessary includes inlined. It is just the matter of finding sb to write the generator.

include files are not clean?

Getting to the roots of TButton is so easy.

Drop a button on a form. Press F12. Goto the form declaration and click with mouse on TButton, while you hold the <Ctrl> key.

Then, if you want to see the TCustomButton methods and properties <Ctrl>+click on TCustomButton.
Or if you want to see the implementation of the Click method, set your cursor on "Click" and press <Ctrl>+<Shift>+<Down>.

Vincent.

Marco van de Voort wrote

While I'm not a .NET lover (I wrote the FPC section on .NET), but while we all know that .NET is at best M$'s copy of Java,

Well, it may be a copy, but if you take a closer look at it, it's actually better than Java, at least on the technical side.

that doesn't mean that .NET is not a danger:

I never said that. :) But that also depends on what you define as "danger". If you want to attract former Delphi-Developers who already embraced .NET, it is, yes. But OTOH, if your target audience gets a little bit broader and would include developers that just need to get the job done, it's not, I guess.

- it is reasonably well implemented and integrated.

Yes. Although most people don't seem to care about such things.

(Remembering the rumours that the Java Hotspot Compiler has been written in about 3.5 million lines of nasty C++ code, I'd say, it could be even much worse and nobody would notice or even care.)

- the framework is huge. This is more important than it seems. Less components to buy, more people using a standarised set of components. It has its attraction.

Agreed. But from my experience, once you're basing the whole discussion on that, frameworks can never be large enough.

First: Technically, at some point, frameworks can actually tend to be too large, latest when you spend more time looking for the right thing that that you'd need to implement it by yourself.

Second: As a programmer, you usually only need a _very_ small subset of any large framework. With the current project here at work (ported some ten years old Turbo-Pascal based software), I already have quite a set of classes, but if I take a look on what I needed from the FCL, it was not much more than the TStringList, TStream and the TThread class. :-)

It's amazing what you can do if you have the right simple building blocks. For me, software development at the end is nothing more than a good planned Lego(tm). All the parts just have to fit together...

And now that I have some more inside data, I can even prove that I have been no less efficient than my fellow Java coders who have a much larger framework , I believe to know why: For
instance, it took them about the same time to figure out how to use the logging classes in Java the right way as if I needed to implement my own thread safe logger class in object pascal.

- Managers still believe in managed languages, and might for some time to come

Nope. In fact, managers don't care about languages or everybody would've used Ada since years already. Usually managers don't even know that there's more than one to choose from. Or if they do then they just know the usual myths like "too old, too complex, ..." BTST.

If you'd ask a manager about programming languages, I would be surprised if they could name much more than the usual suspects like C, C++, Java. But the same guy will tell you, that their developer are very efficient and they all do CORBA, MDA, OOA, OOD, OOP, RUP, UML, XML, ... -"technology".

- training and sales

Yeah right. You mean like giving away 50'000+ bucks for a proprietary version control system when you can get a more or less standard one for free, but then they can't afford a decent language. ;-)

- About each and other shrinkwrap development tools vendor is dead or nearly dead. The few left are into .NET and M$ can easily keep them at arms length technically forever

Depends on the viewpoint. I know some vendors that don't care about MS and .NET too much. But, well, they earning their money mostly with real-time embedded and safety-critical stuff like military, air-planes, nuclear power-plants. Hopefully it will be a long way until MS gets accepted as a tool vendor and such in that area. Of course, it's not getting you very big bucks, but it still seems to pay the rent.

- Microsoft hardly has to do sales anyway. As OS and Office vendor it already has a foot in the door. Strategic developers and educational institutions are given licenses often near free -

Legalized software piracy, yes.

Also the massive MS training operations automatically generate MS developer tools sales.

Still, a lot of people seem to like Java better.

IMHO it is less .NET itself, but the alarming conversion rates of businesses to MS tools (and that is often not a technical choice).

Converting to MS tools has never been a technical choice. :->

(Oh, and the fact that memory prices have sunk much lately also doesn't propel my enthusiasm for .NET)

Well. I have 20 times more RAM now, than my first harddrive had and Windows2000 still isn't starting up faster than my Windows 3.1 was.

That's called progress, I think. Time will tell. But after having a 25 years old technology that some guy hacked up in a garage still being the most used desktop system, I don't have much hope.

But I'm really getting away from the subject, I think.

Vinzent.

It's not about cleanness, but about comprehensiveness. It is sometimes hard to figure out the underlying functionning of the classes, especially when it has to go with gtk1, gtk2, win32, qt, etc.

I'm not complaining, just saying that the source is sometimes hard to figure out for some people, like me (I must say I did not went in it that much).

Getting to the roots of TButton is so easy.

Maybe it was not the best example. :)

Then, if you want to see the TCustomButton methods and properties <Ctrl>+click on TCustomButton. Or if you want to see the implementation of the Click method, set your cursor on "Click" and press <Ctrl>+<Shift>+<Down>.

What a nice invention indeed. I miss it in D3.

Indeed, and they are probably most required because of all the GUI and OS lazarus supports. I was just wondering if simplifying it is possible; it might not in fact.

Regards.

I'm not complaining, just saying that the source is sometimes hard to figure out for some people, like me (I must say I did not went in it that much).

The problem is not include files, the problem is that the code needs better comments and better documentation.

No, include files have nothing to do with multiple GUI / OS support.

They were probably created to make the implementation work easier. It's hard to write on huge file.

They have. As well as they have in the fpc rtl/fcl. Just consider the FPC system unit, stuffing everything into one file would lead to a huge, probably >100k lines file with a lot of ifdefs which make things completely unmaintainable and unreadable and modifications very error prone.

Marco van de Voort wrote

While I'm not a .NET lover (I wrote the FPC section on .NET), but while we all know that .NET is at best M$'s copy of Java, that doesn't mean that

This will change with version 3 of .net, I looked at an article in the german iX-magazine shortly and there was said it'll get some extensions from functional languages and more (lazy typing, templates aka generics and some more).

One day Microsoft will be in danger of getting split up like the Bell company was. But that might take some decades ...

Marc

You're suffering from Steve Jobs-itus. "The reality disortion field is strong in this one."

Pascal on Linux etc is niche. So, does Lazerus offer full Delphi support (including a full and compatible VCL and proper forms support) using native Win32 API? Maybe... I'm doubtful.

What he meant is that supporting fpc/lazarus development is a quite more tangible task than trying to buy and support delphi.

No, he said "Why don't they switch to and support FPC/Lazarus instead of doing that?". Tha is a large FPD is completely
compatible with Delphi 5 onwards (completely) including full VCL, it's useless to me under Windows... I like FPC and the FPC project, but you have to be realistic about what is possible, now, 7 years after Delphi 5 in comparison to what FPC does.

Note that there have been discussions in the past that e.g. for release purposes could be generated per platform that has the necessary includes inlined. It is just the matter of finding sb to write the generator.

That would have been me complaining ;-)

The include files are evil unless the IDE auto inlines them into the sourcefile.

M

No, it's simply a matter of POV and what you need. A family car can never replace a truck neither a truck replaces a family care. Less people need a truck, but those who need a truck don't suffer from a distorted reality.

Pascal on Linux etc is niche.

So e.g. the ability to generate SSE code and reach the double floating point performance is linux bound?

So, does Lazerus offer full Delphi support (including a full and compatible VCL and proper forms support) using native Win32 API? Maybe... I'm doubtful.

A fully compatible VCL was never the main goal of the current FPC/Lazarus developers because it would be win32 bound.

But feel free to hope for OpenDelphi, I'am curious on the developers doing compiler development in C++ to improve an Object Pascal compiler :)))

Agreed. But talking about being realistic, buying delphi and supporting it seems quite an unrealistic attempt too.

Hey, great idea! How come I never thought of it? ;-) It'll be on my to-do list for SynEdit :-)

-Flávio

I started making a diagram of what procedure inherited from what object and what subroutine called what other subroutine. It's hard to keep it all in your head, so might as well make a little map or diagram of the code. It works, but hundreds of little maps need to be created for several functions.

Delphi source code is probably similar, but a few less layers since they are not supporting multiple OS any more. The Delphi open tools API was always a nightmare to work with, having to always tap into bizarre classes just to do simple things, so we know they aren't perfect at implementing the simplest possible solution.

----- Original Message -----

memsom wrote

The include files are evil unless the IDE auto inlines them into the sourcefile.

Now, that is an awesome idea... but you would need the +/- in the gutter (side bar?) in cas we talk about multiple includes based on defines clauses... and save the include files if code has been changed in them.

The functionality would be fantastic!

There are more people than you :_)

For me (and I mean that with my fulltime Delphi programmer hat on), full compability would be a bad thing.

Compability is a beast that means for every time the gap gets ten times smaller (90% - 99% - 99.9% etc), the work to close that gap also get ten times as much, and the limitations get worse ( e.g. crossplatform libs turn into windows or Linux/x86-2.4.x-as-in-kylix emulations).

At a certain point the work can be better invested in expanding the tool than in more compat.

memsom wrote

Pascal on Linux etc is niche.

Yeah, that has always been my problem. Programming for environments and in languages that are usually both considered niche.

Nonetheless I do it. And I even get fucking paid for it. And most important: It really works.

Vinzent.

Not to forget (translated german idiom): only if you swim against the stream you reach the source :)

Nonetheless I do it. And I even get fucking paid for it. And most important: It really works.

Mostly even better because "niche" solutions fit usually the needs better.