Computers:

In 1975 I started using “structured programming” techniques in assembly language, and became a true believer.

In 1983 a new era dawned for me as I started doing some C programming on Unix and MS-DOS. For the next five years, I would be programming mixed C/assembly systems running on a variety of platforms including microcoded bit-slice graphics processors, PCs, 68K systems, and mainframes. For the five years after that, I programmed almost exclusively in C on Unix, MS-DOS, and Windows.

Another new era began in 1994 when I started doing object-oriented programming in C++ on Windows. I fell in love with OO, but C++ I wasn’t so sure about. Five years later I came across the Eiffel language, and my feelings for C++ quickly spiraled toward “contempt.”

The following year, 2000, I made the switch to Java and I’ve been working in Java ever since.

Coroutines are analogous to subroutines, but they are symmetrical with respect to caller and callee: When coroutine A invokes coroutine B, the action of A is temporarily suspended and the action of B resumes where B had most recently left o

Code:

function TwoDimensionWalk( m, n )
{
  for( i = 0; i <= m; ++i )
      for( j = 0; j <= n; ++i )
      {
        // do any thing here
        yield to Consume
      }
}

function Consume()
{
  // do any thing here
  yield to TwoDimensionWalk
}

Code:

function TwoDimensionWalk( m, n )
{
  for( i = 0; i <= m; ++i )
      for( j = 0; j <= n; ++i )
      {
        NextJ()
        Consume()
      }
}

function NextJ()
{
  // do any thing here
}

function Consume()
{
  // do any thing here
}

>I don’t think a “forgone license fee” counts as a loss under any accounting system.

Yeah, there’s no way the IRS would buy that. MS has been able to get massive write-offs by giving away copies of their products to schools and charities, but I don’t think NOK counts as a charity yet.

Jacob Hallén Says:
February 12th, 2011 at 11:12 am

With Symbian the customer is owned by the operator. For an app to work (without tons of tedious warnings) , it needs to have a certificate signed by the operator. In exceptional circumstances you can get your certificate signed by the phone manufacturer, but most of the time this doesn’t happen, because the phone manufacturer wants to stay buddies with the operator and get him to subsidise the manufacturers phones.
As an app developer you are stuck in certification hell. It is tedious and damned expensive.

Enter the IPhone. The customer is owned by Apple. They will lease the customer to you on fairly decent terms. You no longer need to deal with hundreds of operators or manufacturers that see you as a threat to their business. This is a large part of the success of Apple in the market. It beats the pants off the Symbian model, because users can get the apps they want with any operator they care to use and the developers have one target to develop for. However, Apple charges a high price for the convenience.

Google sees this and is also worried about being kept out of the walled garden with their ads. They put Android on the market, making it free and making the apps self certified. This casts the users free from the control of both operators and handset manufacturers. It makes the devlopers happy, because they are no longer under the control of Apple.

# Some Guy Says:
February 12th, 2011 at 12:27 pm

> Apple charges a high price for the convenience.

I wouldn’t call it a high price at all. 30% is quite typical for what we had to pay to distributors back in the days of software in boxes on retail shelves, and we don’t have to deal with the cost of implementing a payment system, etc.

# Morgan Greywolf Says:
February 12th, 2011 at 2:01 pm

I wouldn’t call it a high price at all. 30% is quite typical for what we had to pay to distributors back in the days of software in boxes on retail shelves, and we don’t have to deal with the cost of implementing a payment system, etc.

But we no longer live in a world of boxed software. These days most of us who do buy software do so online. That means the only middle men that are of any consequence are the credit card processors and the transaction clearinghouses. Why do we need Apple? Oh, I forgot, because they make us.

# tmoney Says:
February 12th, 2011 at 4:05 pm

>Why do we need Apple? Oh, I forgot, because they make us.

And the examples of independent Android developers making their millions without using Android market place are…

@Some Guy:

Certainly, there are examples of people getting rich off Apple’s app store, just like there are people getting rich from football, from singing, etc.

A lot of people make the assumption that paid apps are the way to go, because it’s easier to make good money with them than via advertising. That makes sense if the average developer can, in fact, make good money on the average app through Apple’s store.

