Taking Shape: Hot Sauce OS
In This Article:
- Configuring Awesome Sauce Java & Apps
- Update About Package Design
- A Language Without Normal Package Declarations
Configuring Awesome Sauce Java & Apps: Git It?
Well, with enough features in place, and enough R&D, it's now possible to start building. In the last few weeks, macros and mediators have been upgraded/redesigned, and, while working on those two parts of the program, a bunch of other things have been either sketched out or worked on simultaneously.All the work is leading up to finally being able to build from the ground up. With a stable Awesome Sauce Java, access to the JDK, and a growing set of Lisp functions, it's going to be possible to start another iteration on aspects of the Hot Sauce OS.
The first thing I'm doing to build the OS is configuring the code. Awesome Sauce Java is the basis for Hot Sauce. I'm exploring providing a configurable programming language. What that means is being able to build libraries that provide a limited set of functions from the JDK. Each library is like an application in that it maybe can run in and manage it's concurrency model. Making the language configurable is the first part. The second part is making the OS and applications configurable.
Hot Sauce is in flux. While I've built prototypes, the model is kind of new and improved now that it's on top of the JVM. Not everybody is going to want to run Hot Sauce as an OS. Some people will want to run Awesome Sauce Java applications as stand-alone or web-based applications. Others will want to run Hot Sauce as an application environment that coordinates application runtimes, while providing a set of features that allow apps to work together closely (more on this in a later post.)
In order to provide both models? Code needs to be configured so it can be joined with the right application runtime model. I'm configuring code into Git projects so they can be managed as stand-alone units so all the changes get propagated to wherever they end up getting used.
The first projects are the applications, various libraries that support them, and the core of Awesome Sauce Java. From these projects I'll start expanding to include the core elements of Hot Sauce, and keep adding or combining libraries, apps, code, and more into new components (apps, web, cloud.)
Packages, But Not Packages
The next really pure R&D project I'm working on is the package system. I'm deliberately going slow with it because packages are central to so many aspects of building code and they're my pet-peeve of programming in general. I'm not disparaging packages. I get what they are, why they're cooler than anything else, and the insanely complex problem they exist to make manageable. But, packages are also grossly complicated and they limit flexibility. In Lisp, so many things exist to encourage coders to separate code from data and to turn code into data and pass it around - so programs maintain a great deal of dynamicism. Packages kind of block program flow, in my opinion.The package system I'm exploring attempts to make coding with packages more dynamic. Plus, it makes it possible to localize code. What does that mean? It means variable names, functions, methods, can have multiple names, each for a given Locale. When I started exploring this package idea, I saw that names can be associated with things and at runtime. If names can be localized and available at runtime? It might mean that a team of developers can work across language barriers and everybody would see code and docs in their native language and in real time.
Localization poses such potential for collaboration, I'm being very careful with the design to explore and configure the package system to make this feature a possibility.
The thing I'm trying to avoid is referring to what I'm building as a package. Not because they're not packages, but because they might end up offering the same functionality with more functionality and flexibility than packages provide.
A Language Without Packages Has Naming Conflicts & Is Broken, Right?
No. It's not. Maybe. Hopefully not. I don't think so. That's what I'm trying to make work. But, it is if it's built the same way as everything else.What Awesome Sauce Java is working hard to be, is a very dynamic, flexible, and expressive language. It works to make methods and functions work without any specification of which package provides a method. Much of the Java language provides the ability to differentiate method calls by the arguments passed.
Unfortunately, there are conflicts with method names and method signatures, and the desired method call has to be associated with code somehow. While this is the point of package and import statements, ASJ seeks to avoid hard-coding the source of a call. So far, this is working. The new package system, in combination with the Transformers feature, and Editor or Interface Builder, seeks to make it possible to make and manage the association between a function/method call where it's made.
More to come.
Have a great day.
Michael
3/10/18
Comments
Post a Comment