Making the Old New Again with a Differently

Making it on a Shoestring

I was working on Awesome Sauce Java last night when I started thinking. Then it hurt. So I had to stop.

When I started writing a programming language, it was fun and new. It went pretty quickly, too. But it went quickly for a couple of reasons. The first was that the language was small. The second was that the functions I picked to implement were pretty easy. I was just getting started and wanted to limit the complexity. By keeping one side clear and easy to validate, I could know where a bug was happening when they inevitably cropped up.

As the language has grown, things have become more intricate. Sometimes new additions alter the way the reader processes tokens. Or sometimes new code alters the way eval works. Sometimes things just break and it's not clear why.

What I noticed is sometimes things just take time to figure out. I was starting to be frustrated with my pace and felt critical that I wasn't going as fast as possible. Or as fast as I could. Or fast enough...to beat a turtle in a coding race. But then I realized it's just a lot of code. Plus, it's a lot of levels of functionality and abstraction. And then there's just plain old new ways of working with familiar patterns and abstractions that require consideration until they were understood. When the AI parts showed up?  That involved some intense thinking and design work.

Beyond the parts and the AI and tools and language, the package system is still simmering on the back of the stove, metaphorically speaking, of course. That's been a wild expedition into a very familiar structure that suddenly looks like it has utility in myriad and valuable ways for programming in general.  So much of what Awesome Sauce Java is?  It's just old crap repurposed. But with and from a different perspective.

I'm not any great shakes. After my dad died when I was 11, my mom moved us to California and into a little house that always needed work. Soon after we moved in, I came to be in possession of the tools that carried me through a lot of projects.  I had five tools. A crowbar, screw driver, crescent wrench, hammer, and a saw. Six tools. Maybe a set of pliers, too. Point is?  My mom was always asking me to renovate the house of fix something in the house and I rarely had the right tools for the job.  If I did?  They were dorked from using them in ways they weren't intended, like from using a screwdriver as a scraper.

We didn't have much in the way of money, and most of the time, the guys my mom hired turned out to be drunks or mean or both.  They'd take the money and leave without doing the work.  I saw a group of them slash my moms tires of her car because she wouldn't go out with them or worse. Because I rarely had the right tool for the job, but never wanted to let my mom and sisters down, I had to learn to use tools in ways they weren't designed.  It taught me to be flexible and see things not as what they are, but for the potential they offered in a given context.

Awesome Sauce Java is kind of a similar thing. Lisp is from the 60's. Java from the mid-90's. A lot of the parts I'm leveraging were designed in between the birth of Lisp and the birth of Java.  Nothing's new, except the perspective. In fact, I've been laughing since I've came to understand that Awesome Sauce Java could have been designed and built a long time ago.

Back to the Future


There's a point to all that background stuff.  Writing a programming language adds an extra level or layer of complexity when compared to writing a program. When writing a program, the base assumption is that 99% of the time, the language you're using to write your program in is stable and reliable. That way, when bugs appear, you can pretty quickly assume they're your bugs and figure out the source, track it down, and fix it. Along the way, it's possible to double-check the docs for the language or library you're using and make sure your call(s) are aligned with them and finagle the logic until your parts and needs merge with the tools, libraries, and calls the programming language gives you.

Writing a programming language blows that out of the water. Because you still have the possibility that any bug or defect is in your program code. But you also have the possibility that it's in the language itself. Having to figure out whether a bug is in the library or the language is pretty wild. It's kind of like programming a device driver, but more persistent. It's fun and it's challenging. With experience, I feel the shift in mind, from "is this in my program logic", to "no, this is happening in the reader" or some other part of the language.

When I first noticed the shift between validating a defect against program or language logic, I thought it was interesting. Now that I've had time to consider it, along with the need to maintain focus without being overly critical, I realized that writing a programming language is a fun challenge that introduces a really challenging dynamic to programming. Being able to test for logic errors from the program logic, to the programming language logic, is more complex and time-consuming, but now that I've been doing it for a while, it's proven to be fairly easy to determine where the bug lives.

But, no matter how many bugs crop up in the language, my first fear is that the next defect is going to expose the Awesome Sauce Java language with having a fatal design flaw. I suppose that's a healthy way of saying I'm always prepared to encounter the worst, so I'm ready to test, validate and fix *any* logical defect, no matter how deep into the language it is. But it's also exhausting. I think it adds more stress than I need to voluntarily be taking on.

Because no matter how frightening I try to make a bug in the Awesome Sauce Java language, I'm always surprised and amazed at the stability of the lambda calculus upon which Lisp is based. Being based on the lambda calculus provides a degree of stability in coding I've never seen. Once a bug is understood and fixed, it really stays fixed.  When the reader needs to evolve, it does.  When eval isn't quite right?  It's always allowed me to adapt the model to make everything alright.

Having learned that the basis of Awesome Sauce Java is stable has been worth all the effort invested. Because it highlights why Lisp and its weird syntax have lasted, and likely will last, for at least a little while longer. All those parenthesis provide flexibility, stability and consistency other languages lack.  Once you get past criticizing them.

Have a great day!

Michael
2/26/18

Comments

Post a Comment

Popular posts from this blog

I Was Studying Exceptions, But Got Confused, So I Luckily Designed The Code Editor Instead

I spend a lot of time doing nothing without realizing I'm doing nothing. Brain injuries are like that, I guess.  I don't think anybody knows crap about anything & 99% of life is made up and provably stupid.  Whatever.  I seem to get going between 1-4pm.  No matter how hard I try to get moving, I bounce between different tasks until the fear piques and I find something to work on and hopefully find my focus. Awesome Sauce grew too much, or too big, or my living situation is overwhelming, or something.  Because I went from highly productive to scattered right after my son fed me his mom's lentils and rice.  Hmm. That's like what happened after the cup of coffee at his piano teacher's apt. Whatever. Keep forgetting nobody cares.  Except for those people putting me on blast on their social media accounts.  I'm probably good entertainment because I'm blind and write a lot. Last week I started trying to build diagrams for Awesome Sauce Java. The...
Read more

Just a Short Update

I'm reorganizing. What that means is Awesome Sauce Java is going to become structured for release.  Since the release path is forked, the structure of the project has to provide easy configuration for shipping: Stand-alone, Java based Awesome Sauce Java apps. Hot Sauce OS style, all apps running in their own threads & managed by Hot Sauce, based configuration. So all the code is getting moved and re-Git-ified to make sure all the parts can play nice, regardless of which release is being built/updated/released. One of the things I was working on last night on the train was making sure that both release formats provide the ability to edit the application while it's running, even after release, should the developer want their users to be able to edit and modify their application. What this means is that applications need to be able to connect to the ASJ Editor or ASJ Interface Builder apps.  The app, say it's a spreadsheet, needs to be able to connect to the devel...
Read more

A Day Away From a Glowing Screen

One thing I've noticed and written about having been whacked dramatically hard in the noggin' is that my focus works but doesn't. Learning what that means has taken observation and time. The difficulty is that I have to observe while I'm doing, but while I'm doing, I'm concentrating on what I'm doing, not on observing. Why do I suddenly feel like I'm writing what I read years ago from J. Krishnamurthi? Every once in a while, I do something that allows me to see detail from a different perspective.  When I'm really fortunate, I get the chance to see from a high-level perspective.  Like yesterday.  Because it helped me to see, again, how I focus on things that are mostly on the table in front of me. I took the day off from the computer yesterday and worked on paper.  It was depressing.  Because it highlighted how regimented and tiny my world is.  I have four places to go: the library, Whole Foods, Starbucks, & my racoon-stank room (that I...
Read more