#exclude stdlib

It is rather nice to have a standard library. However, for standalone applications on bizarre platforms (i.e. thous shalt be cross-platform), a language should work independent of libraries but not conflict with them. Part of the reason is to allow embedding. It’s nice to not have large dependencies, especially when you can avoid them. At the same time, it’s nice to give users the option to use Boost or some other peculiar library for handling the heavy lifting.

There are some disadvantages to not incorporating the standard library. In fact, not incorporating any library has lots of disadvantages. First, no file loading. That means I can’t have a built-in function for loading libraries – it will need to be an extension. I can’t print to the console either, which means no error messages. (To compensate, I’ll have a logger interface that I can pass error messages and various strings out of.) I will probably also avoid much character manipulation for strings as that might be better served using libraries like ICU.

Rather than depend on the standard library for loading files, I have created a simple interface for using Copper that will accommodate different “front ends” – from simple direct-from-console streams to byte files. Since I have to test my virtual machine, I’ll end up building the basic front ends.

Admittedly, many new languages come with their own “standard library”. It would probably scare away tons of programmers if there wasn’t one. As Copper will be an embedded language, I intend to create small libraries of native code that extend functionality by wrapping standard library functions where… unavoidable – whatever I decide that means, hahaha. At least I don’t need to think about it until I get there.

~ Packaging vs Bundles ~

I would ideally prefer that Copper come in prepared “bundles” containing most of the fundamentals necessary for the job you need. The basic contents of a bundle would be the virtual machine plus some extensions. The components of bundles should be mixable/mutually compatible to allow programmers to take anything they need from one and add it to another. Some components might not function well together – such as those for creating GUI windows, so it makes sense for them to not be mutually compatible. Others – such as image library interfaces – definitely need to be mutually compatible.

Unlike Node.js packages, Copper bundles would not depend on a components that need to be downloaded separately (which I consider unsafe). Instead, their components could be monitored and inspected before being released as part of the bundle. This guarantees everything will work. Furthermore, documentation can be included that is specific to that bundle. Admittedly, some documentation may be redundant, depending on how it is written and presented. The good news is that, at least for Copper, the documentation should be very quick to write up for most functions.

On the downside, creating bundles costs time and requires bandwidth. Security and consistency always has a cost. This entire project has been a struggle between speed, memory, and security.

~ Windows DLL segway ~

On that topic, I am reminded of reading an article (a long time ago) about thee security issue with Windows dynamic link libraries. Apparently, a program’s local folder is checked before the system folder when searching for dlls. So if you name your library after a system32 library, Windows won’t bother searching for the system library. On top of that, the dynamic link library doesn’t need to be compiled with the program – it only needs to have the program depend on a dll with its name. This allows a very crafty hack, which is where a legitimate dll is swapped for a bad one. Of course, the only security fix for Windows is one that breaks backwards compatibility, and we know how precious that is… So much for dependencies, right?

Conclusion

It’s funny how much, no matter how much code you punch out, you always end up being dependent on something someone else has done (and not just on the guys who made the hardware). I intend to avoid the “dependency hell” that is so famous in software, but obviously, some hooks and ladders are necessary. I guess it saves us from reinventing the universe every time.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s