Page 43 - MSDN Magazine, November 2018

Lizzie code, and literally replace your entire back end with a 100 per- cent dynamic and generic Lizzie evaluator. This allows you to move your entire business logic and data access layer into your front-end code, such that your front-end code dynamically creates Lizzie code that it transmits to the server for evaluation. And you can do this securely, assuming you authenticate and authorize your clients before you allow them to evaluate your Lizzie code.
Basically, your entire application is, all of a sudden, easily built in JavaScript or TypeScript or ObjectiveC or whatever, and you can build clients in whatever programming language you like that dynamically creates Lizzie code and send this code to your server.
Lessons from Einstein
When Albert Einstein wrote down his famous equation to explain our universe, it had only three simple components: energy, mass and the speed of light squared. That equation could be easily under- stood by any 14 year old with a decent grasp of math. Understanding computer programming, on the other hand, requires thousands of pages and millions if not trillions of words, acronyms, tokens, and symbols, plus an entire WikiPedia section on paradigms, numerous design patterns, and a multitude of languages, each with completely different structures and ideas, all of which require “crucial” frame- works and libraries you need to add to your “solution” before you can start working on your domain problem. And you’re expected to know all these technologies by heart before you can start refer- ring to yourself as an intermediate software developer. Am I the only one who sees the problem here?
Lizzie is not a magic bullet, and neither are symbolic delegates, but they’re definitely a step in the direction of “20 GOTO 10.” And sometimes, in order to move forward, you need to start by taking one step back. Sometimes you need to neutrally observe yourself from the outside. If we, as a professional community, do that, we just might realize that the cure for our current madness is sim- plicity, and not 50 more design patterns, 15 new query languages, 100 new language features, and a million new libraries and frame- works, each with a trillion moving parts.
Less is more, always, so give me more less, and less more! If you want less, join me at github.com/polterguy/lizzie. That’s where you’ll find Lizzie, with zero type safety, no keywords, no operators, no OOP, and definitely not as much as a single library or framework in sight.
Wrapping Up
Most of the computing industry tends to disagree with most of my ideas. If you asked the average software architect what he thinks about these ideas, he’d probably throw entire libraries in your face as sources to prove how wrong I am. For instance, the preva- lent assumption in software development is that strong typing is good and weak typing is bad. For me, however, simplicity is the only game in town, even when it requires throwing strong typing out the window. Keep in mind, though, that ideas such as Lizzie are intended to “spice” up your existing statically typed C# code, not replace it. Even if you never use the coding ideas presented in this article directly, understanding the key concepts may help you write standard code in a traditional programming language more effectively,andhelpyouworktowardthegoalofsimplicity. n
A Programming History Lesson
Back when I was a junior developer, I used to create 3-tier applications. The idea was to separate the data layers from the business logic layers and the UI layers. The problem is that as front-end frameworks grow in complexity, you’re forced to create a 6-tier application architecture. First you need to create a 3-tier server-side architecture, then a 3-tier client-side architecture. And, as if that weren’t enough, you then have to port your code to Java, ObjectiveC or whatever to support all possible clients out there. Sorry to be blunt here, but this type of architecture is what I call “insanity-driven design” because it grows the complexity of apps to the point where they’re often almost impossible to maintain. A single change in the front-end UI often propagates through 15 lay- ers of architecture and four different programming languages, and forces you to make changes in all those layers just to add a sim- ple column to a data grid in the front end. Lizzie solves this by al- lowing your front end to send code to your back end, which your back end evaluates and returns to your client as JSON. Sure, you lose type safety, but when type safety comes at the cost of having to tie together the different layers of your applications, such that changes in one place propagate to all other layers in your project, the cost of type safety is simply not worth paying.
I started coding when I was 8 years old, on an Oric 1 in 1982. I clearly remember the first computer program I wrote. It went like this:
10 PRINT "THOMAS IS COOL" 20 GOTO 10
If an 8-year-old kid today wants to reproduce that experience, following all best practices, using a client-side framework such as Angular and a back-end framework such as .NET, this kid would probably need to know thousands of pages of technical computer science literature by heart. In contrast, I started out with a book that was roughly 300 pages, and a handful of computer magazines. Before I made it to page 100, I had created my own computer game, at the age of 8. Sorry if this makes me sound old, but this is not evolution and improvement, this is “devolution” and madness. And, yes, before you start frenetically writing down your objections, this problem has been scientifically researched, and neutrally observed and confirmed, by professors and Ph.D.s, all much smarter than me.
The fact is that computer programming as a (human) profession is at the brink of extinction, because the complexity that’s continually being added may soon reach the point where it surpasses the human brain’s capacity to create computer programs. Because programming is becoming so demanding from a cognitive per- spective, it may be that no human being will be able to do it 10 years down the road. At the same time, humans are becoming ever more dependent on computers and software every single day. Call me old fashioned here, but I kind of like the idea that a human being somewhere out there is able to understand the things that are crucial to my happiness, existence and quality of life.
Thomas hansen has been creating software since he was 8 years old, when he started writing code using the Oric-1 computer in 1982. He refers to himself as a Zen computer programmer who seeks to reduce the complexity of modern pro- gramming and refuses to proclaim any belief in technological dogmas. Hansen works for Bright Code in Cyprus where he creates FinTech software.
Thanks to the following Microsoft technical expert for reviewing this article: JamesMcCaffrey
msdnmagazine.com
November 2018 37