DEV Community: Risav

MAP III - Types of Types II

Risav — Tue, 14 Apr 2020 13:26:06 +0000

We need to invert the wasteful trend of learning something as timeless as higher maths only as a means to learn an ephemeral or ever-changing programming language or paradigm. Let's aim instead to explain and discuss foundational mathematical structures like types and categories through these programming languages as visual learning aids. This helps us become better developers in any language, including new ones for quantum computing or even natural language-based programming.

Previously on MAP - Types of Types, we looked at the type hierarchy of Scala and worked with a basic 'level 1' definition of types. Now we will level up and refine our previous working definition of types as value spaces with a set of allowed operations. At level 2, we will celebrate Function's tying of the knot with Data and how that adds a new dimension, literally as well, to how we have come to define and understand types. We will need to go back to discussing some basics like the very concept of functions and objects. With this slightly boring and unapologetically pedantic detour, we will demystify some commonly held oversimplifications or misconceptions and proceeds towards the more advanced and interesting concepts being on the same page. For instance we will see how functions and objects together create a fast track towards advanced abstract data types and algebraic structures or how classes and objects are simultaneously quite different and so much more than what we have been teaching our kids.

2. Function weds Data: Domain and Co-domain Spaces

Our last definition of types was mainly concerned with types of data. It was therefore sufficient to think of value spaces, basic syntactics and behavior, understood in the sense of a set of operations on elements of that space. In programming, behavior comes from patterns of actions, which itself comes from operational chunks of code, which in turn act only on either data or other codes.

It's no surprise that chunks of programming instructions and of data have lived together on the same memory space ever since von Neumann architecture was first adopted. This intimacy of data and code is lost on many programmers who do not often need to think of the nitty-gritty of the innards of their machines.

Functions and objects are two major constructs in programming where this intimacy-by-design is directly reflected at the level of program codes. Since they have already 'moved in' together, many languages including Scala makes this an official relationship, which I have cheekily phrased as 'function weds data'.

2.1 Object and Class

Just like every construct in Scala has a type, every instance of a type is an object. Scala does not have Java-style primitive types, which do not have objects.

Whether or not a language follows object oriented programming, an object in a programming language is a data abstraction representing value(s) in memory. An object has a named identifier and may have properties, methods with read/write access to the object's properties and relationships with other objects. Alike functions, objects have mathematical counterparts too. We will explore them in the next two posts in this series.

Templates

A class is famously known as a 'blueprint' or template for instantiating an object. The class defines what properties, methods and relations an object can have and/or from where it inherits them. A class name is also usually the name of the user-defined type of the objects made using the class's constructor, which also usually has the same name as the class.

This is only partially true in Scala but wholly correct in Scala's more popular cousin Java. In Scala, it is problematic to hold on to the idea of class as a sole blueprint for objects.

The Scala specs define objects, classes and traits (Java 8+ interface-like abstractions supporting states, mix-in type restrictions, reference to objects of implementing classes) in terms of templates, which are not actually available for programmers.

Templates, not classes, are the actual templates in Scala.

A template definition may be a class template definition or an object template definition or a trait template definition. A class definition or an object definition may be for a regular class of objects or a singleton object or for a case class or a case singleton object. These template definitions are what actually define the type signature of the resulting objects and the constructors or initial values therein define the initial states of those objects.

This conception of class in Scala is, as with functions, closer to a class in mathematics in the sense that a class definition represents a constrained set of instantiable objects while an object definition is just for one object.

Scala also throws away the concept of static classes that do not need instantiation in favor of singleton objects created via the object template definition. These static classes, values and methods are hard to reconcile with the object oriented paradigm. They do not support inheritance and dynamic dispatch due to polymorphism, which itself is possible due to inheritance. Lastly they are also tough to mock and unit test easily.

Bonus: Classless OOP

However a class is not the only mechanism for defining templates for object instantiation.

Here's an excerpt from MDN regarding how JavaScript has OOP, better than most other languages known for their OOP, without classes. The ES6 classes are actually just syntactic sugar to make it easier for those used to class based OOP.

A prototype-based language?

JavaScript is often described as a prototype-based language — to provide inheritance, objects can have a prototype object, which acts as a template object that it inherits methods and properties from. An object's prototype object may also have a prototype object, which it inherits methods and properties from, and so on.

This is often referred to as a prototype chain, and explains why different objects have properties and methods defined on other objects available to them.
Well, to be exact, the properties and methods are defined on the prototype property on the Objects' constructor functions, not the object instances themselves.

2.2 Functions and Methods

A function is a chunk of code you can call by name. The function, its inputs and output can each be objects. In Scala, they always are.

Inputs:

Functions may take values as inputs, possibly operate on these values or create side-effects based on those values or the context, and likely return something in the end. Pure functions however are more well behaved and closer to the functions from mathematics thanks to idempotence, referential transparency, and separation from side effects.

Informally speaking, the space of all possible values that could be accepted as an input is called the domain of a function.

Spaces are just sets with added structures. In our context, spaces may have varying dimensionality and each element has its own previously defined level 1 type.

Outputs:

Every chunk of code in Scala that can be put on a single line returns a value.

These lines, which may be typed as blocks for readability, may be either functions or expressions that compose functions. In either case, an output per expression or per function is guaranteed. Even if an expression or function is handling side effects or running into an exception, the previously mentioned Unit return is guaranteed.

This style of programming with expressions is called expression oriented programming (EOP) and is a part of the functional programming paradigm.

Informally speaking, the space of all possible values that could be produced as an output is called the co-domain of a function.

2.3 Parameter Types and Return Types

Now that we are literally on the same page regarding the lingo and the concepts, let's take these concepts to meet some program codes.

Since every line is either a function or an expression, we can simply take note of what type of thing goes in and what comes out.

if/else-if/else (v1)

This is commonly needed and commonly avoidable expression. Let's break it down.

How could we write a (basic) version of the if-then expression? We know that it would

take a predicate as the first parameter i.e. either a Boolean or something that returns a Boolean
take a function to execute if the above value is true as the second parameter
the predicate and the function could use any number of parameters of Any type

// Naive if-then without advannced tytpes

def ifThen(someBool: Boolean)(func: () => Boolean): Any = {
  !someBool || func()
}

def unitaryFunc() = {
  false
}

ifThen(true) (unitaryFunc)
// res0: Any = false
// same as the invocation below

ifThen(1 == 2) {unitaryFunc}
// res1: Any = true

ifThen(42 == 42) {unitaryFunc}
// res2: Any = false

This is quite a useless if-then in its current form but it gives us a good outline of how if-then works and what we should improve over the course of this series.

As explained in 'Curly Braces and Parentheses' in Viva La Scala explainer collection, the curly braces you see in if statements and other control structures are nothing more than just simple parentheses substituted for readability and multi-line blocks.
The if-then structure or p -> q is logically equivalent to ¬p ∨ q

In terms of improvements, these would be highly necessary:

We will need to support more types of parameters and return values for the function being passed to the if-then function.
We will need to find a way to compose if-then to else-if and else constructs.

Function composition requires that the return type of the function passed as a parameter is the same as the parameter type of the function receiving that function as its parameter. How then do you compose functions that need to support incompatible return and parameter types? We will later explore some solutions to this, including monadic ones.

Here's an an example of how Java's Optional is converted to the monadic version in Scala:

def toScala[A](o: Optional[A]): Option[A] = if (o.isPresent) Some(o.get) else None

match-case

The above example is fairly simple use case for if-else because the Optional container has a nice and simple isPresent method make it easier to test against a method with Boolean return type. However here's how the reverse condition is achieved by Scala:

import java.util.{Optional, OptionalDouble, OptionalInt, OptionalLong}
import java.{lang => jl}

object OptionConverters {

  def toJavaOptionalInt(o: Option[jl.Integer]): OptionalInt = o match {
    case Some(a) => OptionalInt.of(a)
    case _ => OptionalInt.empty
  }
}

This time we are checking against the possible types. match-case is a better fit for checking against types, which in this case are either Some or anything else.

Note that the match construct is also an expression and the curly braces are once again super-powered parentheses which can take multiline values or functions or expressions as arguments.

The input to the match expression is o provided as the first operand in infix style and the case expressions provided together as the later parameter in the curly braces. The return type is determined by the return type of the expression on the right side of the matched case.

The match-case expression is also capable of checking against values and is especially better suited for cases with too many cases.

def getEnglishNames(x: Int): String = x match {
  case 0 => "Zero"
  case 1 => "One"
  case 2 => "Two"
  case 3 => "Three"
  case 4 => "Four"
  case 5 => "Five"
  case 6 => "Six"
  case 7 => "Seven"
  case 8 => "Eight"
  case 9 => "Nine"
  case _ => "Not enough fingers!!"
}

getEnglishNames(6)
// res0: String = Six

getEnglishNames(10)
// res1: String = Not enough fingers!!

How about mixing these two expressions? If you have a use case where you have to check for values while also checking for types, it's best to use both. Here's how Scala converts FiniteDuration to a Java duration:

  def toJava(duration: FiniteDuration): JDuration = {
    if (duration.length == 0) JDuration.ZERO
    else duration.unit match {
      case TimeUnit.NANOSECONDS => JDuration.ofNanos(duration.length)
      case TimeUnit.MICROSECONDS => JDuration.of(duration.length, ChronoUnit.MICROS)
      case TimeUnit.MILLISECONDS => JDuration.ofMillis(duration.length)
      case TimeUnit.SECONDS => JDuration.ofSeconds(duration.length)
      case TimeUnit.MINUTES => JDuration.ofMinutes(duration.length)
      case TimeUnit.HOURS => JDuration.ofHours(duration.length)
      case TimeUnit.DAYS => JDuration.ofDays(duration.length)
    }
  }

These are pre-existing types. Can we do this with custom types? As we discussed, custom types could come from custom objects or classes. You might have also noticed earlier that class and object template definitions may also have a case qualifier in front of it.

sealed abstract class Device
case class IPhoneX(uglyNotchSize: Long) extends Device
case class S10(holeCamOffset: Double) extends Device
case class NexS(popUpCam: Boolean) extends Device
case class Pixel(pixels: Int) extends Device {
  def sorry = "Old School"
}

def howBeautiful(device: Device): String = device match {
  case IPhoneX(_) => "Ugly"
  case S10(offset) if offset == 0.5 => "Symmetric but Meh"
  case S10(_) => "Meh"
  case NexS(false) => "Cool"
  case NexS(true) => "Clunky"
  case px: Pixel => px.sorry
}


