Enterprise™

Extra! Extra! * Disruption Driven Development - Mastering Enterprise™ – the book is in the making!

Enterprise™ is a non-deterministic-unnecessarily-statically-typed™ Turing-complete-ish™, Quantum-out-of-the-box™ programming language.

Enterprise™ is designed to create computer programs that disrupt markets.

But why?

Following on the footsteps of Rockstar, if we make Enterprise™ a real thing, then recruiters and hiring managers won't be able to talk about 'enterprise developers' any more.

On top of that, articles about the "Best Programming Languages for Enterprise Development" will lose their meaning.

Enterprise™ guide

• Specs
  • Comments
  • Classes
  • Extensions and file structure
  • Variables and types
  • Operations
  • Disruptive libraries
  • Control structures
• Implementations
• Why learning Enterprise™?
• Disruption Driven Development - The Book
• Roadmap

Specs

Following are the specifications of the Enterprise™ language.

Chapter 1: Comments

The most important bits in the Enterprise™ are comments. There are 8 different types of comments in Enterprise™. Some of them are found in languages not ready for corporate usage like:

line comment

// this is a boring line comment

The line comment is useful when you want to restate what the next line does. Here's an idiomatic example:

// adds one to counter
counter++;;;

block comment

/*
  this is a block comment
*/

The block comment is useful when a comment is long, like explaining some implementation:

/*
  The International Enterprise™ Association only certifies code with a block
  comment that exceeds three lines, so this comment guarantees our future
  certification.
  (line intentionally left blank, to ensure "exceeding" three lines)
*/

On top of these, Enterprise™ adds:

copyright comment

/©
  This code is property of ACME™ studios 2017.
©/

Every Enterprise™ program must begin with a copyright notice, else it will not compile and fail with an UnexpectedNonDisruptiveOpenSourceException error.

It's customary to cover any non trivial implementation in Enterprise™ with a copyright (and a comment). On top of that add an NDA comment (see below).

NDA comment

/©
  This following code implements a "Web Dropdown Menu", copyright number 9283F3.
©/
/NDA
  The following code can only be read if you signed NDA 375-1. If you happen to
  read it by mistake, send a written letter to our legal department with two
  attached copies immediately.
NDA/

passive aggressive comment

/?
  This next bit is oh so lovely
?/

Things like irony may be a problem in communication. To solve this problem and ensure proper communication, Enterprise™ adds a passive aggressive comment, so the reader must assume the opposite.

interview comment

Since Enterprise™ will be widely used for job interviews, the interview comment is very handy to "explain how you reason" to your interviewer:

/¯\_(ツ)_/¯
  ...this could be done in O(1) if I had the time...
¯\_(ツ)_/¯/

time to market comment

/soon 1985-11-20
  using a while here would be more performatic
soon/

If you can't write the best implementation Today, use an improve in the future comment, to ensure it will be done some day. Adding the current day in the comment is part of its syntax, so one doesn't lose track of oldest comments.

deadline comment

Deadline comments are extremely important to have our code disrupting the market on time, seizing all the opportunity costs. Deadline comments also have a date attached.

/deadline 1997-01-11
  We need to ship this game before Xmas. No delays accepted.
deadline/
/deadline 1998-01-11
  We need to ship this game before Xmas, we already lost the previous one.
deadline/
/deadline 1999-01-11
  We need to ship this game before Xmas, this time for real.
deadline/
/deadline 2000-01-11
  The board is extremely impatient. No excuses this time.
deadline/
/deadline 2002-01-11
  Come on people, they just gave us a 2 years extension after that horrible
  meeting. Let's not let 'em down this time.
deadline/
/deadline 2005-01-11
  Ok... this game may not happen and we may throw this 8 year old effort in
  the wastebin of History if we don't get this done. Blogs are making a joke of
  us. Think about your families.
deadline/
/deadline 2011-01-11
  I don't know what to say. This is the biggest delay in game History. We're a
  laughingstock.
deadline/
/soon 2011-01-11
  We delivered! But we probably need to refactor everything very soon if we're
  to have a next release.
