Ethos

Truly Both Static & Dynamic

There is a battle of methodologies between strongly typed languages and scripting languages. While dynamic extensions have been added to bridge this gap to some languages likes C#, these extensions are limited and do not provide dynamic features in a complete manner.

Zed focuses on strong typing and static verification, but also allows truly dynamic code while not sacrificing type safety.

Plain Language Syntax

Languages have typically evolved from a computer-centric viewpoint, rather than a human-centric viewpoint. One this starting point was established, nearly all languages continued to use this as a design focus point.

The few languages that focused on readability either tend to be older (COBOL for example) or very limited in use.

Zed re-examines this starting point and thinks about how we write code from a conceptual standpoint while remaining close enough to current programming concepts as to not create a barrier to adoption or a severe disconnect for seasoned developers.

For example instead of:

Zed can do:

Code Density without Obscurity

Many languages (especially C++) are known for their ability to write compact code. Such code often results in difficult to read or debug code and is an odd paradox because while often programmers will go to great length to combine a few lines down to a  single line, they normally still consume whole lines reserved just for opening and closing blocks.

Zed has a purposeful syntax to allow code to be compact, but meanwhile preserving readability and discouraging obscurity.

Error Prevention

both static and dynamic

  • Focus on code quality and early stage error prevention.

Minimize Shiftiness

  • Quick to type

procedural or object oriented

Other

  • Avoid shiftiness. Carpal tunnel
  • Line based, easier parsing, easier rules. And no ;
  • Be dynamic, but typed and have preference for strong typed operators.
  • Enforce case, but don’t allow it as a feature. ie foo !== Foo, but cannot use both Foo and foo concurrently.
  • Spoken Language Independent. Even for user identifiers, allow alternates. For storage store doubly, once as local language and once as English (easier than tokens). Always use English to compile against to ensure interoperability.
  • High syntax compatibility. ie, functions can be swapped out for properties with no breakage in code that uses it. Properties have more functionality than functions so cannot be downgraded as easily.
  • Readable and self documenting
  • Focus on static error prevention
  • Easy reflection, more like JavaScript, less like C#.