Why badlang?

24 Jan 2012 08:57

Back to list of posts

So you think language X is is bad? Join the club! And since its bad, we need a different language right? I think all programming languages are bad, and we need yet another bad programming language: enter badlang!

Badlang is in the design phase. Its designed to be statically dynamic through eagerly evaluating buzzwords (here buzzwords is defined to be a large set of buzzwords, or just the noun "buzzwords", you choose!).


Go lacks generics. How can generics be added without forcing compile or runtime size or time overheads? How about a completely unrelated language that is entirely designed around solving this one issue? Its badlang!

What if all the different flavors of generics, with their different tradeoffs all could be implemented in code, with no extensions, in a language? Such a language would allow worse hacks than C++. Surely it would be a badlang.

How can this be done? Dynamic runtime type creation seems to solve the compile time size/time bloats. Doing this same dynamic creation, but pre-evaluating it at compile time seems to save the runtime slowdown. Lots of other things can also be built with these tools too.

This focus is the core of badlang: make everything dynamic, then allow it to run at compile time to [re]move the overhead.

What does this lead to?

Design goals:

  1. simple -> most features implemented in stdlib
  2. self-metalanguage -> meta-programming is cool, but if your meta-language is not the target language, you can't have meta-[meta-[meta-[meta[…]]]]-programming. Also, less languages if you reuse badlang as the metalang.
  3. usable performant code-> if you want to waste time optimizing, make it possible to go as far as desired making horrible code to make it run fast, but allow such messes to have tolerable APIs.

In short thats badlang! Now for some bad examples:

printf(someStringConstant,[some args or not])

how about this:

printf(someStringConstant).([some args or not])

Here printf takes an immutable string. If the string is known at compile time, the printf function gets called then, and it returns a callable that knows how many and what type of arguments it expects. Then the compiler sees there is a callable getting called, so it enumerates the types passed to the callable (the types of [some args or not]), and passes the types to the callable's function lookup that returns a matching function, but can also throw an error if the types don't match what is expected, and it can do this at compile time if the types and format string are all possible to determine.

Comments: 0

Add a New Comment

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License