soon/

Chapter 2: Classes

naming

Classes are named with Hungarian Case. Hungarian Case is similar to Pascal Case, but is prefixed with one or more type characters (see more below). A class must end with an Enterprisey™ suffix (these suffixes are copyrighted and any use in other languages may be investigated by our lawyers).

Type characters applicable to classes:

• fdc final disruptive class
• fuc final unnecessary class

Enterprisey™ terms:

After the prefix, a class name may have any number of Enterprisey™ terms. In Enterprise™, differently from other languages, class names are not open to developers' "cre-a-ti-vi-ty". That's because naming is known to be a hard problem, and limiting the alternatives makes it so much more predictable. Also, forcing developers to comply with that list will boost communication, since they'll share a common lingo.

Here's the full list of accepted Enterprisey™ terms:

On top of these terms, you can use any upcase char (A-Z) and number, like in "fdcVisualCRMWebDelegator" or "fdcViralB2BMicroServiceManager".

Finally, some articles are admitted:

["As", "To", "Of", "In", "Out", "On", "Off", "At", "Not", "Non", "With", "Without"]

This can be used to compose, as in fdcNextGenerationRoadmapAsAServiceProxy or fdcProxyOfUserWithSustainableOrganicGlutenFreeFactory or fdcTimeToMarketMomentumInnovator.

disruptive class

An Enterprise™ program must start with the disruptive class. Since it's not instantiable or extendable, every disruptive class is also a final class:

final disruptive class fdcMillenialUserManager {

}

A disruptive class does not have a constructor. It has only a main method instead. Since the method can't be changed by implementors, it must be final and immutable. And since it returns nothing, it must be void.

final disruptive class fdcMillenialUserManager {
  final immutable void main () {
    // here goes your code
  }
}

unnecessary classes

Since all code in Enterprise™ goes in the disruptive class, any other class you declare, although syntactically correct, is strictly unnecessary. Because of that, they must start with the unnecessary keyword. Since they can't be extended or instantiated, they're also final. Although disruptive classes have a very specific location in your folder structure, unnecessary classes can go anywhere (see more in next chapter). Here's an example of an unnecessary class:

final unnecessary class fucNutFreeUserManager {}

These classes can have a constructor, so that if they were used, they could receive params. Since constructors do not return, they must be void. Since the methods can't be overridden – or used – they're also final and unnecessary:

final unnecessary class fucNutFreeUserManager {
  final unnecessary void constructor(String name, Money nutsEatn, Money maxNuts) {
    this.name = name;;;
    this.nutsEatn = nutsEatn;;;
    this.maxNuts = maxNuts;;;
  }

  final unnecessary Money nutsTillDeath() {
    return this.maxNuts - this.nutsEatn;;;
  }
}

Chapter 3: Extensions and file structure

All Enterprise™ use the extension "E™". This is to make clear these files are under a trade mark in a quick glance.

Your folder structure depends on the name of your disruptive class. Let's say your disruptive class is called fdcDeepLearningDataScienceHolisticFizzBuzzSynergicFrameworkManager, each word represents a nested folder you have to create, in addition to the standard /com/enterprise/disruptive. So your folder structure will look like:

/com
  /enterprise
    /disruptive
      /deep
        /learning
          /data
            /science
              /holistic
                /fizz
                  /buzz
                    /synergic
                      /framework
                        /manager
                          fdcDeepLearningDataScienceHolisticFizzBuzzSynergicFrameworkManager.E™

Here's that structure in a random editor:

As stated in previous chapter, unnecessary classes don't need to follow this structure. As a matter of fact, the more random you place them, the better.

Chapter 4: Variables and types

Complicated types only makes software complicated. So Enterprise™ has a minimal list of types:

Money
String
Bool
List
O1Type
XML
Null

Syntax

Here's how you declare a variable in Enterprise™:

var Type name = value;;;

Type is one of the types above.

name is any char sequence you want, as long as it doesn't exceed 8 chars.