I haven’t checked out this guy’s assumptions or math or numbers, but he goes into great detail, and concludes that the median paid app in Apple’s store earns $682 for its developer.

1. Copute more optimized type erasure.
   
2. Pure functions (from Haskell) are the critical feature needed for widescale contribution composability & reuse, as well as concurrency for more CPU cores coming.
   
3. Most programmers can not wrap their mind around Scala (and the better ones need months to grasp it). I was able to grasp Scala in a fews days, but I am apparently far above average and have a lot of knowledge of Haskell, HaXe, etc.. So Copute's syntax will be more familiar (C-like) and it will remove some of the unnecessary generality that makes Scala obtuse, yet retain all the necessary power of expression. So as one market (of several I forsee), I am viewing Copute as a faster way to write Scala code!
   
4. Scala has the ability to throw and catch an exception. I am tentatively trying to eliminate even throwing an exception in Copute, except in a dynamic function.
   
5. Dynamic coding is extremely popular and it will require massive boilerplate in Scala. Dynamic coding in Copute will be the same (thus concise) as the most popular language in world JavaScript.
   
6. Scala can mix implementation in an interface (called "trait" in Scala), which causes semantic errors. I have disallowed this in Copute's inheritance model.
   
7. Scala allows structural subtyping, which I have disallowed in Copute, because it can cause semantic errors.
   
8. Scala allows "override" runtime virtual inheritance, which can cause semantic errors.
   
9. Scala allows abstract and higher-kind types (as well as other things such as hiding closures in Unit type arguments, etc), that make reading Scala code like trying to read treasure map. Copute code is more transparent and straightforward, without losing necessary capabilities.
   
10. The intent is for Copute to target more languages, e.g. JavaScript, PHP, Python, etc.. Copute will be able to do this more easily because it doesn't have those unnecessary, academic super generality types that Scala has. Scala appears to be tied to the Java (and maybe Microsoft .Net) platforms for the time being.
    
11. Copute has an EBNF defined LL(3) context-free grammar (CFG) already completed, so easier for others to write Copute tools. I am not sure if Scala has a BNF CFG specification (I need to research this).
    
12. K.I.S.S.
    
13. If Copute's compiler code will be simpler than Scala's (which it should be, since less unnecessary generality), then I should be able to innovate faster than Scala with more contributors, as they will be able to more readily understand the code.
    
14. there are probably more reasons....
    

#

@Cedric

You missed the point of mixins. They completely solve the diamond problem because only duplicate methods which are from the EXACT SAME trait are resolved automatically. Any duplicates from different traits have to be resolved by the superclass in the single-inheritance chain (i.e. analogous to “Class::” in C++).

You can’t do “Class::” specific method call from a trait (you must use the less specific “super.” instead), this because mixin order can insert an mixin in middle of the inheritance hierarchy of another mixin. For example, given mixin A (B) and mixin C (B), then mixin D (C,A) would effectively cause mixin C (A,B), because the B in mixin C (B) is already in the inheritance tree of mixin A (B), and thus not repeated. A more detailed explanation can be found at top, left of page 7 in the Super subsection of the 2.2 Modular Mixin Composition section of Scalable Component Abstractions, Odersky & Zenger, Proceedings of OOPSLA 2005, San Diego, October 2005.

http://www.scala-lang.org/sites/default/files/odersky/ScalableComponent.pdf

So I want you to realized that “Class::” specific method invocation can never be as flexible as mixins.

I studied this deeply for the design of my Copute language.
Shelby Moore III Sunday, February 13, 2011 at 2:12 am
#

typo: I meant “…have to resolved by the subclass…”
Shelby Moore III Sunday, February 13, 2011 at 2:14 am
#

@Cedric

Don’t conflate some programmer’s insufficient separation-of-concerns in the design of a trait with the Diamond Problem.The Diamond Problem is a specific problem of how to resolve multiple inheritance name spaces (scope).

Also please realize that Scala is a single-inheritance language, with the apparency of multiple inheritance of traits. In reality, traits get folded into that single-inheritance chain in a specific order and are NOT multiply inherited.
Shelby Moore III Sunday, February 13, 2011 at 2:24 am

