On Tue, Oct 31, 2006 at 04:57:25AM +0200, George Birbilis wrote:
> > - What .NET version to target?
>
> Any version.
That 9 folds the amount of work, since the whole lib must be done several
times.
> Visual Studio.net can do similarly (you select the target .NET framework
> dependency [can be set to "all" or to a specific .NET framework version] -
> VS.net can also compile to target mono, see RemObjects.com's Chrome for
> article on how to do that).
I'm not talking what could be done in theory, but I was trying to get beyond
the theoretical discussion that involves Microsoft/Borland propaganda and
random theoretical "you can compile for xx because yy exists".
IOW, in which of these technologies can you imagine that sb has enough faith
(and need) to put in 2 years of your spare time to port FPC/Laz?
IOW what should be the main focus of a hypothetical lazarus/fpc team, what
are your time estimates etc. All this stuff doesn't grow on trees, and each
feature is or theoretical possibility has to be tested and documented the
least, and more likely will need compiler and library changes.
This is not the ".NET dream hour" of what could be, but reality.
Just shouting "any" to all possibilities of them is useless. You have to
choose.
> Anyway in my opinion a form designer should be agnostic of the framework
> under it, just support visual containment and use Reflection-like APIs to
> get properties (and property pages if applicable) of container and contained
> controls (which are themselves containers to other controls etc.).
Which effectively means it will be limited and shitty. Lowest common
denomitor.
(all other "ANY" answers and theoretical dreamery skipped)
> > - Is real (vs on paper) portability an issue? IOW will we abstract all
> > libs for usage with mono, and develop Windows + mono at the same time,
> > or do we develop Windows first and just point to mono as a stopgap?
>
> Side-by-side, to make sure only portable stuff is used
You realise that this will probably severely limit what you can use from the
framework, since mono is far from complete? And it might become a problem in
the future if e.g. Mono or Windows start to divergate (e.g. MS waves with
patents, or Mono wants to do more than just emulation, or decides some parts
are too windows centric and rolls their own incompat one)
> > - What is the benefit on embarking on this issue beyond just buying a
> > copy
> > of Chrome/Delphi.NET/VS2005 copy. IOW what is the added
> > value of doing
> > this with FPC, except because everybody is doing it (and already in
> > production, while we are not)?
>
> In that FPC on future Windows platforms (which take up a huge part of the
> desktop market) will not die (being an obsolete dinosaur)
Well, first, I don't believe native will die, but second just being on .NET
as one of the herd won't mean you will survive. You'll have to add value
somewhere. The added value of native is clear, part Delphi compat (language
and library), with the addition of a strong multiplatform capability that
Delphi doesn't have.
> > - Do we keep Borland compability? (VCL.NET emulation,
> > language features, other lib features) Will Borland still be
> > actively using VCL.NET in say 3 years? (or doing .NET for
> > normal apps at all?). If so, does mono limit us?
>
> I don't see why not use Borland's VCL.net directly too where allowed.
You need a license. So you have to duplicate it.
> Can compare VCL and VCL.net Borland sources to see what they changed
> during move to .NET I suppose
Not allowed. But I expect them to be totally different btw.
> > - If multi platform:
> > - do we develop new libs ? (no ADO on linux etc)
>
> What do you mean by "no ADO on linux"? ADO.net isn't ADO and doesn't need
> to use ADO stuff.
Does it matter? What do I use on Linux/FreeBSD/ Mac OS X /CE etc ?
> > Of course you have to keep in mind that
> > - for every addition you answer "yes" to, you will be asked to put in
> > 2 years of your life to realise it. IOW, don't choose to be
> > compatible with all :-)
>
> You have to always aim high :o)
Well, if that is the case you definitely score well :-)
> > - Choices must be valid and usable in production for at least
> > the next 5
> > years. (2 years devel, 3 years production)
>
> They will, WinForms API isn't dying, will always be arround in one way or
> another (even "emulated" over some other API)
But do you want to invest years in a technology that will be deprecated when
it comes out.
> > - There will be major enhancements for .NET every 2-3 years,
> > and all commercial parties will there before us. So the
> > question of "what do we want as added value" also becomes
> > "what can we provided as added value given the known limited
> > resources". Please no stories about how developers will swim
> > across oceans to help us. Be realistic.
>
> I don't see why Lazarus has to compete with commercial vendors, it just has
> to evolve and keep up with changes in the s/w landscape, else it will
> eventually die
All tools compete. True, there are different markets, but keep in mind that
the .NET market is mostly a commercial one, with some derivative markets
like mono.
And I agree with the rest, but I think you see this change by MS way more
general as a change in the s/w landscape then we do.
I think .NET will get a significant piece of the pie (with marketing dollars
and ASP.NET as main reasons), but it won't erase native. Not even close.
> > around ASP.NET) See also .NET FAQ, Mono is quoted again and
> > again, and I know that basic apps work. But what is really
> > the long time perspective, and how much does that limit you
> > to go the Borland way?
>
> Mono does (partially) ASP.net under Apache. Even Microsoft's ASP.net CAN run
> under Apache (with MS .NET runtime)
Partially here, "CAN" there. But what is now really feasable? We can play
this game forever, but sooner or later one has to commit to real choices,
and not play the maillist dodge game, and "there are no problems".
So again to you and the other .NETistas: how would your program/roadmap for
a FPC/Lazarus.NET look like, how long do you estimate a stage, and then we
will try to objectively comment on that.
> Also, as I said above, ADO.net has not much to do with ADO. From what I
> remember there is ADO.net on mono (they provide managed db providers for
> MySQL and Oracle at least I think)
Of course they play a lot. I also run WinUAE on Windows and UAE on Linux,
but that doesn't mean I'm going to develop Amiga software.
> > Can you name apps? Afaik it is mostly used for a bit of in
> > application scripting and some webapps. But is it really a
> > Delphi replacement? I doubt it. What does it use for GUI btw?
>
> Who said about Delphi replacement.
I mean a replacement for any of the languages you name below.
> It's just a nice OOP language, not my
> taste though when compared to Object Pascal or VB.net (btw, I hate C#,
> prefer Java to it)
Agreed 100%. I simply don't see any reason why I should use it. All the
above languages (even VB.NET even though I hate it) are somewhat general
purposes. The scripting languages are all limited. Why would I bother? What
is their sweetspot?
I always thought PHP's was webdevelopment, and Perl was textprocessing, and
Python was fairly embeddable in apps.
But PHP and any of the web scripting use could be replaced by ASP.NET (so
I'd rather invest time in that), Perl turned out to have a horrible syntax,
fluctate in time, and caused me the worst trauma of my entire development
carrier (specifically in combination with Latex2html). Well Python is still
used for in application scripting, but I don't spend my time on that. Hobby
wise or profesionally.
> > True. But I already know Object Pascal, and have done some
> > Java and some C#.
> > However for me the GC aspect of .NET is not worth the
> > trouble, except for ASP.NET maybe. What would one actually gain?
>
> The GC aspect of .NET isn't like the one in Java VM. I have not seen
> problems with GC hickups stalling the whole runtime as in Java (although
> recent JVM versions have become much better).
I don't have a problem with allocation in general. I design and architect
software, not throw it together, so GC doesn't solve any problem for me.
> > > But then you lose all the fun, plus your skill rot
> >
> > I think your skills rot quicker when one shallowly moves from
> > one technology to the other.
>
> You always have to master what you're learning/using in my opinion, but
> depends on the time you want to give to that (we must have a real life too
> or eventually we wear off [I've been and still are there a bit]).
I don't master them at the expense of free time, but simply by carefully
selecting the technologies I dive into, and not be persuaded by a bit of
carefully crafted PR.
> You reuse your experience at whatever new thing you're at, the only thing
> to worry about is doing the same stuff over-and-over every day, not
> learning new things, nothing really inspiring (e.g. on .NET I find LINQ
> inspiring)
The only thing that was somewhat inspiring for me was the internal model of
ASP.NET,
how they deal with sessions etc.
Some other stuff was not really inspiring (like the providers, the remoting
etc), but still interesting because of the vast scale. Some stuff gave met
the creeps and felt like a step back, specially the _size_ of the language
C# (with all modifiers and property-properties) of symbols.
I don't really buy the "safe" code or GC aspect. I don't really have to
invest much time in memory allocation, and a customer will complain
regardless of the fact that the error is an "access violation" or a "null
pointer exception".
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
