Re: Top 10 Worst C# Features

[Georg Bauhaus <bauhaus@futureapps.invalid>]

On 05.09.15 08:45, Niklas Holsti wrote:
> On 15-09-05 00:34 , Randy Brukardt wrote:
>> "Georg Bauhaus" <bauhaus@futureapps.invalid> wrote in message
>> news:msbhc8$6qq$1@dont-email.me...
>> ...
>>> So, while there is no problem with
>>> either a very flexible O-O system emulated in C, or with having the Ada
>>> compiler help with earlier binding, both approaches do not handle events
>>> in the language.
>>
>> I have not the slightest clue as to what "handling events in the language"
>> would look like, assuming Ada doesn't have it.
>
> It seems to me that Georg's "events" are rather like the "pointcuts" or "join points" in aspect-oriented programming (https://en.wikipedia.org/wiki/Aspect-oriented_programming) where some computation is added to certain points in a program without modifying the original source code, and instead coding the new computation separately and somehow declaratively defining how the original and new computations are interleaved at run-time at the join points.

These "aspects" (of AOP) would come to mind, but rather than focus on them,
I wanted to start from a more inclusive definition of "event", perhaps
a little broader than those "aspects", but applicable to a number of
programming situations. A definition that can lead the way to language
for writing a program's reaction to specific "events".

Summarily: Some words of source text would then express "event handling",
but neither by way of having "_Handler" as the suffix of some primitive
operation's name, nor by the event being an exception, say, and event
handling being the statements of an exception handler.


Exploring a bit:
First and foremost, programmers need to be oriented when being asked
about events and how their programs handle them, so that's an aspect
to keep in mind when defining "event".

If you think about both programming situations (involving humans) and
also about programs that run (involving technology like clocks, mice,
touch screens, networks, thermometers), then "event" becomes the name
of quite many different ideas. However, they all share certain qualities:

1) that of being tied to one single point in space-time
2) that of having economic impact
3) that of being recurring problems in need of a solution

ad 1) while (1) happens to agree with what dictionaries say,
there is limited support for the property of being single in the Ada
language. More so if there would be other sorts of things single,
besides event handlers. The support that Ada offers is not addressing
events in particular. (Ada is not unique here.)
If there is a chance that some event requires a 1:1 mapping in the source
text, or in the mind of a programmer being asked about it, then just a bit
of general Ada language paired with conventions is all there is.

ad 2), imagine a programmer needing to answer questions of the kind
"What happens if A?". Can they just point at some place in the source text?
What will they find, and how? I guess it is some table-like thing, or
some more or less implicit connection of types.

These two "traces" of event handling both would contain hints at the parts
of the program involved in handling the event "A".  Managing this "cross
referencing structure" is tedious and costly. (No surprise that GUI
programming is considered tricky; it is full of patterns.) If a program
does not provide any of this (Gordian spaghetti), then long hours might
pass until programmers can answer after studying their program once again.
(I am assuming that a majority of GUI programs is not modeled after
some real specification. Unfortunately.)

Also, when developing a program that handles events, there is no specific
guidance by the language; there are libraries that make use of some of
the language's features. Of necessity, this creates idiosyncrasies.
This state of the art might be good when selling proprietary class libraries,
but engineers and project leaders may want something more standard for
this very standard programming problem, lest they become "part of the
business". (At whose cost?)

ad 3) a "problematic" event is an easily named entity; like whenever input
channel X14 is delivering data, the program's behavior should be
such-and-such, possibly depending further on such-and-such. Or behavior is
unexpected.

Now, in general,Without these events, many programs would be pointless.
Still, language-wise, solutions aren't directly available: programmers
rely on class libraries or similar. But solutions need to be found
again and again, so as to have programs that handle anything at all.

In case of unexpected behavior, solving the problem means modifying
the program. But how, if someone else has written the program and used
this or that convention?


Tasks to the rescue? What can you learn from a task's interface that you
couldn't learn from a type's interface? There is one additional bit, viz.
independent execution. Does it help event handling? Not according to
Aaron Hillegass, who explains that many activities seen to be concurrent
can actually be handled conveniently by programming to the run-loop.
(I believe some OS design guys also suggest non-communicating processes,
but don't remember the name of their project.)

A last idea: GUI design programs are a visualization of some event handling,
Or rather, they show the stage for event handling. But either way, somehow
events are present there. So, GUI design programs use somewhat formal
definitions of how objects should be tied together for handling events.
They produce some manifestations of "event handling". Is this kind of
formalization inaccessible to programming languages?