Gilad is making the correct point that in best design practice composable modules (i.e. APIs) should expose abstract interfaces but not their concrete classes. Thus new becomes impossible, because there is no concrete class to instantiate. Apparently Gosling realized this.

Static factories in abstract interfaces can accomplish this with type parametrization.

Gilad Bracha wrote:The standard recommended solution is to use a static factory [...] You can’t abstract over static methods

Static methods can be abstracted (over inheritance) with type parametrization, e.g.

Code:

interface Factory<+Subclass extends Factory<Subclass>>
{
  newInstance() : Subclass
}

where the + declares that Factory can be referenced (assigned) covariantly due to Liskov Substitution Principle. The + is unnecessary in the above example, but exists in the syntax generally to perform checking against LSP.

Thus any API can abstract over any publicly exposed Factory<T> by associating them privately with instances of Factory<IheritsFromT>. In other words, our interface could have been as follows, where the factory creates a new instance of itself, which can be any subtype because inherited return types may be covariant.

Code:

interface Factory
{
  newInstance() : Factory
}

On the topic of concrete implementation inheritance and constructors, the Scala-like mixins can not handle this, because external parameters for constructors are not allowed in a trait implementation. Thus each mixin is detached from the external inheritance order. I have taken this a step further in my design for Copute, because I force the separation of purely abstract interface and purely concrete mixin implementation, thus every mixin has to inherit from an abstract interface and can only be referenced as a type via that interface, i.e. concrete mixins are not types in any scope other than the mixin declaration.

A singleton is a simply unique object. In most languages, you can use the static state associated with a class to ensure it only has one instance, and make singletons that way. But this only works because the class itself is a singleton, and the system takes care of that for you by having a global namespace.

In Newspeak, there is no global namespace. If you need singletons in your application, they are simply instance variables of your module. When you load your application, you hook up your modules and make a single copy of each.

If, on the other hand, you need a service that's accessible to an open-ended set of users, it has to be available at some public place - this could be a URL on the internet (the real global state) or a platform wide registry. In other words, it's part of the outside world's state.

Such world state may be injected into your application when it starts up (but only in as much as the platform trusts you to access it).

Not sure if this helps. The habit of static state is pervasive in computing and it's hard for people to get rid of it - but we will.

Nokia must focus on its inherent strengths, which is as a refinement innovator, not a paradigm innovator a la Steve Jobs. Microsoft will slow them down, because Microsoft is strong in neither, and Windows Phone is too far behind in a race of exponential rate of innovation. Due to the exponential function, it is too late for anyone to go back and start a new smartphone OS from scratch or even take time to complete an unfinished one, unless it will offer massive compelling advantages, which is probably unrealistic. The realistic forward innovations are precisely in Nokia's area of strength. By the end of 2011, the smartphone marketshare of Nokia will have eroded to teens and Android will be triple that.

Nokia should innovate on Android so they can ship a #1 selling smartphone in 2011, and incrementally differentiate itself from the herd. It is potentially possible to co-opt Google with strategic innovations that diverge from the herd's common base. The Android platform is inherently fractured, as this is the desirable nature of open source. The opportunity is wide-open for Nokia to provide an unfractured Android platform. Popular innovations will eventually make their way back into the common base, but always on a lag-- look to Apple as a model or profitability as first-innovator.

There is no credible AppStore or iTunes on Android on the horizon. The opportunity to take the best of Android, win the race to market, and innovate are wide open. Do not fight against the exponential function. Embrace the strengths of open source, and your own strengths with respect to it-- this advice applies to everyone. Dinosaur's stand in the way of open source. Re-inventing Android as MeeGo at this stage is an enormous waste of capital, and the free market does not reward those who do not focus capital on their relative strengths. MeeGo is yet another coffin in the European culture cementary of "politics 90% of the time, to get 10% production". The institutional investors are correct that "American" (libertarian) culture of "Just Do It" wins, but the Elop and Microsoft selection are not even shadows of that.

While it is never a good idea to optimize ad text exclusively to CTR, if you can maintain or improve your conversion rate (CR) while also increasing CTR, you need to do so.

