About The disc Language

Inspiration for disc Lang Look and Feel

In the discussion on the home page, I discussed where I originally got the idea for creating disc lang in the first place. However, I took inspiration from languages which already exist to create the overall hand-feel, so to speak. In alphabetical order, I drew inspiration from:

• BASIC
• Haskell
• Lisp
• Python
• Ruby
• Io
• Scala

Some of these languages are expressed more predominantly in the visual aspects of programs written in disc lang. Others provided insight into how I might steer into, or away from, a certain practice, pattern, or internal behavior.

The goal of the final design was to blend learning, and a natural flow of the language. A novice programmer would, ideally, understand how the parts of the language fit together, so long as they speak English. (More on this later.) An experienced programmer would, ideally, see the natural start and end of concepts within the language.

Programming should be fun! I borrowed against the idea, in Ruby, that a programming language would provide a fun while programming with it. Hopefully disc lang delivered on that promise. I spent many hours writing programs in order to find places where behaviors felt odd, out of place, or simply misnamed. My hope is this paid off.

Language Behaviors

The behavior of disc lang should be predictable, before all else. The behavioral goal of disc lang was to create a smooth, normalized behavioral experience with as few warts as I could manage. No language is perfect, and this one is no different. Nevertheless, it should be reasonable to explore any programming concept in the small with disc lang.

Choices of programming guidance were made. Since disc lang is intended to be an accessible first programming language, there were affordances built into the language to help people discover the kinds of mistakes which can easily lead to very long debugging sessions. This list is a set of certain key ideas.

• Obvious block demarcation
  • Every block must conclude with an end statement on its own line
  • Failure to include an end for any block is a parse error, and will halt execution
  • Messaging is as clear as possible about what was missed
• Functions are first class, but...
  • Functions are treated as values for any program
  • Anonymous functions do not exist; all functions must be declared by name
  • All functions are defined as constant within their scope, preventing accidental overwriting
• Variable types are invariant
  • All types are dynamically managed at runtime
  • Once a variable is initialized, its type is strongly enforced; e.g. if a variable id initialized with a string, it can only ever store strings
  • All variables must be initialized with an acceptable value; this ensures a variable always has a sensible default value
  • All of this is to ensure the novice programmer receives appropriate messaging when they do something which could lead to an error
• Reading over rigidity
  • There are more core functions than operators, operators tend to be less flexible
  • Optional reader-friendly alternatives, for example:
    • Function call versus colon: call functionName with arg1 arg2 versus functionName: arg1 arg2
    • Standard call versus infix notation: between: testValue min max versus :: value between min max
  • Alternative notation can be ignored for the sake of consistency or reading normalization