howBeautiful(IPhoneX(10))
// res0: String = Ugly
howBeautiful(S10(0.5))
// res1: String = Symmetric but Meh
howBeautiful(S10(0.7))
// res2: String = Meh
howBeautiful(NexS(false))
// res3: String = Cool
howBeautiful(NexS(true))
// res4: String = Clunky
howBeautiful(Pixel(4))
// res5: String = Old School

The sealed keyword tells Scala that all possible subtypes or cases are present within the same file and not dispersed elsewhere in the code.

The if statement on the first S10 case is another way you could mix if with match. In this case, it is called a pattern guard.

Notice that the ordering of the cases matters because the fall through is similar to that found in switch statements in other languages.

Also note that all but the last case are still checking against values albeit of value objects. Only the last case is actually checking against a user defined type.

We now have a good groundwork to look into try-catch and try-success-failure. We will also be looking into for, for-yield and foreach expressions once we have collection types in our arsenal by the end of the next post. That is also where Scala/Mathematics concepts start to get real fun to play with.

Next on 'Types of Types'

To keep the posts from going beyond optimal lengths, we will explore each of the next 'levels' of understanding and defining types in their own posts. Here's a sneak peek.

3. Abstract Data Types: Types with Structure and Behavior

Here we will rediscover the good old data structures mostly used in programming through a more formal, functional and scala-ble lens 🧐. Sum and product types will also pave the way for the more involved algebraic data types in the later section.

3.1 Sum and Product Types

3.1.1 Union or Tagged Union
3.1.2 Tuple and Record

3.2 Set and List

3.2.1 Unordered and Non-duplicated
3.2.2 Ordered and Random Accessible

3.3 Maps

3.4 Stack and Queue

3.5 Graph and Tree

4. Algebraic Data Types and HKTs

Here we will (re-)discover universal algebra, ring-like, group-like, lattice-like, module-like, and algebra-like algebraic structures relevant to advanced functional and reactive programming. We will also demystify higher kinded types and similarly exotic higher order concepts.

5. A Gentle Introduction to Category Theory

Here we will use the Scala concepts and Type Theory topics thus far to go for a deep dive into Bartoz Milewski's excellent course on Category Theory .

Further resources:

2.1 Classes and Objects Specs in Scala: https://scala-lang.org/files/archive/spec/2.13/05-classes-and-objects.html
2.2 Scala source code: https://github.com/scala/scala/blob/2.13.x/src/library/scala/

1.1 D. L. Parnas, John E. Shore, David Weiss: Abstract types defined as classes of variables, https://dl.acm.org/doi/10.1145/942574.807133
1.2 Tony Hoare on his infamous billion dollar mistake: https://www.youtube.com/watch?v=kz7DfbOuvOM
1.3 Official Scala API Docs and resources: https://www.scala-lang.org/
1.4 L.G. Meredith, Pro Scala: Monadic Design Patterns for the Web: http://patryshev.com/books/GregoryMeredith.pdf

MAP III : Types of Types

Risav — Sun, 05 Apr 2020 03:25:56 +0000

When talking about types in computer science, one could be talking about two types of types. Types from type theory are closely related to the types from type systems used programming languages. Both of these are fun and playing with them illuminates how any language works. It may even help you obtain an A3 or perhaps even the L3-tier superpowers.

Previously in the Mathematics' (An)architecture and Processes (MAP) series, we have briefly touched upon Curry-Howard-Lambek isomorphism, which is a trifecta of independent realizations about, among other things, how propositions are types i.e. claims that are true or false, formal proofs, logical calculus' constraints and formulae are types too. With Scala's types, and Java 11+'s and Typescript's later, we will see what it actually means to say something as abstract as 'propositions are types' and why understanding these esoteric and zen sayings can make you a better programmer - in any language, with any kind of type system.

For getting started with types, we will come up with our working definition of types with increasing levels of technical depth. We will also be iteratively refining our definition and intuitions regarding what types are. As for how types look in programming, here are four simple examples:


val obligatory = "Hello World! "  
// type inferred to be String based on its value

val goodbye : String = "Goodbye, cruel world..." 
// type explicitly defined to be a String

val emoji: Char = '☺'
// Unicode characters are present in Char type's value space

val heteroList: List[Any] = List(obligatory + goodbye, true, 42)
// String type allows addition operation 
// The composed type List[Any] allows use of any type in heteroList

This is certainly just a picture and certainly not the whole picture. However we will get closer to types through this kind of programmatic representation of types above.

This is not a pipe. This is just a representation of a pipe.

Almost every programming construct that you can use has a type. It follows that there are many types of types.

1. Common Data Types: Syntactic and Semantic bits

Let's start with the primitive ones. Types of values in data are the easiest to intuitively understand. Here at level 1, we will define type as a pre-defined value space for our data which possibly comes along with a set of allowed operations on the values in that value space.

At level 1, you may find, for instance, a type that does not have any possible operations or one that is simply an alias of another type. These are merely syntactic types. All types have this syntactic aspect in the sense that a type definition ensures the program compiler - and the programmer - that it adheres to the rules and constraints set by the programming language itself, especially regarding what is and isn't allowed to be done with a certain variable or construct.

For instance, if you find a type definition called Money in your program, it probably is a syntactic sugar representing some type of fixed or floating point numbering.

The semantic aspect of a type would be about what it means to have a certain type in the first place. For instance, type semantics could tell you what possible actions are possible on that type or what interactions are allowed with other types.

For a utility type like Money, the operations could be inherited arithmetic methods for addition or subtraction or convenience methods composed of other operations like methods for interest rate calculations.

Any and Nothing

All types in Scala are different derivations of the Any type. Informally, you may call it the mother of all types as it is the top type in Scala's type hierarchy.

Any of Scala is similar to the Object type defined by the class also named Object in Java. In TypeScript, there are two top types any and unknown. any just tells the TypeScript compiler that it should not even bother to do any type checks. So compile time type safety due to aforementioned type syntactics and semantics is effectively disabled for that variable or constant of any type. So related bugs may only be discovered if unexpected operations are performed on that value at runtime - during testing (hopefully) or in production (yikes). unknown type signifies that the actual type is yet unknown but can be narrowed down and pin-pointed based on its runtime values, usually using a language construct called type guards.

Any in Scala has general definitions of equals, hashCode and toString methods. This means that Any type in Scala allows for checking whether anything equals another and what its hashed or string representation is.

All puns intended. Always.

Type theory and category theory, from which we have type systems in programming, also have something called a bottom type. It is called so because it is at the bottom of the type hierarchy i.e. all types have the bottom type as their subtype. Scala's bottom type is called Nothing as there is nothing you can assign to a variable or construct of type Nothing. If a function throws an exception instead of returning any value, it has Nothing for a return type. We will find further uses of this in later posts, especially when we discuss covariance under parametric polymorphism.

AnyVal and AnyRef

In programming, you may be directly using or passing around a value from one memory location to another. These types of values are derived from AnyVal type in Scala, which itself is a descendant derived directly from the Any supertype.

You may also just be referring to where the value is located in your memory space instead of moving those values around. These variables have a reference type, which descends from the AnyRef supertype, which itself descends directly from the Any type.

When you look at the documentation for a type, for example Boolean, you might find methods that box or unbox a value. The scala.Boolean is a value type but you can wrap your boolean value inside a 'box' made of java.lang.Boolean, which is a reference type. You might need to do this boxing to access reference type's methods or, in this case, to ensure interoperability with Java clients of your library. Similarly, you can also 'unbox' a reference type into a value type.

Unit and Boolean

Just like Nothing allows nothing as its value, Unit allows only one and the same value, and Boolean allows only two.

Boolean type is probably the most well known and easily understood of all. It allows its value to be either true or false.

Unit type only allows one value, which is written as (). Therefore it holds no information and is very similar to, but not the same as, void used in C/C++/Java. It also should not be confused with aforementioned Nothing or with Null from the next section. We will return back to this type later when we talk about tuples and product types since Unit can be interpreted as a 0-tuple or a product of no types. We will also see how it is useful when we talk about abstract data types and algebraic data types.

Option and Null

Sometimes a reference is likely to point either to some value or to none of it when the value of the instance of that type is requested for use by the program execution. In many languages, such references lead to a null pointer, which Tony Hoare, the pioneering computer scientist who introduced the null pointer concept, has famously called his billion dollar mistake.

The functional and type safe solution to this annoyance would be the the type Option or Optional (in Java, Scala, Kotlin, Swift, SML, OCaml, Rust) or Maybe (in Haskell, Agda, Idris). Depending on the implementation, this type may be monadic.

In Scala, Option is a monadic type and has two subtypes Some or None. We will discuss monads in the section on algebraic data types. For now, going by the above box or container metaphor, if you think that in your variable there maybe some value or optionally none at all then you can put it inside an Option box. To check if there are any valuables in the box, you can simply check the type of the content instead of various 'falsiness' checks or nullness checks on the value of the content itself. The type is is guaranteed to be Some if something is present or None otherwise. There also exists another similar trio called Try, Success and Failure in Scala. They essentially form a more concise syntax and are used when catching exceptions could be needed as opposed to just dealing with presence or absence of values.

We will explore examples of the usage of both of these trios when we later discuss pattern matching based on types and control flow structures like try-catch, match-case or for-yield.

**The Normie Types**

These are the common, necessary but boring types that will become interesting when we start composing them with other types and weaving mind-bending - and hopefully helpful - structures later.

I. Byte, Short and Int

These types have trivially defined value spaces. Available methods for each type will defer as relevant.

val u = 42  // defaults to Int type
val b: Byte = 1 // (-2^7 to 2^7-1] i.e. -128 to 127
val s: Short = 2 // (-2^15 to 2^15-1] i.e. -32,768 to 32,767
val i: Int = 3 // (-2^31 to 2^31-1] i.e. -2,147,483,648 to 2,147,483,647

II. Long, Float and Double

These are pretty much the same as the above numerical types except they allow for bigger ranges and, in case of Float and Double, fractional values with floating point precision.

val l: Long = 1 // (-2^63 to 2^63-1]
val f: Float = 2.0 // 32-bit IEEE 754 single-precision float
// 1.40129846432481707e-45 to 3.40282346638528860e+38
val d: Double = 3.0 // 64-bit IEEE 754 double-precision float
// 4.94065645841246544e-324d to 1.79769313486231570e+308d

III. Char and String

A Char is a literal from the Unicode charset. A Char can be cast to its corresponding position in the Unicode charset as an Int, like you can in most languages.