Of course, hackers have to know about a language before they can use it. How are they to hear? From other hackers. But there has to be some initial group of hackers using the language for others even to hear about it. I wonder how large this group has to be; how many users make a critical mass? Off the top of my head, I'd say twenty. If a language had twenty separate users, meaning twenty users who decided on their own to use it, I'd consider it to be real.

Getting there can't be easy. I would not be surprised if it is harder to get from zero to twenty than from twenty to a thousand. The best way to get those initial twenty users is probably to use a trojan horse: to give people an application they want, which happens to be written in the new language.

Excuse if I'm not omniscient about such matters, so is the case that *nix conquered the server in 2008 on deadline, and Android is the killer client app? The OS became an app in a new abstraction named "cloud computing" and the network became the OS?

Excuse if I’m not omniscient about such matters, so is the case that *nix conquered the server in 2008 on deadline, and Android is the killer client app? The OS became an app in a new abstraction named “cloud computing” and the network became the OS?

No. *nix conquered the server long, long ago.

Granted *nix server had majority market share long ago.

ESR cited that 83/23 (78/22%) for new workloads occurred circa 2007, so perhaps the conquering was 90/10% rule (roughly Pareto squared) complete by 2008, thus meeting ESR's deadline.

Is Android the killer app because it paradigm-shifted open source hackers to optimize for hardware without a keyboard-- flatmapping the world closer to the programmers are the users and vice versa? Open source for the masses. On deadline for the roughly 10 year cycle for the imminent arrival of a new programming language for these masses:

1975 he started using “structured programming” techniques in assembly language
1983 a new era dawned for him as he started doing some C programming
1994 when he started doing object-oriented programming in C++
2000, he made the switch to Java

Can Java be the language on Android, invalidating the 10 year cycle deadline? Will the next language be the virtual machine with a smorgasbord of grammars?

Tying this to the OODA and martial arts discussion, note that solving a problem by "mapping to a new context" or "passing through an envelope" abstraction, is a monad model and hence the mention of flatmap. Could the next programming language achieve monads-for-dummies?

Perhaps I am missing something, but off top of my head, I am thinking the following is semantically incorrect, because it makes all None equivalent. (Also doesn’t this force Nothing to a supertype of every possible A, so that bind can always be called with the same function whether it is Some or a None?)

Code:

case object None extends Option[Nothing] {
  def bind[B](f: Nothing => Option[B]) = None
}

Is that the way it is implemented in Scala standard library? Seems to me that None should be parametrized too, so that a None for one type (e.g. String) isn’t equal to a None for another which is not covariant (e.g. Int).

Code:

case class None[+A] extends Option[A] {
  def bind[B](f: A => Option[B]) = None[B]
}

Caveat: none of the following code is tested and I am new to Scala and have never installed the Scala (nor the Java) compiler.

Daniel's "typeclass" is a fully generalized convention for declaring static methods of an interface. Imagine you could declare static methods in a trait with this pseudo-code.

Code:

trait Monad[+X] {
  static def unit[Y] : Y => Monad[Y]
  def bind[M <: Monad[_]] : (X => M) => M
}

sealed trait Option[+X] extends Monad[X] {
  static def unit[Y]( y : Y ) : Monad[Y] = Some( y )
}

To get legal Scala, this is translated as follows, noting the +, -, or no variance annotation on M depend on where Monad appears in the static methods of Monad.

Code:

trait Monad[+X] {
  def bind[M <: Monad[_]] : (X => M) => M
}

trait StaticMonad[+M[_]] {
  def unit[Y] : Y => Monad[Y]
}

sealed trait Option[+X] extends Monad[X] {}

implicit object OptionStaticMonad extends StaticMonad[Option] {
  def unit[Y]( y : Y ) : Monad[Y] = Some( y )
}

Before we can add the cases for Option, note that Monad requires "unit" to be invertible, i.e. bijective, but None has no inverse, so we need an injective monad.

Code:

trait InjMonad[Sub[_] <: InjMonad[Sub[_],X], +X] {
  def bind[Y] : (X => Sub[Y]) => Sub[Y]
}

sealed trait Option[+X] extends InjMonad[Option,X] {}

