locked
Patterns - Active Events: One Design Pattern Instead of a Dozen RRS feed

  • General discussion

  • Active Events is a design pattern that enables encapsulation and polymorphism. It allows you to separate concerns by creating extendable, reusable components that can be assembled almost as if they were Lego pieces.

    Read this article in the March 2017 issue of MSDN Magazine

    Wednesday, March 1, 2017 9:09 PM

All replies

  • I like my interfaces. There is something reassuring in knowing the exact signature of what you're calling.
    Thursday, March 2, 2017 7:33 AM
  • Can't the same separation of modules be accomplished using dependency injection (by creating all objects in the application root, and composing the object graph there).
    Thursday, March 2, 2017 1:16 PM
  • And you should keep on using your interfaces too. Though, when creating "plugins", Active Events are probably a better answer. Check out Phosphorus Five to understand why ... :)
    Thursday, March 2, 2017 8:20 PM
  • Maybe, check out the dependency graph, and the simplicity of code though in Phosphorus Five, linked in at the article itself to understand the "whys" of why this has the right to live ...
    Thursday, March 2, 2017 8:22 PM
  • Not a biggy, but there's a bug in the first code example. "var" should actually have been "input". Besides from that, give my thx to Michael, James, Sharon and the others who helped me out on this :)

    e.Args.Add(“output”, “Hello there ” + var);

    Thursday, March 2, 2017 8:25 PM
  • My answer :) - https://gaiasoul.com/2017/03/06/how-do-you-create-an-instance-of-an-interface/
    Monday, March 6, 2017 10:49 PM
  • I'm struggling to see the benefits of Active Events compared to dependency injection with a dynamically loading IoC. For example, suppose I have an ICanOpener interface in one assembly, and a ManualCanOpener implementation contained in a separate assembly. My IoC can be configured to load implementations of ICanOpener in some physical plugin folder. Let's say later I get rid of my ManualCanOpener implementation assembly and replace it with an ElectricCanOpener implementation assembly. Nothing in my code would have to be changed. The larger benefit here compared with Active Events is that interface driven design requires no magic strings. Code refactoring can be handled automatically through Visual Studio or ReSharper, whereas magic strings require manual refactoring. Finally, if I were new to a project using Active Events, the ramp up time would be much longer than a traditional OOP project because I can't know the required inputs and outputs of these Active Event functions without looking at the implementation. Obviously, I have not spent as much time on Active Events design as you have Thomas, so I may be incorrect in some of my assertions. Please correct me if I'm wrong.

    Tuesday, March 7, 2017 3:31 PM
  • I find the idea of Active Events very intriguing, and I am a total newbie at these sorts of global abstractions and design patterns.

    But doesn't an implementation like this lead to a greater potential for run-time errors? The "Value" property of a Node is, as one would expect, just of type "object". If one passes a Node with an integer in the value where a string is expected, won't that cause issues? Don't Active Event methods need to be written with all sorts of type-checking and domain-verifying code to make sure the data in and data out works properly? Class methods control all that with strictly-typed signatures and properties that control gets and sets.

    I realize that any higher level of abstraction is potentially going to end up passing around plain objects at some point in the implementation, but this setup seems more like dynamic programming, even old-fashioned macro substitution. Heck, I could run one of my Visual FoxPro applications this way with abstracted or data-driven function calls where the names were decided at run-time and parameters passed of any type I wish (since VFP has no strict typing in the first place). But in VFP you trade off that flexibility for getting all sorts of nasty run-time errors (that I am glad to be rid of in .NET).

    Can someone explain how Active Events isn't simply throwing strong typing out the window? Not to mention the fact that IntelliSense is going to have a hard time helping folks make meaningful decisions as they type in method names, etc. -- isn't that also lost in this scheme?

    Thanks,

    sutekh137

    Tuesday, March 7, 2017 10:57 PM
  • You're exactly right, sutekh137! No more type safety, no more go to reference, no more refactoring, no more.....too many things. I don't see the point in this. We should be going forward, not going back in time...


    Thursday, March 9, 2017 9:08 PM
  • I do find this very intriguing, and I applaud the author for writing it and the editor for publishing it. The author decries the overhead in the current state of OOP and has found one way to address it.

    But I am wondering the same thing as others: Does this promote loose coupling better than traditional IoC, or does it only manage to turn easily-caught design-time errors into runtime errors?

    I also wonder how well Active Events would work in teams. The article states: "...no signatures or types need to be known and shared between the consumer and the implementation of an active event." But of course they still have to be known and shared between members of the team for the code to work. So you're still stuck writing an "interface" of sorts, though it's an informal one that gets emailed to a colleague instead of declared in code. (Making it formal would just be re-inventing the interface, right?) And my fear is that the informal information sharing would be more prone to human error, amplifying the lack of design-time & compile-time checking.

    It's very cool that the author has had success with this approach, and I agree with him that the problems with the current state of OOP make it ripe for another approach to gain traction. But as a fan of strong typing and its benefits, I don't know that I'm convinced to move away from that just yet. Devs with deep roots in JavaScript may feel differently!


    • Edited by ArinF Thursday, March 9, 2017 10:02 PM Clarified wording
    Thursday, March 9, 2017 10:00 PM
  • Isn't this is how Erlang works for a decades? I suppose all this is about safety of code and having a compile-time checks. With Active Events like a protocol we still have to use our IOC and interfaces, but now with added layer of reflection / serialization.

    I think author have something good to say, but this must not be in С# world. I think F# would be great, or even a new compiled language. Or a macro-friendly level language like Nemerle.

    This whole concept is easily covered by Dispatcher + Command patterns imo.

    Friday, March 10, 2017 5:54 AM
  • It took me few lines of this article to become familiar with the idea and see down the road where the author wanted to go and what he wanted to point out.

    Actually the first thing that came into my mind was SCSF and the event aggregator mechanism back then. The idea was the same and you could easily trigger any functionality from any part of your system without tight coupling. I guess that is why Active Events are so familiar to me.

    I am not against the idea, the problem is not with ideas, but with people. Because of the lack of tight coupling no interfaces, no signatures shared, the team developing a big project must be very professional and responsible. Everything must be documented and agreed between team members. If the team has this control and not team members are changed frequently then yes I am with the idea. But if not then those interfaces, signatures and types are working as a safeguard between me, the state of the code and team members.

    Thank you for pointing to me this article. I see good ideas are very hard to die and they always come back.

    Friday, March 10, 2017 9:36 PM
  • Did anyone else think this article was posted exactly one month too early?
    Tuesday, March 14, 2017 6:41 PM
  • Heh, fairly elaborate April Fool's joke, considering the article was also in print -- that's dedication!

    At least, I assume you are referring to April 1st... I'm more intrigued by the header on the article itself:

    "When I approached MSDN Magazine Senior Contributing Editor James McCaffrey to review the preliminary draft of this article, he came away fairly outraged by some of the opinions and ideas put forward by the author. Most days, that would spell curtains for an article draft. But as McCaffrey notes, it’s all too common for new ideas in software engineering to be dismissed simply because they’re new. And while McCaffrey says he’s still outraged by many of the statements in this article, we both agree that it may provoke a lot of thought about software design and methodology paradigms."

    I am wondering what the "outrage" was about, as well as why this would be considered a "new idea in software engineering". A shift to more dynamic module calls and looser typing is certainly a different approach from most other ideas in .NET, but I am not sure I would call it new, overall.

    Thanks,

    sutekh137

    Tuesday, March 14, 2017 7:27 PM
  • Heh, fairly elaborate April Fool's joke, considering the article was also in print -- that's dedication!

    At least, I assume you are referring to April 1st... I'm more intrigued by the header on the article itself:

    [...]

    I am wondering what the "outrage" was about, as well as why this would be considered a "new idea in software engineering". A shift to more dynamic module calls and looser typing is certainly a different approach from most other ideas in .NET, but I am not sure I would call it new, overall.

    Yes, April Fool's is what I was referring to :-)

    I suspect the outrage is more concerning the fact the article is presenting an alternative methodology (which itself is replete with at least as many pitfalls as the paradigms it claims to replace) in a manner which strongly implies this is the best way to do things and that anyone who cares to consider how this "new" pattern works will realize it's almost always a better solution than the more traditional methods of inheritance, interfaces and (intrinsically framework-supported) polymorphism. 

    If we were desperate to make sure all classes were totally independent of one another and could be dropped into a totally alien project with no dependencies whatsoever, why not just ensure every method requires a single System.Object parameter?  Or an XDocument?  Use VB and turn Option Strict off everywhere?  Or use Dynamic objects for everything?  Or switch to a loosely typed language entirely?

    It seems to a be a pattern lately to introduce this anti-pattern as some bold new paradigm, but as it turns out all we're doing is working extremely hard to make a strongly typed language behave like a loosely typed one.  The result is a mish-mash of the two ideologies which just ends up replicating the worst attributes of both.  C# and VB.NET are strongly typed languages.  It is their strength.  Play in to it, don't handicap it.

    I think this was why James McCaffrey was "outraged" at the article.  Does it eliminate dependencies?  Sure.  It also eliminates type safety, Intellisense becomes useless, unit testing becomes significantly more complicated, and I cannot imagine it would have anything but a negative impact on performance.  IoC and other established patterns provide solutions to everything that "Active Events" allegedly solves.  Is Active Events an interesting pattern?  Sure.  Does it have some degree of merit?  Yeah, in my opinion I'd say so. 

    "Active Events" as a replacement for almost every interface you write?  No more classes?  Global functions?  Outrageous! ;-)

    Tuesday, March 14, 2017 10:40 PM
  • Quanta,

    I agree with you. I can see how if you think of Active Events only as some sort of "plug-in" layer, then yeah it might need to be very loosely coupled (and this is a nifty way of achieving that).

    But one of my first thoughts on all this was, "Hm, they already added the 'dynamic' type, and tons of hard-core strict-typists almost lost their lunches (or likely did)."

    I find the "dynamic" type pretty useful, mainly for stuff like COM automation. The Interop layers are nice in that they help with Intellisense and keeping things typed, but I can copy Visual Foxpro code over and just add semi-colons and it all works with dynamic types. I know the pitfalls and I know I am trading compile-time checking for run-time, er, errors, but the point is I know.

    I suppose that's the point here as well. Anyone using Active Events knows they are doing that. It isn't a surprise or "gotcha" (unless you are a new programmer and are revolted by such a loosely-coupled methodology). You could do the same thing by declaring all parameters as dynamic types and just knowing what to expect. The compiler wouldn't say "boo" about anything.

    Like I said, though -- I still feel relatively new at C#. So, I don't understand what is so wrong with inter-dependencies in the first place. Isn't there a fine line between writing modular global code and then calling it "spaghetti"? If you have code in one spot and call it from many others, isn't that a good thing? Did that become poor form at some point? If so, then I'm a terrible, terrible programmer.

    Thanks,

    sutekh137

    Wednesday, March 15, 2017 12:45 AM
  • To understand the benefits of Active Events, requires using analogies unfortunately. A good one, happens to be pipes from Unix, which arguably was the "brilliance" in Unix. Meaning, the ability that everything could be "chained", such that one "thing" could react upon the output on another thing. Active Events work the same way, allowing everything to be chained together, using another event's output as input.

    In fact, I created a Turing Complete programming language with the above chaining technique, called "Hyperlambda".

    I realise that it is a learning curve, and that it is difficult to see its advantage, especially compared to dependency injection, which seemingly solves the same problem. However, it doesn't. For instance, here's an example; If I wanted to, I could serialise an Active Event invocation, or a "chain" of such for that matter. Then I could pass on the serialised invocation to for instance a web service. This would allow me to invoke a web service, passing in a lambda object, where the client is responsible for supplying the "code" that is executed on the server. If this sounds like magic, realise I have already solved this particular use case, which you can see an example of in the video below.

    https://www.youtube.com/watch?v=qFqhAQEAbEo

    Another example is serialising a "lambda object" into a database, this actually describes the "CMS" I built, which allows the users to create "interactive CMS pages", instead of just static HTML pages, where the pages contains logic, and interactive widgets, doing whatever you wish to do.

    To be honest with you, I haven't really studied dependency injection that much, since I have been exclusively focusing on my own research, for a very, very long time. However, I think the comparison becomes that of between apples and pears ...

    Thx for intelligent questions :)

    Thursday, March 16, 2017 8:45 AM
  • Yes, it does eliminate static compilation, which sometimes helps us weed out errors. However, if we wanted to really take advantage of static typing, we'd all be using C++, and not C#. The same problem exists in JavaScript, which is arguably the most popular programming language on the planet. Hyperlambda is arguably "the weakest typed programming language on the planet", and Hyperlambda is built upon Active Events.

    However, these "problems", also have advantages. For instance, you could invoke an event that is still not created. Which becomes the equivalent of invoking a method that doesn't exist. This might sound absurd, but actually has a lot of really beneficial use cases, allowing the developer to anticipate potential future use-cases (validate for instance), which he can't implement at the current time for some reasons, and allow future implementations to such "hook into" his own logic. You can also change an existing Active Event, requiring additional input parameters, or returning additional outputs, without having to meddle with old code, or recompile old code, by providing default values internally within your event, relying upon the fact that "old code" would simply ignore additional output nodes.

    Besides, most Active Events will happily convert the input. For instance, if you invoke an Active Event requiring an integer, it will happily convert a string value of "5" to its integer representation, due to helper methods on the "Node" class. There's a generic method, taking a type, that'll try to "convert everything" (if it can) - So even though typing still exists, it's arguably "optional" in P5.

    Ref; "Can someone explain how Active Events isn't simply throwing strong typing out the window?" - Hehe, sorry. But that is actually its advantage ... :)

    One of the most well known C++ developers (can't remember his name, he had written many of the ACLU endorsed books about C++) once stopped using C++, and started using (I think it was Python?) - As to where he argued that "relying on static compilation, is the equivalent of believing an insufficiently unit tested project will not have bugs" (or something, can't remember the exact quote)

    His point was that you should create unit tests anyways, and that your tests would anyway catch all possible bugs, that the advantage of static compilation would give you, and hence Python (and weakly typing) was the "better approach".

    When that is said, you still have C# at your disposal (or F#, VB.NET, etc) - Allowing you to have your cake, and eat it, at the same time. Active Events aren't for everything. If you need static compilation, you still have it, through C#/F#/VB.NET. However, having the dynamicness of Active Events in *addition* to C#, I believe gives you a lot of advantages ...

    So you don't "throw strong typing out the window", but rather "add an additional abstraction level to your code", where strong typing is no longer necessary. If you wish to use strong typing, you still have it. If you don't need it, you don't have to use it. I tend to see C# as "the reality" and Active Events (Hyperlambda) as "Lala land" - You want to spend as much time as possible in "Lala land", since it gives you more flexibility, and higher amounts of productivity. But whenever you need to dive into "reality", you can still easily do so :)

    PS!
    FoxPro is (I think) an under-appreciated programming language, and arguably very good, at solving some tasks. Imagine Active Events like giving you all the advantages from FoxPro, without loosing any of the advantages from C# and true OOP :)

    In fact, I often refer to Hyperlambda (which is the programming language in P5) as a "5th generation programming language" - As a description of how it ties into "4th generation programming languages", or rather, becomes its "sequel" ...

    Thursday, March 16, 2017 9:11 AM
  • PS, there is intellisense in Hyperlambda. Although not perfect, and not giving you "event signatures" (yet) - It still exists perfectly, and I use it all the time ... :)

    In fact "meta traversal" of the event system, is one of the truly amazing advantages of P5 ...

    Thursday, March 16, 2017 9:12 AM
  • If you truly meant that, you would not be coding in C#, but rather C++ ...
    Thursday, March 16, 2017 9:13 AM
  • Ref; "I also wonder how well Active Events would work in teams".

    That's actually its main advantage, since anyone can focus on exclusively "their parts" of the app, facilitating for "orchestrating the events together at some higher abstraction".

    Ref; "though it's an informal one that gets emailed to a colleague instead of declared in code"

    Actually, it's quite simple to (even during runtime) deduct input and output arguments, before invoking an event - IF the event is "publishing" this - Due to the meta capabilities of the event system.

    You could easily create an event, that for instance (optionally) takes an "inspect" node, and if supplied, returns the input arguments, and an example output, basically allowing the event itself, communicate its arguments. I have such an item on my TODO list in fact, for all the internal events in P5 - Unfortunately it's not there yet, but very easily implemented in all your own events ...

    Ref; "But as a fan of strong typing and its benefits"

    Notice, you still have all the strong typing from C# - You just have an additional abstraction, which you *CAN* use, when it makes sense ... :)

    Thursday, March 16, 2017 9:18 AM
  • Ref; "or even a new compiled language"

    In P5, you can serialise an event invocation, or a tree of such, pass it on to a web service, and have the web service evaluate your "tree". This is simply not possible in "another compiled language" - Arguably, Active Events, is about bringing all the advantages of "dynamic languages" into C#, without loosing any of its existing strongly typing. Basically; "Having your cake, and eating it too" ... :)

    Thursday, March 16, 2017 9:21 AM
  • Ref; "I see good ideas are very hard to die and they always come back"

    Thank you :)

    Thursday, March 16, 2017 9:22 AM
  • The article was heavily edited, among other things, its original header was; "One design pattern to rule em' all". Thanks to Michael, Sharon and James though, it became much more easily "swallowable". However, telling people "I have a better solution to OO than OOP", seems to make a lot of people go berserk, for some reasons ... ;)

    BTW, the idea was originally inspired by the "Pattern and Practices" team from Microsoft, which created the CAB framework, more than a decade ago. They had a similar "event system", I just took the same idea, to its extremes, and did it in a "web context" ...

    So arguably you're right, there's little new here - In fact, Hyperlambda for instance, is largely inspired from Lisp. Its first working name was in fact "Hyperlisp". Although Hyperlambda has none of the syntax from Lisp, and works quite differently, arguably Hyperlambda is "bringing Lisp to C#".

    Lisp, for those that don't know its history, is one of the oldest programming languages on the planet, and was invented in the 1950s I think ...

    Thursday, March 16, 2017 9:28 AM
  • Hehe, no further comment :D

    PS!
    A lot of your concerns are answered in some of my answers to the above comments :)

    Thursday, March 16, 2017 9:30 AM
  • I feel it necessary to clarify, for the record, on my response(s) overall:

    It is of course far easier to post a critique/opinion on someone's article (and framework) than it is to write and develop said content.  Innovation is a crucial part of our industry and without people who take risks, we will never advance beyond simple iterations of existing long-held patterns (beliefs?).

    I salute Thomas for not only producing this framework, but for being willing to put it in front of the developer world and discuss it with them.  If nothing else at all, it got us talking - which means it got us thinking, and this is always a good thing!

    Thursday, March 16, 2017 1:38 PM
  • Thomas,

    Thanks for weighing in and elaborating on all this -- much appreciated!

    Where I find Foxpro under-appreciated (I have been using it for 20 years, and it is still the primary tool we use for custom desktop programming where I manage the App Dev department) is in its data-centricity. Don't get me wrong -- I love .NET DataTables and the plethora of IEnumerable types (not to mention being able to code methods to interfaces instead of merely class types). But -- and this was especially true before LINQ -- I have never seen another tool where I can create record sets ("cursors" in Foxpro lingo) that can then be treated agnostically with inline SQL, especially JOINs and WHEREs to further refine, combine, and aggregate data. I can pull in an Excel spreadsheet, DBF data, an Oracle query result, and the rows of a text file and then perform subsequent SQL statements on the cursors to come up with a final result. And let's be clear: Foxpro is doing all of this with a 3-DLL runtime totaling  just 7 MB in size (or 4 files totaling a bit over 8 MB in size if you need older ODBC access). I think by any measure that is fairly astonishing.

    As far as how things are typed and how methods are flexibly generated, I am understanding quite well what I like about Visual Foxpro (no real typing) and what I like about C# (fairly strict typing). I've written some really messy Foxpro subroutines where half of the content is guard clauses to validate parameter types. And in C# I've taken advantage of overloading, default parameter values, and the new "dynamic" type to write equally complicated methods. At this point, I definitely prefer C# in that regard, and I haven't even gotten into using a lot of reflection or the dynamic "Expando" object.

    That's where I am coming from when I say I find Active Events interesting but can't see myself ever using them (on what is mainly all desktop programming).

    I can call an event not yet created, or even name the subroutine dynamically and then call it -- Foxpro supports macro substitution. But if I ever run into old code that heavily uses macros, it's not fun to deal with. Indirection, after all, is still indirection, and to me it is obfuscating. I feel the same way about writing lots of code to flexibly change parameter values into what you expect (and have done it a ton in Foxpro code). But that was by necessity -- I didn't have overloading and the ability to set sane defaults for parameters right in the signature. Now, in C#, if I want an integer, I just ask for an integer and save myself all sorts of coding to account for odd calling scenarios. If your Node class abstracts that checking in a way that does not require guard code for every usage, I suppose that renders the issue at least partially moot, but as I said: I simply have never told myself: "I need something even MORE dynamic in terms of what I can do in terms of calling modular code," and that goes for both Foxpro and C#.

    The HyperLambda stuff does look interesting, though, and I need to look at more of your examples/videos. So, thanks for the link!

    Thanks,

    sutekh137

    Thursday, March 16, 2017 3:52 PM
  • Showers with flowers to Quanta :)
    Thursday, March 16, 2017 6:56 PM
  • Thx :)

    PS!
    P5 is (almost) pure web, though I have an .exe wrapper, allowing you to execute Hyperlambda files, I wouldn't honestly choose it - At least not at the time being, to create desktop stuff ...
    Maybe for some simple "scripts", and basic maintenance stuff, but not for going "all in". Primarily P5 is about web, and will highly likely stay that way, as far as I am concerned ...

    PPS!
    The good parts to start out with Hyperlambda, is below, which is a small (but not complete) "tutorial style book", explaining the most important parts ... :)

    https://github.com/polterguy/phosphorusfive-dox

    Thursday, March 16, 2017 7:03 PM
  • I'll take a look at that -- thanks again!

    sutekh137

    Thursday, March 16, 2017 7:14 PM
  • I've implemented a similar pattern in Javascript.  One major difference is there are no return values (all events are assumed to be async).  This allows for zero-or-more async handlers to be invoked by a single event.  The problem I'm having is managing the configuration.  It's more powerful and more complex than the code.
    Sunday, March 19, 2017 4:13 PM
  • You don't "configure", you create a Turing complete abstraction on top of your stuff. I've got events named "if", "while", "for-each", etc, etc, etc ...

    That way, it becomes a minimalistic programming language, allowing for the user to tie together his logic, exactly as he see fit ... :)

    Monday, March 20, 2017 4:56 PM
  • Me too.  And it can become a PITA :)
    I even have something that waits for multiple events to take place before it fires.  It's incredibly flexible but it takes on the burden of complexity.  You should put together a http://todomvc.com/ demo.


    X

    Tuesday, March 21, 2017 11:10 PM
  • Kudos to the author for publishing this, and kudos to the editors for publishing it.  Discussions always have to start someplace.

    The goal of Active Events is certainly admirable.  I'm wondering if the new C#7 tuples could "help" address one of the most significant concerns -- type safety.  Secondary to that would be invocation overhead.  Certainly a single Active Event call overhead to perform a long disk or UI operation is not worth debating.  However OOP/modular code also consists of things like enumerations (explicitly coded or implicitly coded).  Or math libraries being called millions of times to perform transforms on vectors.

    Okay so... it seems the likely response would be "things don't have to be mutually exclusive".  I'll certainly agree with that.  A lot of debates turn really dumb when people get fixated on what they don't realize is a "mutually exclusive" argument over things that are not mutually exclusive.  However in this case it raises the question of having two distinct design practices depending upon the impact of the calling overhead for some methods versus others.

    Having both is completely within the realm of possibility, but is it worth it?  Maybe.  Maybe not.  I guess if entire DLLs were either one way or the other it might be a "manageable" concept.

    Ultimately I see Active Events as implementing a kind of JavaScript environment.

    I personally DETEST JavaScript because it is a sloppy un-typed language that defers essentially ALL of its error checking to runtime -- with essentially all potential bugs remaining hidden until each actual code path is executed.  Thankfully TypeScript helps make some major steps to clean up that disaster of a language which was never intended for major application development.

    Let's face it.  The "Holy Grail" of client-side web development would be a translator/compiler that SUCCESSFULLY took C# as input and generated JavaScript as the "target machine code".  Actually translating MSIL/CIL to JavaScript would bring the other .NET languages into the picture as well, although it would present the challenge of building efficient high level code from low level code.

    I present the JavaScript issue because Active Events seems to be essentially the highly undesirable JavaScript model for which people are searching for alternatives to get away from all its ills.

    However back to the start, good things evolve from somebody starting a discussion.  Kudos to the author for presenting the concept if for no other reason than to trigger some pondering.  Perhaps the general concept using a safer implementation might prove to evolve into something.


    -- kburgoyne

    As a P.S...

    Seems like the implementation should try to rely upon method pointers (delegates) that get initialized once.  Either upon first use or as some kind of collection that gets initialized at startup.  The later being the more desirable since it eliminates the "does this delegate need initializing" check every time it gets used.

    I guess this is different than simply having directly-called methods if the desire is to allow the calling module to resolve the method references the way it wants. This also has the benefit of confirming all references can be resolved every time the app is run during debugging without being concerned with whether any given call has been exercised.

    Hmmm... type safety on the parameters still remains an issue.  Ultimately the parameters do need to be as the receiving method expects.  (Similar for the return values.)  The problem is not finding out of they're wrong until execution-time rather than the FAR more desirable compile-time.

    • Edited by kburgoyne Friday, March 24, 2017 12:08 AM Additions
    Thursday, March 23, 2017 11:51 PM
  • Are you kidding me? Blaming source code for the failure of software project? If design pattern could fundamentally change the success rate of a software project, it would have already done so. This is like when one committed a crime, go blame his school education. It's not responsible to simply an industrial-wide complex problem into one single solution and sell it to the audience on a reputable platform.

    Cheers, Daniel

    Friday, March 24, 2017 3:28 AM
  • Re; "However OOP/modular code also consists of things like enumerations (explicitly coded or implicitly coded).  Or math libraries being called millions of times to perform transforms on vectors"

    When it comes to math operations, that should be performed millions of times per second, I would *NOT* suggest doing this through Active Events, except for maybe invoking the initial method, that starts the operation.

    Regarding enumerations, I'd say "it depends". I have Active Events named "for-each" and "while". Would I use them for extremely time critical operations? No! However, most loops where these are intended to be used, are loops such as "for-each (customer) {create-widget}", at which point they're perfectly fine ...

    Re; "I personally DETEST JavaScript because it is a sloppy un-typed language that defers essentially ALL of its error checking to runtime"

    Arguably, with Phosphorus Five, JavaScript becomes "optional". I've created a "managed Ajax library", which completely abstracts away 99% of all application JavaScript, which serves as an "API" between the server and the client, making it arguably "obsolete".

    Re; "Let's face it.  The "Holy Grail" of client-side web development would be a translator/compiler that SUCCESSFULLY took C# as input and generated JavaScript as the "target machine code".  "

    In a way, you just described P5's Ajax library (p5.ajax), except it doesn't compile, but provides a server side "API", which maps back to the client, making it impossible to create malfunctioning JavaScript.

    The JavaScript portions of P5 is actually no more than 3.3 KB, and never exceeds this, unless you include "extension widgets" (CKE editor for instance)

    With these 3.3KB though, you can do "everything" you'd expect to be able to do in regards to DOM manipulations.

    I have profiled P5's "datagrid" and "treeview" for instance, towards some of the major players counterparts in our industry, and P5's versions performs several orders of magnitudes faster, better, etc, etc, etc. Imagine a complete client-side Ajax based TreeView component, with no more than 3.3KB of JavaScript - Well, you don't have to imagine, it's already there ... ;)

    Re; "I present the JavaScript issue because Active Events seems to be essentially the highly undesirable JavaScript model for which people are searching for alternatives to get away from all its ills."

    Nope, sorry you're wrong here - It is in fact the exact *opposite*. It completely eliminates the entire "JavaScript problem" for web app development ;)

    Re; "However back to the start, good things evolve from somebody starting a discussion.  Kudos to the author for presenting the concept if for no other reason than to trigger some pondering."

    Thx :)

    Re; "However back to the start, good things evolve from somebody starting a discussion.  Kudos to the author for presenting the concept if for no other reason than to trigger some pondering."

    I have considered optimizing the reflection usage, with such schemes, among other things - At which point I think I could possibly optimize invocations of Active Events down to the point where they perform equally fast as delegate invocations ... ;)

    Re; "Hmmm... type safety on the parameters still remains an issue"

    If you add type safety on the parameters, you remove its entire USP, and you're left with a "worse C#, without classes". The runtime dynamicness of the thing, is the whole point with the thing ...!! ;)

    Monday, March 27, 2017 7:51 AM
  • Hi Daniel,

    I created this in *** 5 days *** !!

    It's 100% secure, uses PGP cryptography, impossible to spread viruses through, and effectively completely clones (the important parts of) GMail. Yet again, I would want to emphasize; I created it in ** 5 days **!!

    https://www.youtube.com/watch?v=_hRZnQCCKyY

    Here is more details about how it works;

    https://www.youtube.com/watch?v=lzRJGU2UrT0

    Here is the project (Open Source) - https://github.com/polterguy/sephia-five

    You can actually browse the history of the commits to the project, and verify how I created it in 5 days, by seeing how I refactored the code over time, and see for yourself how "design patterns eliminates problems".

    I am not aware of any other general purpose web application frameworks on the planet that could create such a thing, so rapidly, with such beautiful code, being so secure, scalable and "agile" ...

    Now if I can do that in 5 days, what do you think you could do in a month, after having learned P5 equally well as me ...? ;)

    Monday, March 27, 2017 7:55 AM
  • MS has been punked on this one.
    Wednesday, March 29, 2017 2:47 AM
  • What unsubstantiated crap.  

    Wednesday, March 29, 2017 7:24 PM
  • Miles,

    What "crap" are you referring to? That first YouTube video, yeah, that's a bit much. But the second one demos the product in a fairly appealing light. Do you think the product itself doesn't actually exist, or do you doubt the claim it was created in five days? (I have not tried to download it or run it...)

    To put it another way, can you substantiate your feelings of unsubstantiation?  *smile*

    Thanks,

    sutekh137

    Wednesday, March 29, 2017 8:10 PM
  • What unsubstantiated crap.  

    Is this "substance" for you ...?

    https://www.youtube.com/watch?v=3bEyBgI82OM

    Friday, March 31, 2017 5:44 PM
  • Thomas,

    Nice video, but I have to say you are not making a fair comparison, nor are the metrics you are comparing necessarily related to being "better" (regardless of what Google themself says about that).

    First of all, Sephia is running on a local server. So, any operation related to displaying an already-retrieved email is of course going to be very fast (is the email server also on the machine? client/server all in one? Then even faster, obviously). If you could somehow run all of GMail "locally", I bet it would be dang fast, too.

    Second, comparing Sephia to GMail is like comparing Notepad to Word. I have no idea what Sephia can all do, but can it check other POP mailboxes? Does it support labels and color coding? Can I hover over a message and have things like addresses pop out and offer an invite? Is there an IMAP-capable folder structure available, complete with integration to Google Drive? If an email has a tracking number in it, will a "Track Package" button appear?

    I've developed things like package tracking screens that use web services behind the scenes, and I can get and display results more quickly than if I were to use the carrier's web site. I've developed such tracking capabilities for several carriers, in fact, depending on whether or not they offer the ability to capture XML results that I can manipulate. And of course it is fast, because I parse the XML and display some meaningful results as text. It gets the job done. But it is fast because it is not nearly as feature-rich as using the carrier's web site. I've re-invented the wheel, a wheel with fewer bells and whistles that isn't bloated yet.

    I'm not saying Sephia doesn't look cool or that I don't believe you did it in five days. But It doesn't seem fruitful, to me, to compare it to GMail and proclaim it is 34 times "better". Notepad loads instantaneously for me while Word takes a second or two. I am sure if I could time to the millisecond how fast Notepad is opening it would look to be over 100 times "better" than Word. And it saves documents that are tiny in size compared to Word. A document containing basic text "Hello world!" is 12 bytes when saved from Notepad, and 11,342 bytes when saved in DOCX format from Word. By that measure, would you say Notepad is 945 times better than Word?

    Thanks,

    sutekh137

    Friday, March 31, 2017 6:06 PM
  • Thx Sutekh :)

    You're right in regards to "download time", but even ignoring that, it is 24-36 times "better", according to Google's metrics, which I find personally extremely funny myself ... ;) - As in, that these are Google's metrics ... :D

    If it really *is* better though, is probably open for arguments, I agree, but it definitely is possibly two of the most important criteria, there are few doubts about that. Check out Linus Thorvald's YouTube/Google talk about GIT, if you want a "second opinion" in regards to speed ...

    Linus argues that GIT, because of its speed, facilitates for a completely different way of "working", and a different "workflow", which I think Sephia too does, because of the same argument ...

    Re; "Notepad to word" - Yup, it is. Sometimes Notepad is superior though, in fact, a LOT of times Notepad is superior. At least, I think so, and I believe a lot of others agree with me there ... ;)

    Sephia can check any POP3 pox, and use any SMTP server. IMAP does not exist though. IMAP is something I don't even think I'll support, because I like the idea of having a "single view" (even sent messages are kept chronologically in the same "grid", which I think is supercool myself ... ;) )

    Re; "would you say Notepad is 945 times better than Word?" - Yup! But I am weird ... :D

    Thx for input, and remember, this is the first app, in an entire suite. Chat, file sharing (GDocs), etc, etc, etc - coming up. I might even get a sponsor (but can't speak any about it yet)

    Yet again, I'd like to emphasise, as I started with; These are Google's metrics, and the paradox is, that if you'd put GMail and Sephia into the SERP (Search Engine Result Page) - Then according to Google's algos, Sephia would be the first match, and GMail would be like "11th gazillion page" or something ...

    Google's definition of quality, not mine ... ;)

    Thx for watching it, thx for valuable feedback :)

    Friday, March 31, 2017 6:18 PM
  • In fact, let me ask you a question; How would you rather read a .txt file, Notepad or Word ...?

    How would you rather read your emails, in plain text view, or with colours, inline images, and tons of marketing jibberish, trying to make your screen look like a fruit salat ...?

    As for me; Notepad and text. I don't think I am alone.

    "Less is always more" -- Steve Ballmer, Oslo 2003 (something), launch of MS Server 2003 ... ;)

    He was running around on stage, in his usual way, shouting; "Less ir more!" - You just gotta love the fella ... ;)

    Friday, March 31, 2017 6:25 PM
  • Thomas,

    Nice to hear Sephia can access any mailbox (multiples, though?)

    But if the video is showing a case where the mailbox and client are both on localhost, it isn't a matter of what you consider comparable even despite functionality (because I will grant that sometimes Notepad is the right tool for the job). It's a matter of making a fair comparison. Comparing GMail to a locally running web app where the server and client are both local isn't fair at all. At the very least, put the server somewhere in the cloud and then do your timings again.

    I assume your local machine is very fast and has a swift SSD in it. High speed, low latency. You aren't going to have that same experience with a server in the sky. That would be like me running a fat-client Foxpro application where my data was across a WAN, and compare the speed against the same app running on a LAN (or local machine). Performance wouldn't even be close, and it would be disingenuous for me to use speed tests for meaningful conclusions in that scenario.

    Benchmarking is always tricky, that is why as many facets of the system as possible are made the same for the tools being benchmarked.

    Thanks,

    sutekh137

    Friday, March 31, 2017 6:32 PM
  • Thomas,

    As you can see from my other reply (we're crossing replies here), it is not as much about the functionality disparity as about the local server issue.

    But if you want to talk functionality, that's fine... I like being able to write meaningful sentiments when I am composing emails, documentation, or even short stories. Basic text won't work for me, in that regard. I need basic RTF capability. I don't use formatting as a crutch, I use it for meaningful communication. So, no, Notepad is not good enough for me most times.

    As far as GMail having lots of ads and such, well, of course it does compared to your locally running, homegrown solution. Same if I were to pay for corporate Gmail -- bye bye ads. So that shouldn't be lumped in with reasons to consider GMail bloated, etc.

    Thanks,

    sutekh137

    Friday, March 31, 2017 6:39 PM
  • Thank you :)

    Re; "But if the video is showing a case where the mailbox and client are both on localhost, it isn't a matter of what you consider comparable even despite functionality (because I will grant that sometimes Notepad is the right tool for the job)."

    Nope, it's actually using the same servers (smtp/pop - .gmail.com for both cases) - Which you can see, since the emails are the same. So the paradox, is that arguably, I've done a "EEE" on them, since you don't have to even switch email address to make the switch to Sephia ... ;)

    Both inboxes runs towards the same POP3/SMTP servers ... :)

    However, when it comes to the number of HTTP requests, and the download size, this is a mute point, since it is 100% neutral, regardless of whether or not Sephia is on localhost. These metrics, in isolation, shows Sephia to be between 24 and 36 times "better" ...

    Download size and HTTP request numbers are irrelevant of whether or not Sephia is on localhost. These would be the same, if I stuffed Sephia on the North Pole ...

    Re; "I assume your local machine is very fast and has a swift SSD in it"

    Yup, Mac Book Air, about 12 months old ...
    Yet again; This might be relevant to some extent, but not to the extent that it would affect HTTP requests and download size ...

    Re; "High speed, low latency. You aren't going to have that same experience with a server in the sky"

    True, but the download size, and number of HTTP requests, will be the *exact same*!! (yet again, 26-34 times "better") - And these will *drastically* affect the "speed" of loading your email inbox, even on a CPU and HD from the "last millennium" ...

    Re; "So, no, Notepad is not good enough for me most times." - Would MarkDown be sufficient ...?
    (Thinking about implementing it ... )

    Re; "As far as GMail having lots of ads and such, well, of course it does compared to your locally running, homegrown solution. Same if I were to pay for corporate Gmail -- bye bye ads. So that shouldn't be lumped in with reasons to consider GMail bloated, etc."

    I seriously doubt GMail stuffs 4.4MB of "ads" in my mailbox. Besides, I could profile it against me "GSuite" account, which I do have, at which point this would be a mute point. I suspect the numbers would be the same ...

    Try to forget the "download time", and realise the important comparison, which is the number of HTTP requests, and the download size. This is the exact same, regardless of where I put my Sephia server.

    Then remember, this stuff has PGP cryptography, GMail could probably never implement it, at least not without completely destroying the ability to search emails, unless you install GMail on your local network, at which point you're still not 100% certain about that your data is secured, since you wouldn't know what their code is doing, unless they open up their codebase to you, which would probably destroy their business model ...

    Try to forget about the "download time", and look at the number of HTTP requests, and download size in isolation ...

    https://blog.hubspot.com/marketing/reduce-http-requests#sm.00000p7c8if50defgysxt88lfln5h

    ...

    Thx for input ... :)

    PS!
    Let me know if MarkDown would "cut it" for you :)

    Friday, March 31, 2017 7:04 PM
  • For the record, in an equal server environment, due to the number of HTTP requests, and total download size, Sephia would perform between 24 and 36 times faster on initial page load, than GMail, discarding ALL OTHER PARAMETERS. Then imagine a "cheezy server", with a "cheezy connection", possibly running on your local internet connection, out of your home ...

    GMail simply won't cut it. Sephia would :)

    Friday, March 31, 2017 7:13 PM
  • Suggestion ...?

    https://simplemde.com/

    For formatting ...?

    Would this suffice ...?

    Friday, March 31, 2017 7:25 PM
  • Thomas,

    OK, I understand where the mailboxes are now... Still, if you were running the Sephia server somewhere else, would that not decrease speed a bit? Not due to size of data (since Sephia is indeed pulling down smaller amounts) but due to latency?

    When I mentioned ads I was not referring to them as being the cause of GMail's larger data pull. I just meant that while ads suck, I do find GMail very functional, more functional than what I see in Sephia (though I do think Sephia's take on viewing and replying to emails, that scrolling workarea idea, is nifty). Like I said, can I track packages directly from an email header line in Sephia? That undoubtedly means GMail pulls more down, but the result is a richer interface that can do more without subsequent calls. It's just pre-loading more stuff. Whether or not that stuff is useful to a majority of folks has nothing to do with a performance comparison discussion. One simply cannot compare apples to apples without knowing what the extras are that GMail downloads and whether or not those extras lead to a better user experience for a lot of people. The same goes for transactions. If more transactions create a more functional client-side view into email, then it doesn't matter if it uses more. For example, what if an email client used more transactions to pull down the first few lines of every email to act as a preview? That's more functionality. It doesn't matter if a user thinks, "Previews are dumb!", what matters is that these are interface design choices -- not hard and fast performance comparisons. Every application has to make trade-off decisions on when to pull data down, how to cache things, when refreshes are required, etc.

    Let's get back to Active Events, though... Run-time performance metrics have NOTHING to do with AE. AE is a design pattern that aids in speeding up design time. By all accounts, it has to be slower than not using it, because of the overhead based on the design idea (reflection, etc.). What if you had created the programming for Sephia using standard, stronger-typed C#? Wouldn't it be even faster, even if it took a lot longer to build?

    To put it another way, putting run-time performance statistics on display on a thread about a design-time model doesn't make the two of them related. I realize you wanted to post something of "substance" to show your results are real, but if we bring the discussion back to AE, comparisons to GMail don't really matter. A better comparison would be to ask how long it took them to develop GMail's front end, but that question is a bit harder to answer. *smile*

    Thanks,
    sutekh137
    Friday, March 31, 2017 7:44 PM
  • Thomas,

    You can stop looking for a "right-sized" editor for me -- I am completely happy using Word for advanced documents, Visual Studio's and Visual Foxpro's own IDEs for coding, and Notepad++ for pure text.

    And for doing "real" work, nothing less than Word will suffice for me. Why is that? Because I can automate Word via COM. We do a ton of Word automation, and even more Excel automation, both from Visual Foxpro and .NET.

    Kind of hard to do that with Notepad, and I'm not reinventing that particular wheel. I gave up on that sort of idealistic desire for efficiency back in my twenties... These days I just need to get shit done without wringing my hands over whether or not I am using the perfectly-sized tool for the job.  *smile*

    Thanks,

    JoeK

    Friday, March 31, 2017 7:50 PM
  • Re; "Still, if you were running the Sephia server somewhere else, would that not decrease speed a bit? Not due to size of data (since Sephia is indeed pulling down smaller amounts) but due to latency?"

    Not anymore than it would decrease the speed of GMail. All other parameters set aside, they would perform according to download size, and their number of HTTP connections, since each connection carries a fixed overhead, per connection.

    So basically, running the same HW, and connection, Sephia would perform 26-34 times better ...

    Re; "I do find GMail very functional, more functional than what I see in Sephia"

    Of course, but Sephia a young project ... ;)
    This was my first release, v0.5, give it a couple of versions, and I doubt you'd miss anything ... ;)
    Without adding significantly to the bandwidth ...

    Re; "that scrolling workarea idea, is nifty"

    Thx, imagine on an iPhone or Android, how much more versatile this is, than GMail's "single email" solution :D

    Re; "That undoubtedly means GMail pulls more down, but the result is a richer interface that can do more without subsequent calls"

    I am almost 100% certain of that I could mirror all features of GMail, without significantly adding to the bandwidth, or HTTP requests ... :)

    Re; "For example, what if an email client used more transactions to pull down the first few lines of every email to act as a preview?"

    Such things, could possible explaing maybe an increase of 50% from Sephia's point of view, but not 3400%. The latter, I suspect, is simply "bad coding" ...!! :P

    Re; "Run-time performance metrics have NOTHING to do with AE. AE is a design pattern that aids in speeding up design time"

    Yes, and not. If you can abstract away your code, to a level, at which it is more maintainable, it becomes more difficult to create "bloat", which I highly suspect GMail is the result of ...

    Re; "By all accounts, it has to be slower than not using it, because of the overhead based on the design idea"

    In theory you're right, in practice though, which I think this example of Sephia perfectly illustrates, the opposite is your practical result ...

    Re; "What if you had created the programming for Sephia using standard, stronger-typed C#? "

    Then it would highly likely have been bloated.
    Hint; Try checking out this video; https://www.youtube.com/watch?v=-FL_rYd6KZY

    It demonstrates 2 libraries built in C#, and a third library built in JavaScript. P5 outperforms all of these 3 libraries by more than one order of magnitude (10x, in fact, on some parameters 276 times!)
    Two of these are built in C# ...

    Re; "Wouldn't it be even faster, even if it took a lot longer to build?"

    Yet again, in theory you're right, but in practice it always goes the "unintuitive direction", due to a much more easily maintained codebase. I suspect that what happened with GMail, was that they lost control over their codebase, and the project became unmaintainable. With P5, you can build much more complex projects, before they reach the same critical level ...
    There are simply not one reason on this planet, why a web mail program (GMail) could possibly justify spending 4.4MB of bandwidth, unless it was ipso facto so bloated, that the developers had lost all control over it themselves ...

    Re; "but if we bring the discussion back to AE, comparisons to GMail don't really matter"

    Yes, and no, see above comments :)

    Re; "A better comparison would be to ask how long it took them to develop GMail's front end"

    Hehe, I rest my case :D

    Friday, March 31, 2017 8:19 PM
  • Re; "These days I just need to get shit done without wringing my hands over whether or not I am using the perfectly-sized tool for the job"

    Hehe, I actually love FoxPro for the record :)

    But I prefer Xamarin Studio for Visual Studio, because it's *slick* (hint hint Microsoft ;) )

    Friday, March 31, 2017 8:20 PM
  • Thomas,

    At this point in a discussion, I so often find that conflation makes it hard to keep accurate communication going. And I think you are conflating several things.

    I do not feel any design methodology or underlying language equates to bloat. In fact, I think it is approaching ridiculous to say Active Events preclude bloat while using straight C# would add to bloat. That is like saying if I wrote something in assembly language I would have more chance at bloat than using Visual Foxpro. That is patently untrue. How can using AE in C# be less-bloatable than using straight C#? Why would I bloat something more because I am using a potentially LESS refined (as in, no) methodology in straight C#? Most bloat, after all, comes from functionality-creep not design-creep. Word isn't "bloated" because of bloated design choices -- it is bloated because it tries to do so much. If there is bloat in the code beyond that it is simply due to age -- and your code is going to get old just like everyone elses. Active Events aren't some magic bullet that will prevent the normal "bloat over time" that all projects see as design choices are re-jiggered and code is refactored and functionality is added.

    Bloat comes from design choices. I can write succinct code in Foxpro and C#, and I can write bloated code in Foxpro and C#. One language is weakly typed and the other is stronger in that regard. Makes no difference.

    If you took all of your Active Events and coded them as straight C# with standard, strongly-typed parameters and conventional method calls, not adding any actual code to it (because why would you have to? You can still write reusable, modular, well-factored code without using any "official" design patterns), how could that possibly end up slower or more bloated than your Active Event code? As I said, it would perhaps take you LONGER to write it in straight C#, but I fail to see how it is a "yes and no" situation with regard to performance -- it's just a "yes" -- the non-AE code will be faster. If you decide to bloat it all to heck for some reason when using straight C# (and I am talking performance-hitting bloat -- not more lines of code. More lines of code does not automatically mean something will run more slowly), then that's the developer's problem and has nothing to do with the tools in the toolbox.

    To put this all another way, what you are saying feels akin to saying Python is faster than straight C because it is more advanced from a design perspective, therefore it will have less "bloat" than C. Would you say that is true? That Python is "faster" than C at run-time? I appreciate that a well-designed algorithm will always trump basic code optimization, but one can write a smart algorithm in C the same as in Python; it will probably just take longer.

    Overall, I feel like you are also conflating design speed with run-time speed, and I believe those two things have absolutely nothing to do with each other. If they do relate in any way, the trade-off is more certainly in that faster design = slower run-time. It's your basic TANSTAAFL argument -- you can't get something for nothing. Assembly is fast but hard to work in. Byte-code languages are more portable and quicker to code in, but perform worse. Any other talk of gains is going to be based on algorithm, not language. But you could code your base algorithms in C# if you wanted to -- it would just take longer.

    Thanks
    JoeK
    Friday, March 31, 2017 9:06 PM
  • Re; "How can using AE in C# be less-bloatable than using straight C#?"

    Because you're not building "applications", you're building atomic building blocks, which you incrementally build more and more complex building blocks on top of, creating more and more complex abstractions, which you later "orchestrate" together to become your applications.

    Some would argue this is also true for all other OOP languages. However, the degree to which this is possible with AE, is not something I have seen before.

    Re; "Word isn't "bloated" because of bloated design choices -- it is bloated because it tries to do so much"

    Yup, imagine if you instead of word, had millions of small components, you could assemble together as you wanted to, to your exact needs, whatever they were? This would mean you could customise your own installation, and word wouldn't have to "solve everything, to please everyone". This is how the universe works, atoms. This is also how biology works, cells. Code does not work that way, at least not historically. AE mimics this way of thinking, due to its extreme amount of modularity.

    In fact, Sephia works like this. The "action buttons" for both "respond to email", and "compose email" are plugins. If you'd like to have your own "rich editor" button, for creating "rich text email", that would simply be a plugin in fact, and not change the core parts of Sephia at all in fact!

    Even the settings, and many other aspects, are pure plugins, and configurable, meaning not two installations would be exactly the same. AE facilitates for heterogenous applications, where there wouldn't exist two exact similar systems, from a code perspective ...

    Re; "One language is weakly typed and the other is stronger in that regard"

    This doesn't come from the fact that it is weakly types, but rather from its extreme emphasise of modularity. Where, arguably, weakly typing is a pre-requisite, but not what makes the bullet "magic" ...

    Re; "To put this all another way, what you are saying feels akin to saying Python is faster than straight C"

    Python doesn't as far as I know have the modularity that AE has ...
    Feel free to correct me, if you know that I am wrong here though ...

    Re; "but one can write a smart algorithm in C the same as in Python"

    Yes, but can you orchestrate your algos together, from a higher perspective, re-using your "if", "else" and "while" lambda blocks ...?
    I could, by using automated processes, "copy" an IF statement, from one "function", and literally "paste" it into any other "function" with Hyperlambda ...

    Re; "Overall, I feel like you are also conflating design speed with run-time speed, and I believe those two things have absolutely nothing to do with each other"

    Maybe we're discussing two different things ...?

    Ask yourself this question; Why isn't the Universe "bloated"?

    Or; Why isn't your body "bloated"?

    Both of the above, are arguably far more complex "systems" than any SW system we have ever built ...?

    We both intuitively know the answer to that question though, which is that both the Universe and your body is composed out of "atomised building blocks", through the mechanisms of "evolution". P5 facilitates for both of these axioms ...

    Re; "Assembly is fast but hard to work in"

    Yup, but try to add features to (arguably, any) system with 50 millions lines of code, and you will experience you'll end up with 500 different qsorts implementations (Windows NT had this problem for the record, according to the source code, that was leaked about 10-15 years ago on file sharing networks, in addition to alot of curse words, in its comments, due to developers trying to balance fixing bugs, with not being able to remove bugs, because some 3rd party software was depending upon that these bugs existed in the Windows kernel, to be able to adequately work)

    In AE, there can never exist a system with more than 20.000 lines of code, it would simply not be possible. What could exist though, is a system created with a million "building blocks", where each "building block" rarely if ever exceeds 1.000 lines of code. This is how your biology works, and this is the best way to create extreme scalability ...

    The whole idea with AE, is to stop thinking in terms of "projects", and start thinking the same way God was thinking, when God created your body ... ;)

    Cells, atoms, molecules, modularity and reproduction of these "modules" - With small iterative changes applied, for every iteration ...

    It sounds like voodoo, I know, but it's actually not that hard. Check out this for instance, which is "refactoring" Sephia, to extract all commonalities, which I will be needing in other projects later ...

    https://github.com/polterguy/camphora-five

    So far it only contains a "pager/filter" toolbar, plus a "legend help text widget" - But after some more work, I will probably have extracted 50% of Sephia out, to this component library, implying my next project, is already 50% done, before I even start coding a single line of code in it. When I later refactor or create bugfixes in Camphora, I inevitably refactor and create bugfixes for potentially hundreds of projects ...

    There's a reason why I use the analogy of "atomising your components" in the article ... :)

    Friday, March 31, 2017 10:40 PM
  • PS, check out this link, which seems to be legit, explaining what's the stake here ... :)

    https://mincss.com/

    Saturday, April 1, 2017 8:00 AM
  • Thomas,

    If I heeded the advice of every developer/vendor telling me what I needed or else the sky was going to fall and I was going to lose billions of dollars, I'd never have completed a single application in my life. I'd be too busy shelling out fees for third-party tools and changing architectures every time someone told me the current state of development was in dire need of overhaul and only their new and shiny toolset/paradigm could save me. been around the block WAY too many times to think anything under the sun is truly disruptively unique.

    I'd rather develop solutions using the tools that work, deploy them, and move on. As far as I can tell, my company isn't losing millions of dollars because I didn't refine a process I wrote to take only 1 second instead of 1.1. To say anything is truly "at stake" here is probably a bit melodramatic for about 90% of the programmers reading this. That's my perspective, anyway

    Thanks,

    sutekh137

    Monday, April 3, 2017 3:35 PM
  • Thomas,

    I think things like the Universe and human life are pretty nifty, for sure. That being said, I cannot fathom assembling enough atoms properly to create even the simplest piece of matter in the cosmos. Arranging atoms is for gods, not programmers.  *smile*

    I see your point, though. To me, all of this reduces to a modularity paradigm (one which you think is new and perhaps even revolutionary, though I disagree with that). Sure, I can write all of my code such that the smallest piece of functionality is a call to a smaller bit of code. But at some point I am going to be spending just as much time assembling the atoms as I am creating the atoms. Is there really a gain in that? Perhaps, especially as a developer framework.

    But people have been developing frameworks since the dawn of computing, and their advantage has never been clear to me. I code in Foxpro, and everyone always used to say, "You gotta get a framework! Development will be so much faster!" This was demonstrably false in every case I pursued it. I've seen "atomized" systems before. I've seen object/inheritance hierarchies with so many classes and property settings that it would take me days just to build a "Hello World!" application using the "framework way". I actively eschew such development paradigms at this point. I am all for modularity, and use it well and regularly. But my building blocks, compared to your atoms, are big ol' molecules. I don't even make a separate "cs" file for every class I create in C#! The HORROR! I make decisions on what things should look like, and I don't lose sleep over whether or not one user really needs a different button on the screen than someone else. That's the big part of development (especially in custom business software on the desktop) -- deciding what works for everyone, or at least works well enough.
     
    As Alan Cooper put it in his book "About Face" (I am dating myself a couple decades into the past on that one), I try not to put "might" before 'when". Trying to account for everything the end-user (or developer) might want to do over what they are actually going to do 95% of the time means you end up with an overly-detailed (or overly-modularized) code base that might very well be harder to learn than to simply implement a solution using what you already know. To put it another way, you've developed a new programming language, not just a new design pattern, but I haven't seen anything that makes this new language any better than learning the ins and outs of the .NET libraries, Java libs, or Python includes (just to name a few of the dozens of frameworks out there). And as your product matures, it will undoubtedly have more complexity to it; even, dare I say, "bloat." No language or design paradigm that becomes used by thousands of people has ever stayed supremely lean and perfectly modularized. If there is, I'd love to hear about it...

    And perhaps what I hear about will be Active Events and HyperLambda in 5-10 years. I would genuinely enjoy seeing that! Good luck to you, and thanks for the article and discussion!

    Thanks,
    sutekh137

    PS. As for whether or not the human body is "bloated", I'd say there are lots of things that are over-designed, under-designed, or just poorly designed in the human body. That's just a matter of opinion. The human body has evolved to survive, no more no less. I don't find anything about my body particularly "elegant" or perfectly modularized. Maybe that's just me. *shrug*

    Monday, April 3, 2017 4:03 PM
  • Re; "If I heeded the advice of every developer/vendor telling me what I needed or else the sky was going to fall and I was going to lose billions of dollars, I'd never have completed a single application in my life"

    Hehe, Google Joel Spolsky "Fire and Motion", I think it's still around there somewhere ... :)

    The thing about Sephia (and also P5), is that it's created to allow for "micro servers", among other things. Which means it'll work if you deploy it on a web server the size of your palm, running on your local home internet connection, possibly with no more than 1-5MB upload bandwidth.

    This feature just so happens to also imply that it performs orders of magnitudes faster on "huge" servers, where the clients have low bandwidth, or for that matter also where the clients have huge bandwidth ... :)

    Hint; I spend 12 seconds downloading GMail on a 50MB connection here, before it's completely finished loading, if I empty my cache ...

    The same numbers for Sephia, on an external connection, would be a couple of hundreds of milliseconds ...

    But I totally 100% agree with your basic assumption, it's really nothing but madness in fact. However, every now and then, a truly brilliant innovation do actually come along ... say no more ...

    Anyways, I've optimised Sephia for the record (yup, I hadn't even started optimising the thing in my last video), and now GMail uses 440 times as much bandwidth, at its worst case scenario. And 40 times more bandwidth on the best case scenario. Check it out if you like, I've also done something in regards to design issues, and I am working on creating PGP keys internally within Sephia, not having to bother about GnuPG anymore ... :)

    In addition, you can still keep using your GMail email address ... :D
    (EEE anyone ...? ;) )

    https://www.youtube.com/watch?v=lmq5eXbk7us

    Tuesday, April 4, 2017 11:02 AM
  • Re; "Good luck to you, and thanks for the article and discussion!"

    Thank you :)

    PS!
    You don't "build atoms", you "consume atoms", to "build molecules", increasingly more advanced, by composing atoms, and other prebuilt molecules together, to such end up with higher and higher abstractions.

    Some of our molecules in our body, contains millions (if not billions) of atoms. DNA for instance ...

    Then as you create "molecules", you can create more and more complex "molecules" by assembling together existing "molecules". Arguably, the human body is only one "molecule" - DNA ... :)

    Tuesday, April 4, 2017 11:07 AM
  • I read the article recently and although I encourage controversy, I formed the impression that this article and its presentation was superficial in nature.

    In addition there is no formal definition of what an OO Language actually is only vendor/language specific principles, so criticizing such languages is also somewhat informal and imprecise.

    All I picked up was that a general purpose method "Raise" becomes the only method used between "components" and the author didn't even define "component". 

    Yes, we have a single signature method "Raise" but the structure of the node argument that is passed varies - so rather than having method signatures vary we have the argument structure vary, and so the caller must be intimately aware of that expected structure, sounds like tight coupling to me.

    Also why identify the operation with a hard coded string? why not simply an integer? what if a vendor gives some operations the same name, same ID as another vendor?

    OO problems are deep seated and include mutability, verbosity and the ease with which we can reason about code. We are often reminded about how mutability is a bad thing yet the C# language (and Java etc) actively encourages it through its semantics.

    We're told to use an OO langauge like C# but then told "dont make objects mutable" and "dont use a loop for that use LINQ" and so on - so why use a language like C# that offers features and then add all these rules about not to use some features! The author says nothing about mutability or anything and so seems like more of a whine about the mechanisms of method invocation than anything else.

    Frankly the most impressive way to address OO weakness is to abandon OO and move to functional languages like F#, the article below makes this argument far more robustly than the MSDN article.

    OO is an expensive disaster.

    Korporal.









    Thursday, April 6, 2017 4:01 PM
  • Re; "All I picked up was that a general purpose method "Raise" becomes the only method used between "components" and the author didn't even define "component". "

    Raise; https://github.com/polterguy/phosphorusfive/blob/master/core/p5.core/ApplicationContext.cs#L149

    Registering assemblies; https://github.com/polterguy/phosphorusfive/blob/master/core/p5.core/Loader.cs#L120

    Re; "so the caller must be intimately aware of that expected structure, sounds like tight coupling to me"

    Tightly coupled the same way an XML parser is tightly coupled. Pass anything but XML into it, and it chokes. Pass anything but a Node into an Active Event, and it chokes.

    Example; https://github.com/polterguy/phosphorusfive/blob/master/plugins/p5.lambda/keywords/core/While.cs#L41

    Re; "Also why identify the operation with a hard coded string? why not simply an integer? what if a vendor gives some operations the same name, same ID as another vendor?"

    Because a string is humanly understandable, and there are few advantages, if any, to using an integer, since internally it's an O1 operation looking up a string in a dictionary.

    Re; "The author says nothing about mutability or anything"

    Everything is mutable in the Node structure. In such a way, it arguably becomes the "anti-functional" programming language of the world (Hyperlambda that is). Some people, especially F# people, will dismiss it immediately, for no other reasons than that, without investigating it, because they love the idea of immutable objects.

    Re; "o seems like more of a whine about the mechanisms of method invocation than anything else"

    Nope, if it is "whining" about anything, it is whining about encapsulation, polymorphism and cohesion, in relationship to strongly typing ...

    Do you use JavaScript ...?

    JavaScript suffers from the exact problems as Active Events, without featuring the modularity features of Active Events ...

    Friday, April 7, 2017 6:38 AM
  • Made with P5 :)

    https://gaiasoul.com/2017/08/28/phosphorus-five-secure-your-emails-with-pgp-cryptography/

    Monday, August 28, 2017 2:57 PM
  • Active Events is a design pattern that enables encapsulation and polymorphism. It allows you to separate concerns by creating extendable, reusable components that can be assembled almost as if they were Lego pieces.

    Read this article in the March 2017 issue of MSDN Magazine

    I have to be honest I read the article when the magazine issue arrived. I'd recently been studying quite deeply into F# and functional languages in general so these were on my mind as I was reading.

    I didn't read the article in great detail I admit but did feel underwhelmed a little, not able to see clearly what problem it is striving to solve, I may have misjudged it however.

    The author seemed to be concerned with "loose" coupling but didn't strictly define the different between "tight" and "loose".

    What I'd like to see is a simple example app, with two versions - one not using his techniques and the other using them, then I could contrast the two examples.

    The idea of looking up a function/method by name is hardly revolutionary, so I wonder am I missing something deeper?

    Korporal.

    Wednesday, August 30, 2017 7:30 PM
  • To understand the benefits of Active Events, requires using analogies unfortunately. A good one, happens to be pipes from Unix, which arguably was the "brilliance" in Unix. Meaning, the ability that everything could be "chained", such that one "thing" could react upon the output on another thing. Active Events work the same way, allowing everything to be chained together, using another event's output as input.

    In fact, I created a Turing Complete programming language with the above chaining technique, called "Hyperlambda".

    I realise that it is a learning curve, and that it is difficult to see its advantage, especially compared to dependency injection, which seemingly solves the same problem. However, it doesn't. For instance, here's an example; If I wanted to, I could serialise an Active Event invocation, or a "chain" of such for that matter. Then I could pass on the serialised invocation to for instance a web service. This would allow me to invoke a web service, passing in a lambda object, where the client is responsible for supplying the "code" that is executed on the server. If this sounds like magic, realise I have already solved this particular use case, which you can see an example of in the video below.

    https://www.youtube.com/watch?v=qFqhAQEAbEo

    Another example is serialising a "lambda object" into a database, this actually describes the "CMS" I built, which allows the users to create "interactive CMS pages", instead of just static HTML pages, where the pages contains logic, and interactive widgets, doing whatever you wish to do.

    To be honest with you, I haven't really studied dependency injection that much, since I have been exclusively focusing on my own research, for a very, very long time. However, I think the comparison becomes that of between apples and pears ...

    Thx for intelligent questions :)

    What would Active Events look like in a functional language? for example F#? 

    F# inherently support pipelines, where sequences are consumed and transformed and filtered and passed on to other stages, it is inherent in functional langauges at a deep level far more than imperative languages like C, C#, Pascal, Java etc.

    Here is a very good article about this.

    Basically is Active Events simply addressing some limitation of C# or is it more profound, deeper and could play a role in functional languages too?

    Wednesday, August 30, 2017 7:35 PM
  • I do find this very intriguing, and I applaud the author for writing it and the editor for publishing it. The author decries the overhead in the current state of OOP and has found one way to address it.

    But I am wondering the same thing as others: Does this promote loose coupling better than traditional IoC, or does it only manage to turn easily-caught design-time errors into runtime errors?

    I also wonder how well Active Events would work in teams. The article states: "...no signatures or types need to be known and shared between the consumer and the implementation of an active event." But of course they still have to be known and shared between members of the team for the code to work. So you're still stuck writing an "interface" of sorts, though it's an informal one that gets emailed to a colleague instead of declared in code. (Making it formal would just be re-inventing the interface, right?) And my fear is that the informal information sharing would be more prone to human error, amplifying the lack of design-time & compile-time checking.

    It's very cool that the author has had success with this approach, and I agree with him that the problems with the current state of OOP make it ripe for another approach to gain traction. But as a fan of strong typing and its benefits, I don't know that I'm convinced to move away from that just yet. Devs with deep roots in JavaScript may feel differently!


    The problems in OO are indeed noteworthy (here's a particularly critical article), the most radical alternative seems to be functional languages, very very different animals. As I say above the article I read about Active Events didn't make a huge impression, it just seemed to be a dyanamic indirection of methods based on string names, but I admit I did read it fairly quickly.


    Wednesday, August 30, 2017 7:39 PM