Re: About speed

"Alex" <zencovich@xxxxxxxxxxxxx> wrote:

Experience only applies to what you've done before. If you're coming on
to a new platform, of *course* not all your experience is going to apply
directly.

It is simple for understand. But I mean - new platform must simplify
develpment. But according to arguments used by you and others (including my
own expirience in Delphi.NET) I cannot see if it become simple.

OK. I tried programming with Delphi.NET a little some years ago, to see
what its integration was like. It was quite impressive for bringing
existing Delphi/Win32 applications to .NET, but right *now*, I don't
think it's the best language for targeting pure .NET. That's just my
humble opinion. I think one should try C# 2.0 before judging .NET.

Seemslike it
become simple only for usual tasks, which enough simple with VB or Delphi
standard VCL development.

That depends on your usual tasks - and the usual tasks are changing as
the problems become harder, and environments become more heterogeneous
and distributed.

For example, a few minutes ago I wrote a little application to download
an image on a background thread, and display the image on screen when
finished. I did it to demonstrate a very basic .NET solution to a
moderately tricky task, involving HTTP, background threading and UI
interaction. The key method looks like this:

---8<---
download.Click += delegate
{
string targetUrl = url.Text;
ThreadPool.QueueUserWorkItem(delegate
{
try
{
Image image;
WebRequest request = WebRequest.Create(targetUrl);
using (WebResponse response = request.GetResponse())
image = Image.FromStream(response.GetResponseStream());
form.Invoke((MethodInvoker) delegate
{
ShowImage(image);
});
}
catch (Exception ex)
{
form.Invoke((MethodInvoker) delegate
{
MessageBox.Show(form, ex.Message);
});
}
});
};
--->8---

This code here queues an action for the threadpool, and marshals the
result (or error, if an exception occurred) back to the UI when done. To
do the same thing in Delphi, I'd have either have to be (1) fiddling
with the design surface, searching for components, properties and
events, or (2) writing lots of code to create a bunch of components, and
a bunch of methods to wire up to the events of these components. I'd
probably have to subclass TThread too.

When you realize what this code is doing, in order to get the variable
capture in the anonymous delegates to work, you end up wondering how you
got along at all without anonymous delegates - they are that good.

But as only you move to complex tasks it becoem not only not simple but even
much and much complex as for understanding as for implementing (I mean - if
you need to check additional interface to allow your object to be disposed
right, implement right methods for dispose resources, etc - is is
simplifying from simple Create/Destroy model? Seems like not.

From your own logic, it is no more complex for resources than
Create/Destroy, and is much simpler for most classes - classes which
don't own resources. Therefore, *any* improvement in productivity from
GC will make it better than a non-GC language / environment.

If you need to keep in mind - object will be boxed so you mostly must avoid
to use object-type properties if you not want to lost perfomance etc etc. It
seems like not simple way.

These become simple rules of thumb, part and parcel of learning a new
language. I don't think they're a significant barrier for an experienced
programmer.

It comes down to this: look at the libraries and infrastructure
available to .NET applications (and keep in mind coming libraries, like
WPF), ask yourself the question: would my job be easier if I could take
advantage of those libraries, rather than settling for whatever your
alternative patchwork of library support is.

Same words can be said for any language. You may find a lot (I think even
more) libraries for Delphi Win32 or C (even not C++). The most sinetific
libraries can be found on Fortran. Business - on Cobol. So I do not think it
is serious argument.

I think it is a serious argument if your platform is Windows. Like it or
not, the future APIs on the Windows platform that client-facing programs
need to code against (i.e. ASP.NET or WPF, but excepting games using
DirectX) are for .NET and managed code.

the right thing to do. Like almost all programming, as long as you have
the higher-level architecture right, you don't need to worry about the
details of the implementation: you can fix those with tuning etc. as you
go along.

Could not agree. .NET show BIG difference in architecture from Win32 so my
knowledge of algorithms works for Win32 was need fully changed for .NET So
it is quite uneasy to create right architecture if you not a guru in that
platform. Previous expirience may not help even worse.

Algorithm complexity is still preserved: an O(n) algorithm is still O(n)
on .NET. The algorithms don't change; sometimes the implementation does.
For example, there were a number of tricks one could do with pointers in
native code; that's often a lot less profitable now, and if it is still
necessary, that path is still there. There are other things available
that make up for the loss, though: anonymous delegates are almost
magical in their capability for automated code transformation.

On the other hand, you need less knowledge about Win32 development.

Yes of course. But I already have it. Since Win 3.1 development. So it is
not a problem for me, like for any developer who work more than 5 years.

My point was a counterpoint to yours about one needing to know more than
before; I was pointing out that you also need less. Perhaps the total is
the same? Or perhaps the problems today are more complex?

I think that solutions these days involve more interaction with the net
(an unreliable, laggy resource), and that naturally makes today's
programming more difficult than it was in previous years. I think the
complexity level of the average solution is increasing.

If you base your decision on your experience with Win32 and lack of
experience with .NET, then I think you're only fooling yourself.

It was a rhetorical statement, not specifically targeted at you - sorry
if it caused any offence!

-- Barry

--
http://barrkel.blogspot.com/
.

Relevant Pages

  • Re: About speed
    ... But I mean - new platform must simplify ... available to .NET applications (and keep in mind coming libraries, ... writing a critical piece of architecture or a library that will be under ... .NET show BIG difference in architecture from Win32 so my ...
    (borland.public.delphi.non-technical)
  • glext++
    ... The purpose of the library is to provide Yet Another OpenGL Extension ... Initialization Library and platform abstraction between ... libraries existed. ... These methods are related to context creation and abstracting platform ...
    (comp.graphics.api.opengl)
  • Re: <ctype.h> toLower()
    ... >> called tolower. ... > My guess is that the compiler you got this from isn't really ... assume the interface will be suitable for the target platform. ... creating portable libraries. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Your iPhoneIs Not Yours
    ... that let you openly write to the platform. ... with windows mobile, to make life easy, you probably want to have ... visual studio to be free (and you can get the express editions free ... do charge for access to APIs and to certain libraries. ...
    (comp.sys.mac.advocacy)