case class Some[+X](value: X) extends Option[X] {
  def bind[Y]( f : X => Option[Y] ) : Option[Y] = f( value )
}

case class None[+X] extends Option[X] {
  def bind[Y]( f : X => Option[Y] ) : Option[Y] = None[Y]
}

Thus Daniel's sequence.

Code:

def sequence[M[_], X]( ms : List[M[X]], implicit tc : StaticMonad[M] ) = {
  ms.foldRight( tc.unit( List[X] ) ) { (m, acc) =>
      m.bind(_) { x =>
        acc.bind(_) { tail => tc.unit( x :: tail ) }
      }
  }
}

Note that syntax is peculiar to Scala, here is a more widely readable version:

Code:

def sequence[M[_], X]( ms : List[M[X]], implicit tc : StaticMonad[M] ) = {
  ms.foldRight( tc.unit( List[X] ), (m, acc) =>
      m.bind(  x =>
        acc.bind( tail => tc.unit( x :: tail ) )
      )
  )
}

Note my version of Daniels sequence will work with both bijective Monad and injective InjMonad, because the call to bind is a method of the instance; whereas, Daniel's version assumed the injective monad and I see no possible way to fix it using his convention of implicit duck typing of non-static methods. His is an example of how duck typing breaks composability.

==================
**** Monad Theory ****
==================

The best layman's explanation I have found so far is "Comprehending Monads" by Philip Wadler, 1992. Google for the PDF.

Conceptually a monad has three functions:

Code:

unit : X -> M[X]
map : (X -> Y) -> M[X] -> M[Y]
join: M[M[X]] -> M[X]

The map function might be curried two ways:

Code:

map : (X -> Y) -> (M[X] -> M[Y])
map : M[X] -> ((X -> Y) -> M[Y]) // Will use this for trait below

We must overload the map function, if M is not same type as N, because otherwise map will not know which "unit" to call (in order to lift Y => M[Y]), because overloading on return type is ambiguous due to covariance:

Code:

map : (Y -> M[Y]) -> (X -> Y) -> N[X] -> M[Y]
bind : (X -> M[Y]) -> N[X] -> M[Y]
map a b = bind x -> a b x

The reason I rephrased the abstracted monad as a inherited trait with static methods, is so far in my research, I don't agree with a general "implicit" keyword for a language design, because the general use of duck typing can violate the localized single-point-of-truth (SPOT) and can make semantic assumptions that were not intended, because duck typing forces all traits and classes to share the same member namespace, and thus essentially bypasses the behavioral conditions of the Liskov Substitution Principle contract of OOP. Also, since duck typing does not explicitly state which interfaces are required at the SPOT of the trait or class declaration, there is no way to know which interfaces are available by looking in one place. Localization (separation) of concerns is a critical attribute of reusable/scalable software design. Again the following is pseudo-code for the translation of static methods to implicit, but now fully generalized to monad theory.

Code:

trait Monad[+X] {
  static def unit[Y] : Y => Monad[Y]
  def bind[M <: Monad[_]] : (X => M) => M
  def map[M <: Monad[Y], Y]( a : Y => M, b :  X => Y ) : M = bind x => a b x // bind( x => a( b( x ) ) )
  static def join[M <: Monad[_], Y] : M[M[Y]] => M[Y]
}

But the above trait won't work for monads whose "unit" is not bijective, i.e. where the inverse of "unit" is lossy, e.g. None option has no inverse. The injective monads thus know which "unit" to call, thus we could add a map to our prior injective monad, which does not input a "unit".

Code:

trait InjMonad[Sub[_] <: InjMonad[Sub[_],X], +X] {
  def bind[Y] : (X => Sub[Y]) => Sub[Y]
  def map[Y] : (X => Y) => Sub[Y]
}

sealed trait Option[+X] extends InjMonad[Option,X] {}

case class Some[+X](value: X) extends Option[X] {
  def bind[Y]( f : X => Option[Y] ) : Option[Y] = f( value )
  def map[Y]( f : X => Y ) : Option[Y] = ObjectStaticMethod.unit( f( value ) ) // Some( f( value ) )
}

