Re: About speed

Jolyon Smith <jolyons@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Fair enough - but by definition delegates are only useful if you use an
approach that uses delegates. I'm just pointing out that you don't have
to use delegates and that that doesn't preclude an elegant and simple
solution (and in fact, is potentially even more so):

btnDownload.On_Click.Add(DownloadInBackground);

procedure TSomeForm.DownloadInBackground(Sender: TObject);
var
tsImageDownload: TImageDownloadThread;
begin
ThreadPool.CreateThread(TImageDownloadThread, tsImageDownload);

tsImageDownload.URL := self.URL.Text;
tsImageDownload.Target := self.Image;
tsImageDownload.On_Complete := ShowImage;
tsImageDownload.On_Exception := HandleThreadException;

ThreadPool.Execute(tsImageDownload);
end;

A huge advantage here (imho) is that the tsImageDownload thread spec
class is re-usable, extensible and potentially polymorphic. In this
case the Target is a TImage, but it could be a TStream.

Ok, a lot of complexity is hidden by this example, but the same is true
of a .net framework based approach. Maybe I can't google or F1 for this
approach, but I do have complete source code.

Yes - you've written a class (but haven't shown the implementation ;) to
encapsulate the job, while I wrote a function (which was entirely
self-contained, in so far as it did what your TImageDownloadThread does,
assuming it has an Execute method or some such). That comes from the
power of anonymous delegates - passing *code* to other methods as an
argument.

The approach you've taken (pretty much the only encapsulation approach
available to you for this problem in Delphi) is great if the class
produced is reusable enough to warrant its existence - but sometimes it
isn't. Also, functions are reusable too! Anonymous delegates are just
another abstraction tool. They're not more powerful than object-oriented
programming, in the same way as object-oriented programming isn't more
powerful than procedural programming - just different and sometimes the
better tool for the job.

I've appended the whole program to this post. Compile it with
"csc Test.cs" for .NET 2.0 (you don't need VS or the SDK, just .NET 2.0
and include $(WINDIR)\Microsoft.NET\Framework\v2.0.50727 on your path)
and open up the executable with Reflector
(http://www.aisto.com/roeder/dotnet/) and you'll see the transformations
in full.

Check out what the code snippet's anonymous delegates are
actually doing. It's not trivial without language support.

Unless I've missed something it's just an alternative to passing
parameters no?

It's an alternative to defining (possibly) a whole separate class,
fields and method just so you can pass a method pointer to a routine.
The magic comes from the way anonymous delegates capture local variables
in their surrounding scope. So, C# code like this:

---8<---
using System;

class App
{
delegate void Method();

static void Main()
{
int value = 0;
Method m = delegate
{
value *= 2;
};
Console.WriteLine(value);
m();
Console.WriteLine(value);
}
}
--->8---

gets transformed into something like this (from Reflector):

---8<---
using System;

class App
{
delegate void Method();

private sealed class <>c__DisplayClass1
{
public void <Main>b__0()
{
this.value *= 2;
}

public int value;
}

static void Main()
{
<>c__DisplayClass1 <>8__locals2 = new <>c__DisplayClass1();
<>8__locals2.value = 0;
Method m = new Method(<>8__locals2.<Main>b__0);
Console.WriteLine(<>8__locals2.value);
m();
Console.WriteLine(<>8__locals2.value);
}
}
--->8---

That is, local variables captured by the anonymous delegates get
converted into fields of a heap-allocated object, while the body of the
anonymous delegate gets converted into a method on the heap-allocated
object. The heap-allocated object only occurs if necessary to enable
variable capture - if you don't capture variables, or only capture
static variables, then there won't be any heap allocations.

I have had to
keep some aspects of GC behaviour in mind when designing some data
structures and algorithms, but on the whole, I've never "come stuck"
because of GC.

Hmmm. Here-in lies the danger as I see it. For yourself this is no
great problem - you have lived in both GC and non-GC worlds, and know
the pitfalls and advantages of both and how to avoid/deal with them.

Now roll forward a few years, and imagine a team comprised of people who
have only ever known GC. Now present them with a memory and CPU bound
process that is suffering greatly with GC issues.

Then retreat to a safe distance.

;)

Java has been around as long as Delphi (certainly I believe Oak or
whatever it was in its incubation period predates Delphi). There's got
to be teams out there filled with people whose only known experience is
Java, right? And if you're right, then there'll be plenty of responses
to this Google query:

http://google.com/search?q=java+gc+disaster

Where are all the war stories from all these disasters?

I don't think unmanaged code is dead. In talking about the virtues of
managed code, I'm not saying that I think unmanaged code is necessarily
inferior or unworthy of strong ongoing Delphi support, for example.

Unmanaged code is more flexible, by definition. Whilst it cannot
leverage some of the benefits of the managed environment, neither is it
constrained by it.

<tongueInCheek>
Assembler is more flexible, by definition. Whilst it cannot
leverage some of the benefits of the type-safe procedural language like
Pascal, neither is it constrained by it.
</tongueInCheek>

I have recently seen .net likened to the VB runtime - vbrunXXX.dll made
developing VB apps very quick and very easy. It required that the
runtime be available on the machines that wanted to run those
applications, which was initially a problem, but not once the required
runtime support became a standard part of Windows.

A lot of people thought that one day all business applications would be
built in VB, with only lower level coding requiring the power of C++.

Guess what: to a first order of approximation, they were right! Visual
Basic has been the most successful programming language in the world,
ever - more than 3 million developers. Far more successful than Delphi,
which I think you and I both believe to be a superior tool.

So, on the whole, I think that the days of business developers writing
business rules in unmanaged languages are numbered. Where the line gets
drawn after that is yet to be seen.

Deja vue all over again.

I seem to remember that applications would one day be built not by
programmers, but by business people.

I think this is a red herring. I don't think anyone has suggested that
Delphi.NET, Java, C# and .NET are suitable for the suits.

It's a cyclical thing. We'll no doubt be having the same discussion in
another 10 years or so, when .net has long since been forgotten and the
next big thing to make programming a non-technical exercise is being
peddled to a whole new generation of executives who would like to
believe that their IT department is an unnecessary expense.

Java hasn't gone away, you know. I suspect it's more likely that the
next big thing will be even *more* managed: things like Ruby on Rails,
for example, and we all know how popular Python is with the folks at
Google.

These new things will just take their place among the diverse and
growing field of things in the programming universe - every new
innovation doesn't necessarily obsolete everything that went before. As
computing and programming continue to mature and evolve, the tools also
specialize and become more targeted as they find their niches.

From where I sit right now, I reckon can see at least 4 distinct
programming paradigms, where languages find it hard to bridge the gaps
(examples not complete or guaranteed to be representative, YMMV):

1) Assembly: best for OS, managed runtimes, performance-critical
libraries, constrained hardware.

2) Unmanaged languages: general purpose languages best for system-level
programming: OS, managed runtimes, performance-critical applications,
slightly less constrained hardware.

3) Managed languages: general purpose languages best for
application-level programming: where the flexibility, productivity and
reliability of managed libraries, applications and infrastructure
outweighs the loss of fine-grained control.

4) Domain-specific languages: the same as it's always been: makefiles,
XML, HTML, SQL, Prolog, etc. Personally, I'd include things like Haskell
and Lisp in here, even though they have equivalent power to other
managed languages; I just think they'll always remain relatively niche,
yet can be very successful in their niches.

The thing is, all these paradigms have been around since the '60s. What
we've been waiting for is the hardware to catch up and start to push the
usage distribution closer to the ideal for the different sectors.

My €0.02 ;)

It's time I got to bed. I'm starting to live on California time :)

***

The whole program, as promised:

---8<---
using System;
using System.Windows.Forms;
using System.Drawing;
using System.Net;
using System.Threading;

class App
{
static void Main()
{
Form form = new Form();

TextBox url = new TextBox();
url.Parent = form;
url.Location = new Point(10, 10);
url.Size = new Size(380, 1); // will expand height to size

Button download = new Button();
download.Parent = form;
download.Text = "Download Image";
download.Location = new Point(400, 10);
download.Size = new Size(100, url.Height);

form.ClientSize = new Size(510, url.Height + 20);
form.AcceptButton = download;

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);
});
}
});
};

Application.Run(form);
}

static void ShowImage(Image image)
{
Form form = new Form();
form.BackgroundImage = image;
form.ClientSize = image.Size;
form.FormClosed += delegate { image.Dispose(); };
form.Show();
}
}
--->8---

-- Barry

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