.NET - Create Your Own Script Language with Symbolic Delegates RRS feed

  • General discussion

  • Tired of the complexity of modern programming? Thomas Hansen is. In this article, he presents a home-brewed scripting language for .NET called Lizzie that uses symbolic delegates--a C# design pattern based on looking up delegates from a dictionary using strings as keys.

    Read this article in the November 2018 issue of MSDN Magazine

    Thursday, November 1, 2018 6:10 PM

All replies

  • Surprised this article didn't get more (or any?) attention on here.  The scripting mechanism is a neat idea but the paragraph at the end seemed, at least to me, to be the most pertinent. 
    Wednesday, November 14, 2018 5:39 PM
  • Thank you Quanta for the nice words :)

    My experience though with these kinds of things, is that people tend to for the most parts only comment when they disagree with something. When what I write/speak about are things they already agree with, fewer tends to comment. In such a regard, I should probably declare the lack of comments as a success ... ;)

    In my 3 previous articles, I wrote about something that was "controversial", and arguably "passe technology" (web forms). At which point my articles generated many comments, most of whom were in disagreement with me. With Lizzie, I in comparison made much more "likes" on the project site, and in fact, it's been the Open Source project I've created that generated the most interest for the least amount of effort, like *ever*. At the same time, it also seemed to be the project generating the *least* amount of comments and hence objections ...

    In a weird way, these things are the way they should be I guess ...

    Yet again, thank you for your nice words :)

    Friday, November 16, 2018 8:09 AM
  • I very much appreciate the insight about a delegate acting as a powerful programming construct -- I definitely need to do more playing around with Actions (and just functional programming in general).

    Hopefully this isn't just a re-hash of the commentary concerning Hyperlambda and P5, but I'm not quite grokking the following from the article:

    "This property of Lizzie allows you to create a generic HTTP REST endpoint where the client layer sends Lizzie code to your server and where it’s then evaluated. You can then have your server create a JSON response that it sends back to your client. And more interestingly, you can implement this securely. You can implement a single HTTP REST endpoint that accepts only POST requests containing Lizzie code, and literally replace your entire back end with a 100 percent dynamic and generic Lizzie evaluator."

    I mean I get it, I understand how nifty it might seem to build a single-endpoint API, but aren't you just taking the complexity of the API and pushing it all the way to the caller? Worse, the calls need to be made with ugly (in my opinion) syntax and string generation, with zero help from Intellisense or the compiler. What if my string has an error in it? I have to wait for an error code in the returned JSON? A well-crafted API with C# object wrappers seems much easier to use.

    To put it another way, the Lizzie idea might very well reduce the documentation on the underlying methodology to make calls (e.g. framework docs), but the documentation for the calls themselves (the Lizzie strings) is going to have to be an order of magnitude more robust compared to something that is documented inline (and strongly typed) such that Intellisense can provide documentation where it is needed the most, and the compiler can warn when something looks like it isn't going to work.

    I am all for simplicity, but the idea of creating a single-point API seems to be shifting the complexity around, not eliminating it. Maybe that is because I don't consider current architecture to involve 6 tiers, and do not feel overwhelmed by the choices of frameworks out there. Use what you need, and forget the rest. Things aren't getting more complex, per se, they are simply growing wider in scope as cloud computing and connectivity start to touch more and more aspects of human existence. I don't think programming is eventually going to become impossible if we keep going this route, because the next generation of architects will be standing that much higher upon the shoulders of those giants who came before. Might growing complexity eventually overwhelm those of older generations? Sure. But that's been happening in all professions since civilizations reached the point of occupational specialization.

    As always, though, thanks for the new ideas and different perspective! 



    PS. Did you ever have that programming contest? Can't recall who with and what the topic was exactly, but it sounded like something was supposed to be going on...

    Friday, December 28, 2018 9:20 PM
  • "but aren't you just taking the complexity of the API and pushing it all the way to the caller?"

    Yes I am. However, to understand its benefits, imagine "GraphQL on steroids". With GraphQL you are left with the ability to retrieve data (more or less) - With Lizzie, you can invoke strongly typed, C# extensions, on the server, allowing you to do much more. To give you an analogy, imagine the server as a "dumb database", and nothing else. Then add the ability to (easily) create stored procedures in C#, which can use the entirety of the .Net Framework (or .Net Core) - Including all those millions of beautiful libraries, solving every single task, ranging from BouncyCastle (cryptography) to parsing MIME (MimeKit) and sending emails (MailKit).

    If GraphQL is the equivalent of "SQL", Lizzie is "turing complete 'stored procedures' + SQL".

    "with zero help from Intellisense or the compiler"

    Actually, there's a guy (or gal?) claiming he's in the process of "porting" Lizzie to TypeScript. You can probably contact him (or her) over at the Lizzie "Issues" section at GitHub :)

    "A well-crafted API with C# object wrappers seems much easier to use"

    Yes, it is. But a C# class is the equivalent of a "sculpture made out of stone". After it has been created, modifying it to do something else, requires a much more complex process. While Lizzie is more like "clay", you can always change it to do something else. Hence, arguably, Lizzie "puts Agile into C#."

    "To put it another way, the Lizzie idea might very well reduce the documentation on the underlying methodology to make calls"

    Actually, in theory, you could take it even further, and create a single "database" (server-side), with a multitude of completely different "applications" (client-side Lizzie code) on top of it. In theory, you could bring this so far, that you create one simple "Lizzie server", that allows you to create any applications you would ever need to create, on top of this "Lizzie server", and declare your data structure (db-scheme) in a simple configuration file on your server. If you go down this route, you've completely eliminated the need to ever again do any server-side programming EVER! Effectively eliminated (at least) 50% of your development costs ... :)

    "is going to have to be an order of magnitude more robust compared to something that is documented inline (and strongly typed)"

    Weakly typed code has a cost, and it has gains. The question becomes are you willing to pay the cost, to experience the gains? For strongly typed solutions the cost is "static rigid code, that is 'impossible' to change on the fly". Weakly typed code has the cost of "less security since the compiler catches fewer errors for you."

    If you're OK with paying the cost, and the gains are what you're looking for, then my answer is "choose what you feel OK with choosing, according to the problem at hand."

    The following quote comes to mind; "To a man with only a hammer, everything looks like nails."

    Some people are OK with only using hammers, and in fact entire professions are based upon the beliefe of that "everything is a nail."

    If you happen to have a "screw in your pocket though", I might have a tool for you that better solves your problem ... :)

    And yes, I did the programming contest thing. There's some information about it over at my blog. Look for "InGen" or "dinosaurs", and you'll find it.

    Thank you for your very valid feedback. And yes you are right. However, just because you are right, and I happen to propose something that's not "down your alley", doesn't imply that I am wrong. That's the beauty of nature, its pluralistic nature, where different ideas can co-exists side by side, and solve different problems :)

    But as I do explicitly start out with, "sometimes I like to live dangerously". Lizzie is arguably dangerous.The question you should be asking yourself though is; "Do I need the flexibilities that it brings to the table."

    An estimated and qualified personal guess from me would be; "Yes! **Sometimes**!"

    Friday, January 4, 2019 10:51 AM
  • Thomas,

    I certainly never meant to imply that you were wrong about anything, so if I did, I apologize (though I don't think I did).

    I agree that it is all about ROI and the upside/downside ratio, and as you know from my Visual FoxPro background, I have great respect for more dynamic languages (and am comfortable with analyzing the push and pull of compile-time errors vs. run-time errors).

    The methodologies put in place here are definitely worth of placing into the toolbox in order to properly handle nails, screws, and whatever else comes our way, so your ideas are appreciated.

    I'll go check out your blog. Have a great 2019!



    Friday, January 4, 2019 3:11 PM
  • "I certainly never meant to imply that you were wrong about anything, so if I did, I apologize."

    I didn't think so either. But since these comments are (probably) also read by others, I wanted to re-iterate my thoughts explicitly none the less, to avoid confusion for others reading it. I think we in general terms agree on most parts it seems :)

    Saturday, January 5, 2019 10:35 AM
  • This is a thought provoking article. Of course the symbolic delegates and Lizzie are interesting. More interesting is the thought behind them. As the profession gets more complex, there will be specialization. So far the specializations in the industry are always around the programmer but with complexity the specialization will be inside programming staff also. Specialists become costlier with time leading to expensive software.
    Saturday, February 9, 2019 6:05 AM
  • Thank you Ravich. There is an overarching idea behind everything I do, create, and write - And yes, hopefully my ideas are thought provoking, since according to my Zeitgeist, provoking thoughts are desperately needed in these days in our profession.

    500 years ago, our "predecessors" built stunning cathedrals, out of literally sticks and stones, whom we today admire and ask ourselves "how?" Today we struggle with creating "Hello World", due to the amount of complexity that has been driven into our work, under the assumption of that it would ease our job, while the effects became for all practical concerns the exact opposite.

    Ask yourself "what was the reasons for the internet's success". I for one see it as a "data channel". It features no "strongly typing", zero "OOP", no "design patterns", etc - Still, it's the by far most massively successful and scalable idea humanity has ever had. Let's do the same with our code internally within our servers and clients, and maybe we'll experience similar results there too ...? :)

    "Data in, data out - Everything else is tricking ourselves to believe in that which does not exist"

    Thursday, March 7, 2019 7:20 AM