scala> val c: Char = 'q'
c: Char = q

scala> val i: Int = c
i: Int = 113

scala> val emoji: Char = '☺'
emoji: Char = ☺

scala> emoji.toInt
res0: Int = 9786

A String is defined as a sequence of Chars. You assign a string using quotes:


val strQ = "Now I am become Death, the destroyer of worlds - J. Robert Oppenheimer"

val listToStr = List("If I'm not back in five minutes", "just wait longer").toString
// output: List(If I'm not back in five minutes, just wait longer)

Scala String relies on java.lang.String but is also augmented by many useful utility methods from the StringOps class.

It is not necessary to learn these methods or those of any Scala type by heart. You should just get more intimate with the docs and always check the docs before writing a routine or standard looking operation on your own. You can likely also discover them using your IDE's autocomplete or inline documentations.

IV. The Big and The Rich

There are StringOps equivalents for the other the other value types called RichBoolean, RichByte, RichChar, RichDouble, RichFloat, RichInt, RichLong and RichShort. These proxies provide additional methods to the above value types. Unlike the case in Java with its primitive and boxed reference types, this pattern allows for keeping the value types lightweight while still providing a rich API and therefore fewer use cases for boxing and unboxing due to performance vs convenience trade-offs.

Besides the Rich* ones, scala.math package provides BigDecimal and BigInt classes. These are for calculations with floating-point numbers of arbitrary precision starting with a default precision approximately that of IEEE 128-bit floating point numbers.

Next on 'Types of Types'

To keep the posts from going beyond optimal lengths, we will explore each of the next 'levels' of understanding and defining types in their own posts. Here's a sneak peek.

2. Function weds Data: Domain and Co-domain Spaces

Here we will introduce functions and methods together with objects and classes. We will see how OOP augments the power of functional programming and how best to avoid the many pitfalls of OOP.

2.1 Object and Class

2.2 Functions and Methods

2.3 Parameter Types and Return Types

3. Abstract Data Types: Types with Structure and Behavior

Here we will rediscover the good old data structures mostly used in programming through a more formal, functional and scala-ble lens 🧐.

3.1 Sum and Product Types

3.1.1 Union or Tagged Union
3.1.2 Tuple and Record

3.2 Set and List

3.2.1 Unordered and Non-duplicated
3.2.2 Ordered and Random Accessible

3.3 Maps

3.4 Stack and Queue

3.5 Graph and Tree

4. Algebraic Data Types and HKTs

5. A Gentle Introduction to Category Theory

Here we will use the Scala concepts and Type Theory topics thus far to go for a deep dive into Bartoz Milewski's excellent course on Category Theory .

Beware that category theorists are sometimes insufferable and gave birth to memes like this one,

'A monad is just an endofunctor in the category of monoids. What's the problem?'

or this one below:

Further resources:

D. L. Parnas, John E. Shore, David Weiss: Abstract types defined as classes of variables, https://dl.acm.org/doi/10.1145/942574.807133
Tony Hoare on his infamous billion dollar mistake: https://www.youtube.com/watch?v=kz7DfbOuvOM
Official Scala API Docs and resources: https://www.scala-lang.org/
L.G. Meredith, Pro Scala: Monadic Design Patterns for the Web: http://patryshev.com/books/GregoryMeredith.pdf

Play with Spring and Angular: Getting Started

Risav — Thu, 26 Mar 2020 04:58:41 +0000

In this series, we will explore full stack development with Play, Akka, Spring modules and Angular. This will also help you understand how projects like nep.work are built and what one might need to learn or revise to be able to contribute to the nep.work core stack or to any Play and Angular based stack, for that matter.

We will start this series by installing the command line interface tools for Play 2.0, Spring Boot and Angular. I strongly recommend using a linux distro with a good package manager and a sensible terminal emulator for the best developer experience.

SDKMAN and JVMs

Download SDKMAN from sdkman.io. If you like curling, run:

curl -s "https://get.sdkman.io" | bash

This shows all available installs on SDKMAN.

sdk list

You have some choices of JDKs to choose from.

sdk list java

I would suggest Amazon's Corretto if you will be deploying to AWS as it is always a good idea to have development, staging and production environment parity whenever applicable.

You can also use AdoptOpenJDK or the magical GraalVM (strongly recommended) if you are a polyglot developer or want to experience the best available high performance VM.

For Corretto:

sdk install java 11.0.4-amzn

For GraalVM:

sdk install java 20.0.0.r11-grl

Please update the version numbers in this article yourself in the future. For SDKMAN, you can use sdk list <package> to see available versions.

Spring Boot

Install springboot:

sdk install springboot
spring --version

Let's run an obligatory hello world to see if everything is running fine using a helloWorld.groovy file with the following content:

@RestController
class SimpleWebApplication {

  @RequestMapping("/")
  String welcome() {
    "Hello World!"
  }
}

Run it using Spring CLI:

spring run helloWorld.groovy

This command will resolve all dependencies and start a tomcat install on the default port 8080. Check your browser or curl localhost:8080 to see if Hello World! has been displayed.

Scala and Play

You should strongly consider using Scala and Play if you are interested in leveling up from Spring Boot/Java. You can still use Spring Data and other awesome spring modules in Scala/Play.

Installing Scala and sbt is simple:

sdk install sbt
sdk install scala

You can now create a sample Play app with a single command:

sbt new playframework/play-scala-seed.g8

To run it simply type:

sbt run

This downloads all the dependencies and starts the system.

In a browser, enter localhost:9000 to view the welcome page.

Nodejs

We will be making use of nodejs' package manager npm, which comes bundled with nodejs. Download it from the download page of their site or via your package manager as explained here. For example, to get Node.js v13.x (with full ICU/i18n support by default) on Ubuntu you would run:

curl -sL https://deb.nodesource.com/setup_13.x | sudo -E bash -
sudo apt install -y nodejs

It is a bad idea to use sudo with npm for security reasons. A simple better solution is to set it to install packages to your home directory and then recursively chown the npm directory with your user and group.

mkdir -p ~/.npm/prefix
npm config set prefix ~/.npm/prefix
sudo chown -R $USER:`id -g -n $USER` ~/.npm/prefix

Now we need to update the path environment variables by adding the following in any one among ~/.bash_profile or ~/.bashrc or ~/.profile files.

# set node to use user's chowned directory
export PATH="$PATH:$HOME/.npm/prefix/bin"
export NODE_PATH="$NODE_PATH:$HOME/.npm/prefix/lib/node_modules"

After saving the above addition to the file, you have source the file e.g.

source ~/.profile

It is a good idea to enable the use of npm's cache whenever possible, especially when you have a lot of projects with similar dependencies. This is effectively the same as setting the now deprecated 'cache-min' option to 9999999:

npm config set prefer-offline

Angular

After nodejs and npm have been installed and configured, install angular CLI globally:

npm install -g @angular/cli

Now create and run your angular hello world using ng new and ng serve:

ng new hello-world --defaults
cd hello-world
ng serve -open

In your browser you can see your new angular application being served at localhost:4200.

IDEs and Editors

For IDEs, you could use Spring Tool Suite (STS) version of Eclipse for Spring and Visual Studio for Angular. For working on both using the same IDE, you can also install STS on Visual Studio Code or just use Intellij Ultimate, which would be an expensive option but a worthwhile one if your company/team decides to use it. In case your IDE does not recognize the SDKMAN installed JDK, create these symlinks to the usual locations:

sudo ln -s ~/.sdkman/candidates/java/current/bin/javac /usr/bin/javac
sudo ln -s ~/.sdkman/candidates/java/current/bin/java /usr/bin/java

Bon Voyage!

Now we are all set to explore Scala, Play, Spring and Angular in the future installments of this series on nep.work stack related tutorials.

We will also use Java 11+, Scala 2.13+ & Typescript 3.8+ from this setup for exploring advanced CS, category theory and other pure mathematics concepts in the Mathematics' (An)architecture series .

Time - II

Risav — Wed, 25 Mar 2020 13:38:02 +0000

The ABCs and 123s of Time

Time is also in an existential crisis. In the previous post in this series, we have touched upon the semantic crisis of time and the possibility that time may not exist as a feature of the universe as it is but rather a feature of our modes of understanding of the universe. In this second part of the series, we will focus on three ways of understanding time and how these can be represented in mathematics or physics terms. Hopefully this will build up the toolkit we require to easily dissect the more complex philosophical and technical arguments I would like to present in the third and fourth part of this series.

These three conceptions of time are also highly problematic. McTaggart’s A series, B series and C series of time each have ugly self-contradictions, infinite regressions and outdated philosophical arguments. Furthermore, even mathematics and physics representing the various aspects of these 3 different possible universes do not claim to define time but rather just measure, calculate or represent these conceptions of time. We will be visit Euclidean and Minkowski spaces where time may even become an imaginary number via Wick rotation, whenever it makes it easier to ‘shut up and calculate’. I am getting ahead of myself here so we will start at the beginning of philosophy of being and becoming in the west and then jump 2 millennia to find McTaggart again.

Heraclitus & Parmenides

The pioneering process philosopher Heraclitus of Ephesus was also prolific in his scientific and logical research. He was a cosmologist, empiricist and a dialetheist logician. For dialetheists, there are propositions that can be both true and false in their logical system, which is recently finding support in modern paraconsistent logic. He also believed in an ever present flux and change. This concept also happened to lend a cool name to my first computer science research group and its online education forum at my university: ‘Panta Rhei’ which means ‘everything flows’. For Heraclitus it was not just enough to say that everything is always flowing. He would also insist that everything is always ultimately ‘fire’. This fire too is always in a flux because everything is either fueling the eternal monistic fire or being burned down to ashes by it. Eastern scholars, including Krishna from the epic Mahabharat, also had similar sayings about a single monistic energy or spirit always changing its form, dividing itself infinitely into many forms yet remaining complete, infinite and undying.

(This infinite eternal fire would be an interesting topic for a later blog post, when it becomes relevant for our discussions of infinite streams in programming and infinity's types in the Mathematics' (An)architecture series or for the upcoming theoretical quantum computer science topics.)

So energy flows and everything flows, all the time. Just like a river always flows downstream. Then, does time itself flow as well? Heraclitus found it impossible to step in the same river twice as the river was always becoming anew. This is similar to how we perceive that a time once passed can never be stepped back in again since current time always seems to be becoming a later time. Two millennia later Nietzsche built upon this and went so far as to say that fixed subjects and entities are not at all possible due to everything’s eternal state of becoming. Becoming in itself is the very process of change in time and space. Perhaps time does flow or have its own eternal state of becoming as well since everything in the world does?