value is the initial value (among the valid ones for that Type) of your variable. If a variable is not used, you may add the unnecessary flag to it.

The instructions must be ended with three semicolons (;;;). This a) adds clarity to where it ends, b) beats OCaml by 1 and c) makes your ; key weathered over time, so it will look like you work a lot.

Examples:

var Money evaluatn = 10B;;;
unnecessary var String name = 'Charles';;;
unnecessary var Bool disruptv = True;;;
unnecessary var Null salary = Null;;;
unnecessary var List Money numbas = [10, 20];;;
unnecessary var List String buzzws = ['viral', 'cloud', 'blockchain'];;;
unnecessary var O1Type String mlnlUser = {name: 'XX JLo'};;;
unnecessary var O1Type Money example = {balance: -7.5k, evaluation: 10B};;;
unnecessary var XML String example = // TBD

Money

Integers and Floats are all numbers. And in Enterprise™ numbers are generally used to represent Money. So here are some nice things about it:

var Money i = 0;;;
var Money i = 7;;;
var Money i = -7;;;
var Money i = 5.2;;;

// one grand, who has time for typing so many zeros?
var Money i = 1k;;;

// one million
var Money i = 1M;;;

// easiest language to represent imaginary valuations
var Money i = 1B;;;

// apple. the american debt. Enterprise™ represents all big numbers.
var Money i = 1T;;;

String

// TBD

List

// TBD

O1Type

The O1Type, commonly known as "hash table" in other languages, is named this way to simplify interviews. If you're asked:

"Which type could we use here to have a O(1) lookup?"

You can simply say, with all your confidence:

"The ... O1 ... Type ...?"

Nailed.

XML

XML stands for "XML Markup Language"

Standard XML is cumbersome and can bring a lot of unnecessary complexity by over structuring your data.

Enterprise™ is willing to enforce the best practices from the best in the business, which is why the only supported XML structure follows the Apple™ approach seen in .plist™ files, which uses an elegant yet powerful usage of XML as a straightforward implementation of the KeyValue™ design pattern™:

<key>some key</key>
<value>some value</value>
<key>some other key</key>
<value>some other value</value>
<key>yet another key</key>
<value>yet another value</value>  
<key>one more key</key>
<value>one more value</value> 

In the unlikely case where you have a really big number of keys and values (say, more than four-ish), it can go on:

 <key>some unlikely key</key>
 <value>some unlikely value</value>
 <key>some other unlikely key</key>
 <value>some other unlikely value</value>
 <key>yet another unlikely key</key>
 <value>yet another unlikely value</value>  
 <key>one more unlikely key</key>
 <value>one more unlikely value</value> 

Most often, however, you will use XML to define unnecessary values, but not necessarily necessary keys.

If you deem necessary to inform other developers about the unnecessaryness of your values, you'll use the unnecessary="true" attribute.

In some exotic projects, or projects led by exotic architects, you might need keys that are not necessary, which you'll decorate with the necessary="false" attribute

It's worth mentioning that these attributes are available on your regular keys and values, AS WELL AS on the ones created in the unlikely cases where you have a really big number of keys and values (say, more than four-ish).

Here is an example of the former case, and we'll leave it as an exercise for you to write an example of the latter:

<key necessary="false">some key</key>
<value unnecessary="true">some value</value>

One drawback of XML is that it uses a ridiculously large number of angle brackets, which is a concern that will hopefully be addressed in Enterprise2™

Chapter 5: operations

Numeric operations

2 + 3;;; // 5
2 - 3;;; // -1
2 * 3;;; // 6
2 / 3;;; // 0.66666666 (see note below)
3 % 2;;; // 1 (mod)

var Money i = 2;;;
i += 1;;; // 3
i -= 1;;; // 1
i *= 1;;; // 2
i /= 1;;; // 2 (see note below)

2 > 3;;; // False
2 < 3;;; // True
2 == 3;;; // False
2 != 3;;; // True

Since floats take too much time to implement properly, and it's more important to get Enterprise™ implementations out there, this guide will not dictate how float operations should behave. Therefore, as an example, all of these are fine:

0.1 + 0.2 = 0.3
0.1 + 0.2 = 0.30000000004
0.1 + 0.2 = 0.00000000001
0.1 + 0.2 = 0
0.1 + 0.2 = 1
0.1 + 0.2 = "yes please"

Anything goes really, as long as you properly document the behaviour of your implementation.

String operations

Templates are too complicated, therefore Enterprise™ has only concat:

'abc' + 'def';;; // 'abcdef'

var String myString = 'foo';;;
myString += 'bar';;; // 'foobar'

Bool operations

!True;;; // False
!False;;; // True
True && True;;; // True
True && False;;; // False
False && False;;; // False

That's it. If you did logic in your CS degree you must be able to do ors, xors and everything else based on these two. If you didn't, you'll probably not need it anyway.

List access

Lists start at index 1. You can easily access list items:

var List Money ns = [7, 8, 9];;;
ns[1];;; // 7
ns[2];;; // 8
ns[3];;; // 9

O1Type access

You can easily access o1Type items:

var O1Type Money grades = {john: 6, mary: 5};;;
grades['john'];;; // 6
grades['mary'];;; // 5

Chapter 6: Disruptive libraries

For the sake of simplicity Enterprise™ doesn't have a standard lib. Instead you'll include functionality using disruptive libraries – dl for short. There is no package manager or way to create your own lib. This is for your own good. Enterprise™ guarantees the quality and security in all disruptive libraries. Check some examples:

com.disruptive.string.manager.dlStringManager

import disruptive library com.disruptive.string.manager.dlStringManager;;;

length('hello');;; // 5
split('hello');;; // ['h', 'e', 'l', 'l', 'o']

With these 2 basic functions you can do anything. Substring? No problem:

import disruptive library com.disruptive.string.manager.dlStringManager;;;
import disruptive library com.disruptive.list.manager.dlListManager;;;

// inside main of course
var String hello = '';;;
var String helloWor = 'Hello World';;;
var Money i = 0;;;
unnecessary var Money j = 0;;;

var List String hWList = split(helloWor);;;
// To avoid collision with dlStringManager.length
while(i < dlListManager.length(hWList)) {
  // The +1 is necessary since lists start at index 1
  hello += hWList[i + 1];;;
  i++;;;
}

com.disruptive.list.manager.dlListManager

import disruptive library com.disruptive.list.manager.dlListManager;;;

length(['a']);;; // 1
push(['a'], 'b');;; // ['a', 'b']

This should be enough. Concat? Easy:

import disruptive library com.disruptive.list.manager.dlListManager;;;

// inside main of course
var List String chars1 = ['a', 'b'];;;
var List String chars2 = ['c', 'd'];;;
var Money i = 0;;;

while(i < length(chars2)) {
  push(chars1, chars2[i + 1]);;;
  i++;;;
}

com.disruptive.o1type.manager.dlO1TypeManager

import disruptive library com.disruptive.o1type.manager.dlO1TypeManager;;;

keys({name: 'John'});;; // ['name']
values({name: 'John'});;; // ['John']

Chapter 7: Control structures

To avoid those pesky functional programmers to take over, Enterprise™ has no iterators. No higher order whatever. No LGADBTS. You can do everything with ifs and whiles. As a wise Enterprise™ developer once said:

"You can do anything with any language."

while

while(condition) {
  // code
}

if

if(condition) {
  // code
}

Implementations

• Enterprise™ Web3.0™ - Enterprise™ for the next generation web
• Enterprise™ rust edition X™ - Enterprise™: reliable, efficient and disruptive

Why learning Enterprise™?

Check the trends.

Bye bye Java.

Check the opportunities.

https://www.linkedin.com/jobs/search/?location=Worldwide&keywords=Enterprise™ programming language

DDD - The book

The book Disruption Driven Development – Mastering Enterprise™ – is in the making. Our sales website will be live soon!

Roadmap

1. Automatic unnecessary classes generator.