case class None[+X] extends Option[X] {
  def bind[Y]( f : X => Option[Y] ) : Option[Y] = None[Y]
  def map[Y]( f : X => Y ) : Option[Y] = None[Y]
}

I will offer two improvements to my prior comment-- the prior comment wherein I had proposed a conceptual mapping of pseudo-code "static" interface members to legal Scala syntax.

Note that the StaticMonad trait (in my prior comment) is necessary to enable accessing "statics" on types (e.g. M[_]) that are otherwise unknown due to type erasure (e.g. Daniel's Sequence function example), but StaticMonad is not used for direct invocation of statics, e.g. Option.unit( value ). Thus a necessary improvement is to name object OptionStaticMonad to object Option, which makes trait Option its companion class (or does Scala only allow this if Option is a class?):

Code:

implicit object Option extends StaticMonad[Option] {
  def unit[Y]( y ) = Some( y )
}

Also, to give functionality similar to what we expect for "static" in Java, (some macro or other language to Scala compiler) could automatically generate the statics for each derived class in pseudo-code that did not override them, e.g. as follows although this example seems superfluous, it is not harmful and the generality is needed in other examples.

Code:

implicit object Some extends StaticMonad[Some] {
  def unit[Y]( y ) = Object.unit( y )
}

implicit object None extends StaticMonad[None] {
  def unit[Y]( y ) = Object.unit( y )
}

Expounding on my prior comment, the situations where StaticMonad[M] is employed (versus directly accessing the singleton), type M is unknown, and thus is a more composable abstraction which inverts the control of the access to the singleton statics, and gives that control to the caller:

http://en.wikipedia.org/wiki/Hollywood_Principle
http://lists.motion-twin.com/pipermail/haxe/2011-February/041527.html

Type erasure is an orthogonal issue, that forces the use of an implicit as function parameter, versus the compilation of a separate function body for each possible M in reified languages. Even if Scala was reified, trait StaticMonad is still necessary to abstract the inversion-of-control on singletons. Thus the declaration of implicit instances and parameter is justified by type erasure, but they (along with StaticMonad) could just as well be hidden to make a non-reified language appear to be reified. Which is what I was illustrating with pseudo-code examples.

Code:

pure sequence<M<X> : Monad<X>, X>( ms : List<M<X>> ) = {
  ms.foldRight( M.unit( List<X> ), \m, acc ->
      m.bind(  \x ->
        acc.bind( \tail -> M.unit( tail.append(x) ); );
      );
  )
}

A variance annotation on Sub was missing in my prior comment, and should be as follows:

Code:

trait InjMonad[+Sub[_] <: InjMonad[Sub[_],X], +X] {
  def bind[Y, S[Y] >: Sub[Y]] : (X => S[Y]) => S[Y]
}

Without that change, then Some and None would not be subtypes of Option, because Sub was invariant.

Also I am thinking the following is more correct, but I haven't compiled any of my code on this page:

Code:

trait InjMonad[+Sub[X] <: InjMonad[Sub,X], +X] {
  def bind[Y, S[Y] >: Sub[Y]] : (X => S[Y]) => S[Y]
}

I am not sure if that is legal in Scala, but seems to me that is the only way to express that Sub's type parameter is X.

My prior idea for expressing X to be the Sub's type parameter is not retracted.

However, my suggestion for a covariant annotation on Sub, is erroneous for the reason I had stated in prior comments-- Sub's lifted state may not be invertible (e.g. None has no value of type X) and thus there may be no mapping from a Sub to its supertype. Thus the correction to restore an invariant Sub, and keep the other idea, is:

Code:

trait InjMonad[Sub[X] <: InjMonad[Sub,X], +X]{
  def bind[Y] : (X => Sub[Y]) => Sub[Y]
}

It was incorrect when I wrote that this invariant Sub prevents Some and None subtype of Option. Some#bind and None#bind type signatures contain Option, not Some and None respectively.

I can not think of a useful subtype that would overload bind, but in which case, in my paradigm the subtype could multiply inherit from Monad with distinct Sub. In Daniel's typeclass paradigm this would entail adding another singleton implicit object that inherits from Monad.