Perhaps not. Perhaps time is not a part of ‘everything in the world’ in the first place.

The pioneering metaphysicist Parmenides of Elea, around the same time as Heraclitus, provided one of the first sustained arguments i.e. via a set of premises, deductions and inductions regarding the lack of flux or change in all of reality and regarding the impossibility of actual change, among other things. He argued that whatever is, is. And whatever is not, cannot be. This was an early attempt at defining being philosophically. Furthermore, nothing can come out of nothing, or to be fancy by using Latin - ‘ex nihilo nihil fit’, according to the sustained arguments under the primitive Parmenidean logical calculus. For something to seemingly change, it already has to be that which will provide the illusion of change. But it is in the very nature of it to not really change from what it essentially is, while still making the appearance of change.

(This also assumes some sort of conservation, especially conservation of mass-energy for physical entities. This would be more fodder for the aforementioned upcoming post on infinitude.)

The Being and The Becoming of Time

Could it be that both Heraclitus and Parmenides are correct?

In my previous post ‘A Recipe for making a Developer’, I had argued that Neil Postman’s thesis in ‘Amusing Ourselves to Death’ that Orwellian 1984 never came into being but Huxleyan Brave New World did was in fact not entirely correct. 1984 is more about a politics-borne dystopia and Brave New World is about a social dystopia. I had made a digression, much like this one, to outline how elements of both dystopias can and do co-exist in our societies. In a similar fashion, I would argue that both Heraclitean ‘panta rhei’ and Parmenidean ‘ex nihilo nihil fit’ are arguments, sustained or otherwise, for two very different albeit interlinked contexts. Having them together is not contradictory since a logical contradiction does not occur when a proposition is true in one context and false in the other. I would argue therefore that there is a false dichotomy between eternal state of being of all of existence and eternal state of becoming of different aspects of reality. I must also stress that I am not invoking dialetheism here and that this is still not a popularly accepted argument in academic philosophy.

Heraclitus is concerned with becoming. Parmenides is concerned with being.

With this basic reading of Heraclitus and Parmenides, we are probably equipped to appreciate the modern continuations of their seemingly contradictory arguments. As some of you familiar with the previously mentioned works of McTaggart might have guessed, Heraclitus’ position leads to the tensed and flow-compliant A series of time whereas Parmenides’ position leads to the non-tensed, indexed and unchanging time in B series.

As mentioned before, becoming in itself is the process of change in time and space. So does the becoming of time itself require an underlying meta-time? And what about the meta-time itself and how far down do these turtles go? We can escape from infinitely regressive problems like these in A series by using B series. McTaggart believed that there were problems in B series as well and further that the problems in both A series and B series go away in his less popular C series.

The A and B Theory of Time

Following the A, B and C series of time of J.M.E McTaggart, Richard Gale coined the terms A-theory and B-theory. Like most others who studied McTaggart, Gale too did not want to entertain the idea of C-series for reasons we will explore later in this series. Maybe we will find some redemption for the C series after all.

In an A theoretic universe, time flows from past to the present to the future. In a B universe, there is no flow.
The B universe is a multi dimensional block in which the ‘here’ and the ‘now’ are structurally similar. Anywhere you are is ‘here’ for you. Anywhen you are is ‘now’ for you in the same sense. 'Now' is just where you have reached in time. 'Now' is not flowing into the future with each instant. Just as the spatial coordinates change with your body's movement across space, the time coordinates change with your existence’s unending progression across time.

Saying time flows is just as ridiculous as saying space flows. Our existence marches across time, not the other way round.

In a B Universe, addressing the beginning or the end of an entity or even the universe itself is tricky. Every point of time exists eternally but just becomes inaccessible to some observers by becoming either their past or their future while being ‘the present’ for some other observers. An arbitrary event A in time may occur before a particular event P for some observers while A may occur after P for some other observers if A and P are not causally interlinked.

I mention ‘the present’ in quotes because in B theory, there is no present, or past and future for that matter. However the present may not exist at all and this may be true not just in B theoretic universes. Our senses are never experiencing the present since sensation and perception is never instantaneous. We cannot even ascribe a duration to the present other than, if we are being too stubborn about it, an infinitesimal. However going anywhere lower, let alone infinitely lower, than Planck time does not make sense as our reality itself is built up using time quanta of Planck time and space quanta of Planck length. In other words, in our reality space and time does not have a more fine grained 'pixel resolution' than Planck length and Planck time respectively.

In case you are wondering, Planck Time is not a good candidate either for the duration of 'present'. There is no reason to believe that Planck Time, derived from Newton’s universal gravitational constant G, Einstein’s relativistic constant c and Planck constant ħ, has any physical significance in how we experience time. It merely represents the time required by light to travel one Planck length in an ideal vacuum of space. Consequentially it describes, firstly, an approximate time scale at which quantum effects dominate, and quantum gravitational effects might become important and, secondly, the upper bound on the frequency of any wave. Nothing we ever do or experience in our human lives or even in our advanced scientific experiments occurs at the Planck scales.

The A theory is a common sense theory of time that we find easy to digest. We can compare time to the Heraclitean river. Time does seem to be flowing through past, present and future after all. The B theory however is the more scientifically sound theory of time. Einstein would agree with it since his redefinition of space-time and Minkowski’s Minkowski space is what led to the block universe model espoused by B theory in the first place. We can compare it to the Parmenidean view of unchanging reality or roughly to an ocean which displays tides or currents in some sections but remains unchanged overall. In a famous letter of condolence to the family of his childhood friend Besso, Einstein wrote,

“Now he has departed this strange world a little ahead of me. [...] That signifies nothing. For us believing physicists, the distinction between past, present and future is only a stubbornly persistent illusion.”

We should note that although B theory posits that past, present and future are illusory and eternally exist as indexicals, B theory does not imply or constrain us to a deterministic universe where one particular ‘future’ is fixed in the same way that B theory and relativity do not constrain us to a single absolute ‘past’ for every observer anywhere in the universe. We will see that the block model of the universe may not be contained in just 3 dimensions of space and only 1 of time and that there may thus be enough wiggle space for a non-deterministic future.

Also note how we end up having to use A theory terms like ‘past’ or ‘future’ to describe aspects of B theory. The reverse is also true and thus equally problematic in establishing a primacy or validity of one theory over the other. B Universes would have a hard time reconciling the concept of change and description of processes according to McTaggart. So McTaggart originally rejected both his A series and B series.

At this point, we have reached the A and the B from the title of this post. Before we dive into the C, we should probably first look at the 123.

Time on 1, 2, 3 or more axes

We are used to time being represented along a single straight line. Facebook, Twitter, blogs, Windows 10 and many other popular software interfaces utilize this familiarity to represent chronological ordering of life events, tweets, posts or recently used applications. Linearity of time was not always as naturally accepted before though. Many civilizations and traditions viewed time as a cyclic series. This is evident in our analog clocks which describe the hour of day in modulo 12 or modulo 24 numbering or in our calendars which describe the month of year in modulo 12 numbering schemes. Cyclic nature of time also made sense in predicting crop seeding and harvesting periods or other similar daily or annual loops, back when global warming had not messed with the change of seasons. Since time is famously defined as that which the clock measures, we could have insisted - before the modern quartz, digital or atomic clocks were invented - that the time is the measure of the intervals in our planet's cycles of rotation around an axis or revolution in an orbit.

We could represent these circular timelines (time arcs?) using polar coordinates. For this we simply have to draw clock hands on top of a polar coordinate system to represent time. The first coordinate can be stipulated to be a constant or a unit distance from the origin. We can safely ignore this for our polar timekeeping activities. The second coordinate which contains the angle of the hand of the clock would be more interesting. Adding more hands to the clock with further subdivisions of the circumference is also possible if we want to have more precision than just seconds. In this way we can keep having an arbitrarily large number of angles providing us more and more precise time. However these representations can still be mapped from polar coordinates to a straight line without loss of information and precision i.e. these are both isomorphic representations of time. Intuitively it seems as if a polar coordinate based circular time representation is 2 dimensional. The plane on which the polar coordinates are drawn is indeed 2 dimensional and we need two numbers for specifying the position of each hand of the clock. Since we have stipulated that each hand of the clock is going to be of the same length, we are now left with 3 angles or n angles if we have n hands on our clock. We can put these angles on a n-dimensional Cartesian coordinate system and, by construction, this n-dimensional coordinate representation would be isomorphic to our 2 D coordinate representation.

So the n D representation outlined above is the same as the 2 D polar coordinate representation outlined above. But there's more. This 2 D representation is in turn identical to the 1 D representation based on a usual straight timeline with which we are all familiar. The proof is trivial as one can easily partition a straight line into as many divisions as there are on a clock for the hours and minutes marks. Then one can simply make a one-to-one mapping for each of the markers on the straight line with those on the clock. For a more visual proof, imagine, draw or animate a circular clock wet with ink along its circumference wherever you find marking for the hours and minutes in the clock. Now wheeling or rotating the clock on top of a paper sheet in a straight line can map each of those 12 hour markers and 60 minute markers on the clock to the corresponding markers on the straight line. The straight line will have hour markers equal distances apart and will have the same number of equidistant minute markers between them.

One key insight from this mental mathematical athletics, mathletics if you will, is that the number of axes for representations do not matter much if they contain the same amount of information. A corollary insight would be that you can extend one dimensional linear time to any number of dimensions if you have a proper mapping or transformation mechanism.

There is a powerful concept of the 2 D 'imaginary time' in different areas of physics like cosmology, special relativity and quantum statistical mechanics. It can also be shown that Euclidean QFT in n dimensions is identical to quantum statistical mechanics in n-1 dimensions. The proof for this and the construction of 2D imaginary numbers both use a mapping mechanism called Wick rotation and are quite involved. Although we cannot use simple coordinate system transformation like before to prove this, we can see from the above exercise how one can map down or up to a lower or upper dimension. We can use a simpler tool than Wick rotation called a metric for better understanding the justification behind imaginary time.

A metric is just a name we give for the generalization of the idea of distances between points in any given mathematical space. A mathematical space, often formed using a polar coordinate system or a Cartesian coordinate system, is an abstraction detached from physics and does not always get used to represent the physical notion of space. The metric or distance of a mathematical space is also detached from any physical units of distance. In a two dimensional Euclidean space, also known as a Euclidean plane, the metric is simply given by the famous Pythagorean theorem. For instance the distance of a point from origin is the square root of the sum of the x coordinate squared and the y coordinate squared. In a three dimensional Euclidean space, the metric involves the square root of the sum of x coordinate squared, y coordinate squared and z coordinate squared. This trend for the metric continues for higher dimensional Euclidean spaces. Even in the infinite dimensional generalizations of Euclidean space, also known as Hilbert spaces, there are exact Pythagorean theorem analogs.

The mathematical space that represents the relativistic notion of space-time needs to be 4 dimensional but is not exactly just a 4 D Euclidean space. These 4 dimensions are minimal unlike the 3 D and n D Euclidean spaces that we constructed above because we do need a bare minimum of 4 different axes to house our 4-tuple or, more accurately, a 4 vector representing the 3 D Euclidean space with length, breadth and height, and an additional dimension for time, which is treated differently from the other 3 dimensions. Minkowski had found that his student Einstein’s postulates of special relativity also needed his 4 D mathematical construction, which he had originally developed for Maxwell’s equations of electromagnetism. The metric for this mathematical space is also called an interval and is given by the usual Pythagorean formula but with negated time:

Poincare had presented a simpler form of this expression when introducing complex Minkowski spaces:

The imaginary number i has the special feature, by definition, that multiplying any real number with its square negates that number. Note the we had a negative square of time in the metric in the first place because of how space and time interact with each other in our universe. So it makes sense to allow for the time dimension's values to be placed on the imaginary axis so that we have the more elegant and Pythagorean looking metric expression:

And there you have it. Time is useful not just as a real but also as a complex or imaginary number when it makes our mathematical models simpler.

The Higher Dimensions of Time and The C series

Since we already came across imaginary time, it would be natural to question if further generalizations like quaternionic time, octonionic time or n-onionic time also make sense. In the next post in this series, we will evaluate the usefulness of these representations and see what, if any problems, they solve or what predictions they can make. We have seen so far that abstractions and mental constructs, even complex ones like a complex Minkowski space have usefulness in reality and are no less ‘real’ just because they are abstract. The mathematical models we have looked at so far are quite powerful in solving real world problems and predicting aspects of our reality. One can say that as long as we are able to do all that, and create GPS, cell phones, internet, spaceships etc, do we really need to understand time any better?

I would say that it is all the more reason to understand time, one of our most profound mathematical models of reality.

To this end, in a true Hegelian fashion, McTaggart reached the C series of time via dialectics. A series was the incumbent thesis. B series was the antithesis and C series was supposed to be the synthesis. McTaggart also employed modern metaphysics and analytic philosophy in defense of his neo-Hegelian view in the C series. We are about to reach the C series by understanding his arguments through parallels in the scientific community’s evolution of thoughts and ideas. The next two posts will be dedicated towards explaining this position and using it to dive further into the phenomenology and physics of time. We will also have a look at some more definitions of time and imaginary time from various scholars in the field and see if they too are fundamentally noumenal or mere abstractions for aiding calculations and without a physical meaning. We will see further uses of the ABCs and 123s and more explanations of the C in the upcoming discussions, which I hope will be very rewarding to the few of you who have read this far.

[In this series, I am trying to compress multiple millennia of thought evolution and probably an entire semester of academic work on the philosophy of time, which I would have loved to take. So I am probably being hasty, incomplete and incorrect at times. I have tried to link to further readings whenever I skip detailed explanations of the fundamentals. I would love to find corrections, links to resources and feedback, especially for these last two posts in this series as I am writing these also to inform myself better on these topics. I am not shy regarding invoking Cunningham’s law to this end.]

Time - I

Risav — Wed, 25 Mar 2020 13:35:25 +0000

The Unreality of Time

Time is in a semantic crisis. Physics and metaphysics should have resolved this by now. However it is hard to find a consensus when both disagree even on the fundamentals, let alone a rigorous definition. The closest that physics has come to metaphysics of time in recent times was probably when Einstein developed his theories of relativity, the first of which came out in 1905 and the second in 1915. He changed our classical view of time as an absolute, linear, monotonic and laminar flow, usually understood as a progression towards higher entropy or towards later events.

This conception of time is highly problematic. Flow of time is provably not absolute, linear, monotonic or laminar. Furthermore, instances of time are not bound to any particular absolute ordering, especially if not linked by a direct causal chain. And even when a subsystem is moving towards lower entropy, time is still moving ‘forward’ instead of ever reversing.

Cambridge idealist philosopher J.M.E McTaggart published his seminal treatment 'The Unreality of Time' in 1908. Its slightly different, more mature defense appeared in his 1927 work 'The Nature of Existence'. Especially in Vol II of the latter, his proof of unreality of time builds upon a seemingly careful Hegelian analysis of the foundational requirements of a metaphysical system like time or space. As a teacher and friend to Russell and Moore, the two other members of the 'The Mad Tea Party of Trinity', and a member of the Cambridge Apostles and the Bloomsbury set, he had overwhelming influence on his contemporary and later generations of thinkers and writers. Hegel himself was an important source of origin for most of the great 19th century philosophical ideas ‘from the philosophies of Marx and Nietzsche, phenomenology, German existentialism, and psychoanalysis’ according to Maurice Merleau-Ponty, a philosopher I admire more than most others and to whom we will come back to towards the end.

Before we look deeper into it, it would help to note that the underlying subtext in these bodies of work, a triumph of neo-Hegelian idealism and modern physics, is that our knowledge of time is indistinguishable from our conception of time or our ‘modes of representation’ of time. Time and space may not even be features of the phenomenal universe - the universe in itself without anyone to perceive or observe it - but rather just of the noumenal universe - the one that exists only as reality's map in our minds. This map of reality has grown to be almost as large as reality itself.

The pre-relativistic term ‘timeline’, as opposed to ‘worldline’, still pervasively permeates the zeitgeist thanks to the common sense assumptions about time's linearity. Some of our most used interfaces have timelines, something akin to the general concept of linearly ordered events. Subverting such linearity that we are getting accustomed to on a daily basis is a popular trope in movies and story-telling in general, even when they are not about time travel or alternative histories or possible futures. Thus it is not hard to see why relativity, curvature and dilations of time do not fall under our general understanding of time but rather under sci fi, even after a century.

In this series we will use the theories of relativity, quantum physics, McTaggart, Hegel, Lacan and Merleau-Ponty to arrive at where time stands currently. We will then move further towards the future of semantics of time partly by going all the way back to Aristotle's Physics and Vedic literature and partly by going, ahem, back to the future with Prosser, Shuler and MJT.

COVID-19 Simulation for Nepal: A Call for Collaboration

Risav — Wed, 25 Mar 2020 13:29:43 +0000

We are a group of national and international experts and scientists in the area of public health research, quantum statistical modeling, artificial intelligence, big data analysis and semantification. Our current goal is to enhance our powerful predictive models and simulation for the spread of COVID-19 in the Nepali population given different scenarios and high level decisions, including the best and worst cases.

Models and simulations based on our current approaches have many proven benefits including helping governments and relevant authorities make informed decisions. With large amounts of real world data and latest advancements in information technologies, we can discover previously unseen patterns and conclusions that cannot be attained through classical statistics and methods. We have a rare but highly prescient and state-of-the-art tool to potentially save many Nepali lives and livelihoods.

The core algorithm and the central model for this simulation was developed by Manish J. Thapa, a quantum physicist at ETH Zürich, one of the most historically significant research institutions in the world. His own research and some other leading research in this field from his peers and contemporaries, especially regarding responding to cascading disaster spreadings and frameworks for intelligent network adaptation, have been used to construct this simulation, which brings these findings together via an intelligent many-model approach. This simulation also includes the standard SEIR model in epidemiology. However, we have focused on building upon the existing established knowledge and taking it a few steps further instead of wholly depending on one single model. We believe this research, when combined with further real-time data from various sources will be a substantially helpful tool in Nepal and even at a global scale. However, we certainly need to focus first on Nepal given our lack of national scale technical collaboration.

Teams That Formed This Team

The aforementioned 'we' represents a growing collaboration. Manish and I have reached out to multiple organizations and individuals after he first shared his research.

NAAMII, an applied maths and AI based research non-profit, is the central body coordinating this entire effort. It has been instrumental in bringing together its network of experts in Nepal, US, UK, and Switzerland and has effectively created the platform Nepal has lacked for a national and international scale collaboration in this area.

Previously introduced nep.work group in EU/US along with our partner company in Nepal, Meraki Corp, is providing its advanced and secure data platform and coordinating with various current and potential data providers.

Our group takes privacy concerns and data anonymization very seriously. It has protocols and technologies in place for assuring the data providers and Nepali citizens about a transparent and careful handling of their data.

Recently, we were joined by Dr. Kiran Raj Pandey, who is a prominent figure in this field and has also been in touch with government officials regarding his ongoing SEIR modelling efforts for Kathmandu.

Leapfrog, which is one of the supporters and close partner of NAAMII and their sister company Machnet, which provides guidance and support to nep.work group especially in its fintech efforts, are providing their support in bringing in further invaluable resources and organizations to this collaboration.

Please Join Us

We would like to call upon you and all organizations, businesses, and individuals who are in a position to provide us reliable data regarding Nepal’s health infrastructure, road traffic flow and human mobility. It is of critical importance that we as a nation track human movements and hospital infrastructure to be fully informed and prepared for what's coming ahead.

We would like to also highlight CovidNepal.org, another independent and noteworthy effort for this cause, that will be of help especially in aggregating hospital related data. Please contribute reliable data to it and/or promote it to hospitals and organizations in possession of relevant data.

Here are some topics and examples regarding how data aggregation, especially from telecommunication service providers, can help:

Crowd Densities Analysis

Finding out lots of phone GPS and cell phone tower pings near a large vegetable market every evening would be a sure sign that we need to decentralize grocery supply.
Finding out that the crowd densities change more during the day than at night will further substantiate our findings based on data from a leading Nepali ISP that not enough people have been staying at home during the day

Human Movements

Finding out how many cell phones previously pinging Kathmandu's cell towers are now pinging towers elsewhere will give us an approximation of how many people have left Kathmandu valley or how they are moving from and to different places in the last few weeks.
GPS location reports, if possible to aggregate, will be even more precise and may provide us real-time data for the simulation.

There are more possibilities than these regarding improving the models behind our simulation. Please let us know if you have further ideas or if you have already made efforts similar to ours.

Contact Us:

NAAMII: info@naamii.org.np
Manish J Thapa: manish.thapa@phys.chem.ethz.ch
Risav Karna: risav@merakinepal.co

A Recipe for making a Developer - I

Risav — Tue, 25 Feb 2020 17:33:28 +0000

Amusing our Devs to Death

Let’s make a developer. I obviously do not have a literal kitchen recipe for you because although a sizeable portion of developers likes getting baked, putting mathematical minds in ovens had disastrous results last century. We now have less brutal ways to prepare and dispose this brave new world’s modern labor force, with or without indentured servitude. Both Huxleyan and Orwellian dystopias can create efficient developers for your latest visionary tech sweatshop. The question is what pedigree of a developer you need, how much they should feel like they should get paid and how easily replaceable you want them to be. Hint: you need to set your story straight for the first two and, as for the last, the most easily replaceable ones are either the better ones or the worst of them.

Two Ingredients

One secret sauce in all variations of this recipe is to use tech to make them feel better or even smug about themselves be it after a mere JavaScript boot camp, a CS degree or a Ph.D. in category theory. They each need to find pleasure in explaining to themselves and to you how the latest tree-shaking optimizations allow them to be free of npm bundle phobia or how they can optimally invert a binary tree in their sleep or why their fancy burrito is just a monoid in the category of endofunctors, respectively.

As important as this pungent ingredient is, an even more important restriction is that you should never - never ever - let us question the fact that we are no more than just the modern equivalents of craftsmen, smiths, and laborers that build structures like houses and churches without much say in the big picture. Instead, we must be made to feel as if we are geniuses doing our own Manhattan projects or at the very least, ‘making the world a better place’. This is unquestionably achievable for us through ‘digital transformation and automation’. It squarely fits within our little domain of expertise making us feel good as your messiah or one of the apostles – in cases where the team leader is the actual one true visionary, the second coming of Lord Steve Jobs himself.

With just these two things in mind, you are already half set for making a bonafide instant hire. Within a fortnight or two, you will have a fresh batch of JavaScript engineers ready to forever change the world. Add a week and they may even become scrum-certified, project-managing, medium-blogging, self-important, rockstar developers.

You will notice that those who actually understand our place in the corporate hierarchy are most likely humbled by imposter syndrome and office politics and, more often than not, functionally depressed or about to be. These will soon become your 'problem employees' asking for more say in what they do or more pay or both or – God forbid – resignation. If you have candidates of this nature, I would suggest the Huxleyan recipe.

Father & Son

As a developer currently being brain-damaged by JavaScript and co., I would like to introduce this concept to you via NgRx several levels of indirections and digression. Andrew Postman, Neil Postman’s son, reiterates the core of his father’s work that dissects Huxley and Orwell in his Guardian piece as follows:

“The central argument of Amusing Ourselves [to Death] is simple: there were two landmark dystopian novels written by brilliant British cultural critics – Brave New World by Aldous Huxley and Nineteen Eighty-Four by George Orwell – and we Americans had mistakenly feared and obsessed over the vision portrayed in the latter book (an information-censoring, movement-restricting, individuality-emaciating state) rather than the former (a technology-sedating, consumption-engorging, instant-gratifying bubble).”

This is still a very American narrative regarding our sociopolitical climate. Most of our world including highly developed nations like the US with high concentrations of developers did enter the cliched brave new world but never really left 1984 either. The former is more about our social order and the latter is about our political order. Countries like the US, China and many of the rich cities in middle-east have managed to concurrently pull off both exceedingly well. Many other nation-states are soon to follow this trend of a liberal-but-Huxleyan social identity and a conservative-and-Orwellian political identity. Any economic entity like your new tech sweatshop or revolutionary startup (or both) tautologically falls under this regime too.

The Huxleyan variant

If you go by the Huxleyan recipe, for the morale and motivation problem mentioned above you would need to up your game in using seductive tech privileges, access, and gifts here and there as Pavlovian carrots and sticks. You might have noticed how pimps in movies also play the role of a drug-dealer or have one around. They have known what Huxley always suspected governments and those in power choose to do with narcotics and pleasure-seeking human nature even before the posturing of ‘war against drugs’ and the epidemic of the ‘opioid crisis’ became a thing. The 'soma' drug of our brave new world is not a pill. It is the dopamine hit of social media approval and digitally-crafted personalized and addictive nonsense. It is delivered through the devices many of us are going to queue up for with our credit cards and savings right after this year’s product launch keynote.

Your developers need this instant gratification themselves too to be able to whole-heartedly participate in pushing the soma to others around them. You have to construct distorted views of reality where they think (iff they manage to think beyond technology at all) that they are doing God’s work, without which society would fall apart. At the very least, you have to keep them inside a confined garden or a well, if you will, where they do not have to think much about the world beyond their code or of the socioeconomic ramifications of the features in their next release. This could take the form of secluded housings and transportations. It could mean antipodal distances from the assembly sweatshops. It also helps if you lead them to surmise how AI, and tech in general, will relieve us all of our mundane works and philosophize how pipe-dreams like Universal Basic Income will save us all from the developers’ jobs cannibalizing all human jobs.

The Orwellian-Huxleyan hybrids

Since the primary goal of Huxleyan citizens is to ‘find happiness’ and to be happy, the very purpose of tech entrepreneurship is to help them find it from their screens and devices. If you happen to be in an economy that is servient to bigger Huxleyan economies, your political order has to be Orwellian, the essential Huxleyan dual.

You have to have high-tech sweatshops for scaling up the aforementioned ‘consumption-engorging’ supply chain. You should thus make and preserve developers using the Orwellian recipe in this case. You have to hide information about what your developers are building and often who they are building it for. You have to remind them often about how lucky they are to have the job coveted and desperately needed by hordes of unemployed or over-qualified junior developers in the country. You can never allow them contracts that secure their place at your organization for anything more than half a year. Actually, it helps if you further outsource and do not hire them directly at all. You cannot be responsible for individuals. You only need to talk to the company serving them on a platter or à la carte for you.

(Disclosure: This author is currently rolling out a platform primarily for these kinds of workers.)

In practice, there is no purely Orwellian or Huxleyan company. Most companies are a good mixture of the two these days. You will find it more likely to find secure, well-treated developers living comfortably in London, New York and most of SF Bay area and Western Europe. These are predominantly Huxleyan communities fueled and placated by coffee, alcohol, weed, micro-dosing or even Burning Man-like festivals. They will be mostly addicted to technology more than any drug though, thereby confined to a self-centered growth focus and destined to see the rest of the world as just a set of problems curable by software and technology. I have listened and guiltily participated when they would wax poetic on topics like

how their weekend hackathon was for helping teen developers make the world a better place
which meditation apps are the best
how cryptocurrencies will solve the problems inherent in late-capitalism - while, ironically, speculating which unregulated coins are worth investing in
how Facebook providing Facebook-branded internet to the not-yet-connected billions is great for those countries.

Orwell feared those who would deprive us of information. Huxley feared those who would give us so much that we would be reduced to passivity and egoism. Orwell feared that the truth would be concealed from us. Huxley feared the truth would be drowned in a sea of irrelevance. Orwell feared we would become a captive culture. Huxley feared we would become a trivial culture.

Having a Cake and Eating it Too

I also used to interact with Asian/Indian developers living in the US or India who were constantly looking for their next job or a better one as they would be working as temps or externs from some outsourcing firm operating in the US or EU but originating in their home country.

After almost a decade in Germany, I recently started living and working from Nepal as well. I have started noticing more than before how my region of the world is producing prolific developers albeit putting them under certain different incentives and priorities. It is convenient for companies like Boeing or British Airways to be able to simply push the narrative in the news that the so-called $9-an-hour developers crashed their $100+ million Max planes or cost them £100+ million due to a flights control system changeover disaster. They still have to face the music but they can still claim to be a sound company with a good internal engineering culture. Or alternately, if questioned about bad outsourcing practices, claim that the technological problems are ‘local’ to the company exploiting the ambiguity of localness in a globalized corporate Möbius strip.

These ‘$9 developers’ are probably ethical and mindful in other areas of their lives. Since they are still making almost twice the regional average, I would guess they are probably also among the better developers from their universities and companies. I find it hard to believe that their mistakes are personal and not actually structural due to wrong contractual priorities (e.g. fast shipment and emphasis on bare minimum fulfillment of requirements) and bad supervision (e.g. doing a system changeover without coordinating well with the rest of the developers and technical personnel). This is a problem in how developers are made and less about their proficiency, which is traditionally improved by the company.

All of these musings so far cover just the secret ingredients and the underlying kitchen chemistry for our recipe. How could we do the whole process of manufacturing, packaging, freezing, defrosting and preparing a proper developer?

I would like to continue exploring this increasingly uncomfortable metaphor in the next title in this series since I have previously had complaints about my awfully long articles.

Wau Ϝ Wow

Risav — Tue, 25 Feb 2020 17:29:11 +0000

Let me introduce you to Wau,
Your new favorite of all numbers
For many a different reason
But here's only some for now
I could keep going on
But dev.to post limit encumbers

Here's one:
One is wau choose wau
And another:
One is wau factorial
Zero over one's infinite sum tower
Is really just a wau memorial

If I've compounded your interest,
e to the two i pi is wau.
But it gets better,
e to i to the e i o
Finds its shelter in e to the wau
To the tau wau wau

If you're dumb-founded, just reinvest
First, throw away your calculator,
As a log of a wow base breaks it
Next, buy a fractal exponentiator
And let's say the wau takes a hit
Then it still gives just another wow -

Makes no more sense than Brexit

A wow spiral definitely curls into its lone shelf
Allow trials infinitely, it unfurls its own self
It's not just maths, even physics gets wow help
Einstein's E to the wow over MC squared
Is wow to the two, but this news never aired
Maybe since its a con split personality 0 and 1 shared

Yet it's so uber cool no math lover hates it.

Vi Hart's con that inspired this wau wau wow poem:

youtu.be/GFLkou8NvJo

Mathematics' Anarchitecture & Processes for Programmers

Risav — Tue, 21 Jan 2020 03:02:42 +0000

MAP for Programmers

In the previous post in this series, we made an outline of mathematical areas of programmer interests that we will explore together in 2020.

A major portion of the post was about how first-order and/or propositional logic is isomorphic with categories and types. Since propositions are types, you can have such constructs as constraint types or process types and perhaps a protocol for interacting with other types. A simple way forward would be to simply use the commonly held concept of mathematical operators and the fact that these operators will always be 'operating' on n - tuples with elements of various types. It is fun to work on the operators themselves rather than with numbers.

Operators that preserve structure or map to a specific one are more interesting than the stochastic ones for now. At this point in the realm of what we call transformers and mutators. You will see that these are generalized nicknames for natural transformations and functors. We will be using these to build our basic data structures like multi-dimensional matrices, preferably in rasdaman on PostgreSQL. These matrices encode graphs and hypergraphs which we will be using in our collaborative system ( CoSys ).

We have introduced the co-planetary platform and nep.work in a separate post. We end the series on a more abstract note by talking about our internal and external language and about the sinks, links & sources.

The whole point is to make a map. And then to make a smaller map to navigate the previous map, ad infinitum. This structure is 12 tiered, 6 tiered, 4 tiered, 3 tiered, 2 tiered and 1 tiered in a 1D plane. In 2D, it is 12x6, 12x7, 12x7x2 and 6x6. In 3D, it is 3x3x3 and 3n+-1 x 3n+-1 x 3n+-1 dimensional. All kinds of data can be mapped on to this single monolithic immutable structure. The projection of such data, however, requires specialized DBMS and algorithms. For example, we will be using Druid for time series and stream data. For document storage, we will be using MongoDB or Mongo-like DB APIs. For key: value stores, we will lean towards memcached or redis. This is not to be confused with the Apache Ignite read layer of our persistence model for mathematics, and anything else for that matter.

Yes, we are still strictly only talking about mathematics and applied mathematics. We will shift focus towards 'pure' mathematics and forget the engineering concerns later when we define types and categories. We still have the responsibility to build the matrices and hypergraphs promised before. For our purpose of finding mathematical foundations and mathematical structures and founding a mathematical software based on those findings, we will need steps 7 through 12.

In the next post in this series, we will cover the origin of all of these ideas and the one ring to rule them all.

Three Rings for the Elven-kings under the sky,

Seven for the Dwarf-lords in their halls of stone,

Nine for Mortal Men doomed to die,

One for the Dark Lord on his dark throne

In the Land of Mordor where the Shadows lie.

One Ring to rule them all, One Ring to find them,

One Ring to bring them all and in the darkness bind them

In the Land of Mordor where the Shadows lie

Are the rings, dear dev, that form our API

Mathematics' Architecture & Processes for Programmers

Risav — Fri, 17 Jan 2020 15:52:24 +0000

This will be the 2020's web series about the foundation, architecture and deconstruction of mathematics. We will be mainly concerned with structures on top of which all of mathematics can find its foundations. However one cannot do much with just the foundations. We are going to discuss the known and the novel constructs with which we have built our mathematics.

We will start by observing an interesting shadow set of the same structure and, more interestingly, we will name the different shadows but not the structure itself. Once you have shadows from all the infinite steradians, you have the complete silhouette. You can go further and map the details of the structure instead of just getting its topographical outline.

When you map geological points and events in a network, you will see that it helps to have topological maps aside from geologically correct maps. Maps are concerned with distances and physicality of things. However mathematical spaces and sets are concerned with other variables such as time and arbitrarily many mathematical or physical concepts.

1. Logic, Categories and Types

In this section, we will talk about how the logic side and the programming side of things are equivalent in a sense. Technically we call this an isomorphism. Hilbert style deduction systems are based on intuitionistic logic, axiom schemes and deduction or proof systems. A model of computation called lambda calculus is concerned with similar equivalent structures as well. Similar models based on type theory , combinatory logic and Gentzen's sequent calculus also exist. In the so-called BHK interpretation , intuitionistic proofs are functions and since lambda calculus proofs form a class of function, there is a correspondence between natural deduction and lambda calculus.

Going further than the Curry-Howard correspondence we have so far, there is a generalized Curry-Howard-Lambek correspondence . It shows that proofs of intuitionistic propositional logic and combinators of typed combinatory logic share an equational theory and form cartesian closed categories .

We will learn about constructions that operate on these logical propositions or abstract categories or types. We will deal with pairs such as

We will also examine the following aspects of the correspondences and related concepts:

Hibert-style deduction and Type System for Combinatory Logic
Natural Deduction and Type System for Lambda Calculus
Closed Monoidal Categories
Internal Language
Linear Type System & Linear Logic
Homotopic Equivalence & Equality

2. Propositions and Constraints

Here we will talk about rule based knowledge bases and logical calculus for extracting knowledge from constraints, rules and propositions. Formalisms for these will also be introduced.

3. Operators and n-Tuples

We will mostly obsess with quaternions and n-dimensional tuples which may mutate to equivalent structures in other dimensions.

4. Transformers and Mutators

These mutators are called transformers if they shift the tuple towards structures in the same dimensions as before.

5. Matrices and Hypergraphs

We will agree upon an intuitive encoding for matrices and various kinds of graphs.

6. MAMBA and COSYS

We will examine a memory arrays & meshes based architecture for a collaborative system for computational problem solving.

7. COPLA and NEP.WORK

Based on 6, we will create a model for inter-planetary level computational collaborations and national level collaborations, named in the examples as nep.work.

8. Spoken and Written Lang

We will take a step back and examine the constructors of our abstractions. We will study spoken and written language structures describing the aforementioned concepts and knowledge base.

9. Shared and Heard Lang

We will continue 8 with a shifted focus towards how language is intensionally and extensionally shared and heard. Essentially we take a sharp and brief look at understanding of understanding itself.

X. Internal Lang and Lang

We will continue 9 with a further shifted focus towards internal language systems and the capacity for an externally shared language. We will look unbiasedly at both Chomsky's Universal Grammar and Deutscher's Universal Relativism.

11. Sink and Link

Certain nodes in our directed graphs and networks are sources or sinks or both. The edge's representation as a line or a n-D enclosure is known as a link and it may be directional and/or contextual.

12. Source and Course

After looking at sinks and links, we focus ourselves on sources. The rest of the courses will be about sources and actors prevailing in such a meta-platform for mathematics, politics, economics, physics and engineering.

Anarchitecture

Risav — Wed, 08 Jan 2020 09:52:13 +0000

Development in Post-Agile, Managerless Teams

Software teams often need a personnel as a bridge to the world of businesses and customers. However do they really need these bridging professionals who have likely never developed any non-trivial software to also manage enterprise software teams? Can a team, especially a software team, self-organize?

Managers of Bullshit

Anthropologist David Graeber argues in his book aptly named Bullshit Jobs about the existence and social harm of meaningless jobs. Among the five types of entirely pointless jobs, non-technical professionals managing software teams would fall into the 'box tickers' and 'taskmasters' categories. These managers use paperwork and shallow documentations as a proxy for actually needed actions. They may even create extra work, unnecessary burden, avoidable tight deadlines and management strategies unsuited for a creative and technical team. I have known and worked with brilliant project managers over the years who definitely do not belong to these categories but I have also seen first hand the enormity of harm from these managers of bullshit and their similarly bullshit management techniques.

'Uncle Bob' Martin, one of the authors of the original Agile Manifesto, in his talk cum rant 'The Future of Programming' explains precisely why most software development teams are facing this manager invasion problem. He draws from multiple decades of living what we now learn as history of software development and pin-points that software development professionals have in the modern days come to be workers without a self managing and risk handling discipline. You can see in this writeup how his talk leads to the post-agile sentiment I am bringing forth here:

Businesses created this mess

"...business understands discipline... so business really liked scrum. They like scrum because of the discipline. They like scrum because it was simple and obvious - you could do these little sprints and you could do all these meetings and you could do these plannings and it made sense to the business and the business thought, "Yes, this certification thing is a great idea. We need to certify people."

... because they do not understand our craft and disciplines

"But the business does not understand us - doesn't understand programmers and in particular the business does not understand our disciplines. Business understands scrum disciplines. Business does not understand pair programming, ... test driven development, ... refactoring, ... simple design. These technical disciplines are not within the expertise of business and they shouldn't be. They belong to us; they are a part of our expertise. So business cannot approve or endorse them... or evaluate the risks. The risk frankly is ours to take... so we have to take the risk as part of our normal professional operations, as professionals. And that's what a professional does."

... and because they made agile movement a managerial mess

" ... [but then] there was the invasion of the project managers caused by certification. Certification turned into this siren song and attracted, frankly, all the wrong people. Agile was developed by technical people. It was a creation of the software industry. Programmers sat in that room and created the agile manifesto and agile principles. And then came certification and with certification, hordes and hordes of project managers started to get certified. They would sit for two days in a class and get a piece of paper and feel that that was somehow significant. And they literally took over the agile movement. The agile movement shifted dramatically towards the project management side."

... which paved the way for the post-agile world

"When you think now about the stuff going on in agile, you are thinking about kanban and, you know, lean this and, you know, lean startup that. Where's the technical discipline? Where's [sic] the programmers? Frankly, the programmers have all fled. If you go to an agile conference now, you don't see an awful lot of programmers there and you don't see lots of technical tracks there. Although they try...

Kent Beck said at Snowbird,

"The goal for Agile was to heal the divide between business and programming"

and I believe that the [agile movement] has completely failed... Somebody has to take the lead... Civilization depends on us in ways it doesn't yet understand. In ways we don't yet understand."

Take the lead?

So who should be the somebody that takes the lead? Would it be the technical XPers and craftsmen or would it be the businesses with their newfound love in a bastardized agility? Could it be both?

Martin Fowler explains in his article on FlaccidScrum about how scrum, albeit not a technical framework, can accommodate the craftsmanship best practices and discipline of, say, XP or TDD.

"In defense of Scrum, it's important to point out that just because it doesn't include technical activities within its scope should not lead anyone to conclude that it doesn't think they are important. Whenever I've listened to prominent Scrummers they've always emphasized that you must have good technical practices to succeed with a Scrum project. They don't mandate what those technical practices should be, but you do need them...

I always like to point out that it isn't methodologies that succeed or fail, it's teams that succeed or fail... Many people are looking to Lean as the Next Big Agile Thing. But the more popular lean becomes the more it will run into the same kind of issues as Scrum is facing now. That doesn't make Lean (or Scrum) worthless,

it just reminds us Individuals and Interactions are more valuable than Processes and Tools."

The Manifesto, XP and Failures

The Agile Manifesto reads:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

XP values feedback, simplicity, communication, courage and respect. Agile's original best practices include standups, stories, retrospectives, iterations, estimates, tests, refactors and continuous deployments.

Most teams fail because of lack of XP values and/or the managerial world view that prioritizes shipping faster - under the guise of pragmatism- over shipping with agile discipline - under the disparaging label of ideology. Some failures are softer and, in my experience, are caused by managers who make their developers so disconnected from business problems over time that they are no different from machine or telephone operators from the days of past. Then there are those managers who promote the idea that QA tools and tests are not part of getting the job done but rather a luxury.

However the biggest and most cliched failure source is viewing programmers as a species that

does not know how to talk
does not have 'social skills'
cannot understand clients' complex requirements

Hence businesses create the need to bring forth a magical middleman with their own non-technical management strategies and their greedy algorithm based product shipment strategies. These would also be the managers who will never agree to epics and tasks centered around code refactoring let alone complete overhauls and rewrites. Effectively, these are also the managers that cannot make rational risk management decisions owing to their lack of in-depth technical knowledge.

Developer Driven Development and *DD

Post-agile movement is primarily about removal of these aforementioned categories of managers. We do not need business managers leading software teams certified after a few weeks of training about software development management principles. We instead need an inversion whereby software developers learn management principles suited for their domain. And yes, this applies for even the junior most developers in the team since domain specific management principles are useful to know for everybody in the domain.

Another profound realization that led to Fred George's vision of the post-agile programmer anarchy is the fact that partnerships between the customer and the development team to drive the software development project is inherently flawed and cripplingly slow. Partnership with the customer should be about defining their problems and desirable features of the solutions, nothing more. Otherwise we would be in the business of building the fabled horse carriages of customer's dreams when we could be building them cars or even star ships that the customers do not yet know about.

This radical departure from the classical and agile status quo is possible because development teams understand business metrics, customer oriented development and follow the supremely powerful continuous feedback-continuous deployment cycle.

On a more fundamental level, it is the realization that

if you are going for a drive, you need to put the driver in the driver's seat.

Secondly if the driver is an experienced professional whom you have told where to take you,

the backseat drivers are not needed.

Over the decades we have identified that we need Test, Feature, Behavior, Acceptance Test, Data, Domain, Design, Model or, if you will, * Driven Development. Perhaps one or more of these apply to your team's needs but none of it will go into practice if the developers themselves cannot drive the development practices. As both of the Martins above would say, the teams fail not the tools and this responsibility of applying the correct technical tools is a technical team's responsibility not a business domain concern.

Developer Anarchy, Self-Organization and Anarchitecture

As separation of concerns is a dearly held value and a common meta-design pattern among developers, developers need to use this same principle for the architecture of their software and the development team's communication structures. These two are known to be inseparable and mutually influencing according to Conway's law.

Anarchy: Seeds and Needs

Businesses will always need to be lead by business managers. Software development will always need to be lead by software developers and architects. Businesses need not be concerned with the solutions and therefore should invert the control of solution design back to the developers to maintain orthogonality. Businesses can still partner with software teams in an agile way to properly define the problems and agree upon the desired features for any possible solution that may emerge in the solution space after enough iterations.

This is obviously only going to work if your development team has enough senior developers with industry experience and if there is enough communication among all its members. Working as a professional is very different from actually becoming a professional. But once you are lucky to have a team of professionals and younglings eager enough to become professionals, every developer can rightfully be an architect for their own region of the system they are building. You do not always have to go for a micro-service architecture for this to be possible. Simply let the most experienced developers create a functional core and everyone else develop their own parts of the imperative shell around it as efficient and well-integrated plugins. More trusted developers would get the responsibility of pairing up with the developers of the more important plugins.

Self-Organizing Superorganisms

This so-called 'post-agile' technique is still very much compliant with the original agile manifesto. However there are no managers of programmers whose wrongly placed formality and misplaced rules may constrain technical innovation and creativity. As these developers will like to fail as much as possible in the early iterations, the classical managers will have no reliable metrics of progress anyways. The ideal anarchic development team has team members jumping up to take responsibilities that no outsider manager could even have possibly foreseen. Such a team could democratically divide work based on the particular sub-specializations, interests and expertise of the team member instead of forcing everyone to see through a story or task's completion from top to bottom of the tech-stack owing to the assigned 'user stories'. These developers would work directly with the product owner or the customer and build more trust than what waterfall or impure agile derivatives can provide.

It follows that one big change in the development team's architecture would be the fact that development can no longer be story driven. As mentioned earlier, customers should produce formal, comprehensive problem descriptions and perhaps the desired features of the solutions but never directly participate in solution designs and technical specs. Anarchic teams cannot allow for customer side stories that disconnect developers from the actual problems the customers face. Neither customers nor managers know enough to tell the developers what or how the solution should be. If they did, the programming part would already have been automated or made into a business manager friendly automation DSL or UI. Developers who understand the problem clearly can empathize better with the end users and come up with better specs and deadlines for the solutions. They might also be able to squeeze in enough room for early failures and experimentation. Overall, such teams will behave as self-organizing superorganisms.

Anarchy to Anarchitecture

Lastly, neither Fred George nor the two Martins are advocating radical anarchy or complete departure from the lessons learned from scrum and other agile frameworks, be it managerial or technical. Even the anarchists are supposed to converse and ask each other. Anarchic teams have emergent leaderships and self-organization strategies rather than pre-ordained leadership or lack of well-suited organizational strategies.

How would the architecture of a system produced by an anarchic team look like? Surely the anarchy would leak into the architecture itself. Perhaps there will be an explosion of plugin and microservice architectures. Perhaps not. But I am sure that software architecture itself will be radically affected. What kind of architecture allows for flexible micro-architectures? The best kind. Probably. Could we still call it an architecture? Once again, the solution emerges from the problem definition itself.

We could call it anarchitecture.

Introducing nep.work

Risav — Mon, 06 Jan 2020 13:23:48 +0000

nep.work in a nutshell

We are a community that develops omni-channel platforms for sales and delivery of services through work contract exchanges and pre-purchases.

Think of us as an ecommerce platform for trading service agreements and insurances (eg for event organization and logistics) instead of products and as a hospitality platform operational at every accessible venue instead of a particular location (eg hotel, stadium, hospital, website, app etc).

Omni-channel

A single channel, physical or digital, is not always enough for modern ecommerce and high frequency transactions. Neither is a basic multichannel strategy. For every nep.work trading agreement related interactions between providers and consumers, we strive to bring together all available digital and physical real estate, payment gateways and logistical solutions. As we will have a singular (but distributed) functional core, these various interaction points for the market will always be in synchrony and harmony with each other. That said we will still have service providers with brick and mortar shops and traditional online catalog-sales style webshops and apps.

Platform

Our sole product and exclusive service is the work exchange platform and its customer support program respectively. We have a foundational infrastructure for a contractualist service exchange, with or without money, backed by immutable, reliable and publicly verifiable structures such as blockchain and in-memory merkle trees. The platform also has formal and socio-technical mechanisms to verify proof of work (PoW) for a given fulfilled contract. A verified PoW can be used for adding a new block of data to our blockchain and related persistence systems.

Sales and Delivery

Our services can be sold as contracts, insurances and barter agreements. When money is involved, the transactions can be made using local payment channels or our on-delivery cash service. Payments in kind or barter may be included before, during and after the delivery as per the specific Trading Agreement (TAg). We also have logistics partners and will soon announce a unified access API and SDK for our TAg management, payments and delivery.

Work Exchange

Our work exchange platform goes beyond a freelancer network for posting and grabbing project offers. After a service request or offer is posted, there is either an open or closed negotiation between the provider and consumer parties. Optionally, an auction of the type chosen by the author of the post may be created to bypass negotiations and find optimum pricing options without involving senile Walrasians.
Work exchange also enables us to remain self-organizing and self-preserving. We have learnt from similar communities on web and throughout history and created a public reputation based trust system. Providing such services in itself is a part of our work exchange program. For every project, the project's team may have various developers, artists, sponsors, volunteers, reviewers and even the audience itself due to our democratized innovation and feedback mechanisms. Membership in certain negative interest rate service provider communities can help offset your monthly income in case it dips below your baseline. Similar 'buffer financing' or insurance services also exist for the projects the nepwork community works on. Finally most communities and work groups have a meta group which is responsible for critical reviews and future roadmaps of the group.

DEV Community: Risav

MAP III - Types of Types II

2. Function weds Data: Domain and Co-domain Spaces

2.1 Object and Class

Templates

Meta

Bonus: Classless OOP

2.2 Functions and Methods

Inputs:

Outputs:

2.3 Parameter Types and Return Types

if/else-if/else (v1)

match-case

Next on 'Types of Types'

3. Abstract Data Types: Types with Structure and Behavior

3.1 Sum and Product Types

3.2 Set and List

3.3 Maps

3.4 Stack and Queue

3.5 Graph and Tree

4. Algebraic Data Types and HKTs

5. A Gentle Introduction to Category Theory

MAP III : Types of Types

1. Common Data Types: Syntactic and Semantic bits

Any and Nothing

AnyVal and AnyRef

Unit and Boolean

Option and Null

The Normie Types

I. Byte, Short and Int

II. Long, Float and Double

III. Char and String

IV. The Big and The Rich

Next on 'Types of Types'

2. Function weds Data: Domain and Co-domain Spaces

2.1 Object and Class

2.2 Functions and Methods

2.3 Parameter Types and Return Types

3. Abstract Data Types: Types with Structure and Behavior

3.1 Sum and Product Types

3.2 Set and List

3.3 Maps

3.4 Stack and Queue

3.5 Graph and Tree

4. Algebraic Data Types and HKTs

5. A Gentle Introduction to Category Theory

Play with Spring and Angular: Getting Started

SDKMAN and JVMs

Spring Boot

Scala and Play

Nodejs

Angular

IDEs and Editors

Bon Voyage!

Time - II

The ABCs and 123s of Time

Heraclitus & Parmenides

The Being and The Becoming of Time

The A and B Theory of Time

Time on 1, 2, 3 or more axes

The Higher Dimensions of Time and The C series

Time - I

The Unreality of Time

COVID-19 Simulation for Nepal: A Call for Collaboration

Teams That Formed This Team

Please Join Us

Crowd Densities Analysis

Human Movements

Contact Us:

A Recipe for making a Developer - I

Amusing our Devs to Death

Two Ingredients

Father & Son

The Huxleyan variant

The Orwellian-Huxleyan hybrids

Having a Cake and Eating it Too

Wau Ϝ Wow

Mathematics' Anarchitecture & Processes for Programmers

MAP for Programmers

Mathematics' Architecture & Processes for Programmers

**The Normie Types**