Computers:

...the generative essence, which is that granularity of types is what determines the tension.

Afaics, the importance of typing is to enforce semantic bounds at compile-time (i.e. locality of concerns), to avoid proliferating run-time "exceptions" (misbehavior of any degree)...

...while getting rid of virtual inheritance on non-abstract classes avoids the Liskov Substitution Principle problem...

1. In order to strengthen the semantic design contract, it has been proposed to apply preconditions and postconditions on the variants of the interface. But conceptually such conditions are really just types, and can be so in practice. Thus, granularity of typing is what determines the boundary of semantic undecidability and thus given referential transparency then also the boundary of tension for reusability/composablity. Without referential transparency, granularity increases the complexity of the state machine and this causes the semantic undecidability to leak out (alias) into the reuse (sampling of inheritance) state machine (analogous to STM, thread synchronization, or other referentially opaque paradigms leaking incoherence in concurrency). Coase's theorem (i.e. there is no external reference point, any such barrier will fail) predicts the referencial dependency failure, which is really just the Shannon-Nyquist sampling theorem (i.e. aliasing occurs unless one samples for infinite time and infinite granularity in space-time, Nyquist limit can't be known due to Coase's theorem) and the 1856 law of thermodynamics (i.e. entire universe, a closed system thus everything, trends to maximum disorder, where disorder means maximum possibilities or granularity).
   
   
2. Thus I disagree with current (afaik) state-of-the-art in literature that claims LSP allows that interface arguments inheritance are contravariant and return values are covariant. Afaics, they must be invariant in order to inherit the same semantics on the interface, unless the variance is between 100% abstract (no mixed semantic implementation) types. What someone was probably thinking is that those rules for variance on the interface inheritance enables the subtype to fulfill LSP, where the property that holds true for the superset (supertype) is that each member (subtype) obeys the order of the declared inheritance hierarchy, but that is a very weak property (semantics of order of hierarchy doesn't do anything to enforce semantic behavior of interface, e.g. inheritance order does not prevent a subtype CIntersection from silently ignoring duplicate adds to a supertype CUnion, whereas a boolean return value for success does). Note, differentiate between interface inheritance and invocation. The invocation of an interface allows the inverse of such variance, but that is an unrelated issue (if the interface inheritance is invariant and thus LSP correct).
   
   
3. For each supertype method that does not have a semantic implementation, by definition it is impossible for it to semantically deviate from its implemented subset (surjectively, but the subset members can deviate from each other), thus can be invoked as a virtual method with semantic type-safety (without violating LSP) when it is called on a compile-time (aka statically typed) reference to that supertype (even though the reference points at run-time to a subtype with an implementation of that method, because an abstract type can not be instantiated). By definition, any type that has an incomplete implementation of its interface(s), is an abstract type. Note for a method that has an implementation, then it is not semantically type-safe (violates LSP per my prior paragraphs) if called virtually on a compile-time reference to the type (even abstract) that contains that implementation. Thus perhaps one can make a good rational for not mixing implementation in an abstract class, so if abstract class names are transparent to the programmer it is always clear when semantics is undefined at compile-time and virtual at run-time, and thus to force separation (granularity). One of my critical general design rules (to everything, including social science) is that implicit should never be opaque, meaning implicit constructs should never create hidden ambiguity.
   

My data structure for Steele's word splitting example is, where enum is an algebraic type (which is just a syntactical sugar for class inheritance), e.g.

Code:

enum Segment
{
  char( s : String )
  undelimited( left : Segment, right : Segment, words : Array<String> )
  delimitedLeft( left : Segment, right : Segment, words : Array<String> )
  delimitedRight( left : Segment, right : Segment, words : Array<String> )
  delimitedBoth( left : Segment, right : Segment, words : Array<String> )
  function combinator( left : Segment, right : Segment ) : Segment
  {
      // Insert logic here to return a new Segment that combines left and right
      // words will contain incomplete words on one or both ends of the ends of the array unless Segment.delimitedBoth
  }
}

The input is Array<Segment>, probably Array<Segment.char> and the covariant substitution is legal because Segment.combinator is referentially transparent. Then map reduce this over Segment.combinator. If Segment.combinator is associative, call an associative version of map reduce. Ditto if Segment.combinator is commutative.

I am also thinking that for example, images should be defined by a recursive hierarchical algebraic type that has resonant locality in the 2D space (e.g. to JPEG 8x8 DCT blocks), instead of non-resonant locality in the 1D space of an Array<Color>, e.g.

Code:

enum Image
{
  pixel( c : Color )
  block( topLeft : Image, topRight : Image, btmLeft : Image, btmRight : Image )
  function combinator( topLeft : Image, topRight : Image, btmLeft : Image, btmRight : Image ) : Block
  {
      return new Image.block( topLeft, topRight, btmLeft, btmRight )
  }
}

Note the Image.combinator is associative, but in a 2D sense, thus we need a 2D version of map reduce. Map reduce is the constructor for the instance of a recursive hierarchical algebraic type.

Note Image could be parametrized on type of a Image.pixel instead of married to Color.

Compiled vs. library?

Afaics, the key premise this research hinges on, is that some important higher-level domain specific portions of optimizations must be done at compile time.

However, if it turns out that the optimizations are really just lower-level general optimizations such as optimizing matrix math, combined with remapping data structures from accumulator and/or random access, to recursive, hierarchical, with associative functional map reduce constructions (see my post at bottom of that link, no direct link yet, as post is awaiting moderator approval), then it may turn out that domain specific optimizations are just run-time libraries that enforce certain data structures.

My intuition leans towards Tim's outcome being most likely, because of economy-of-scale, and tackling the lowest hanging fruit first. Nature prefers the multifurcating tree of possibilities, because it is the most economic (fluid dynamics through pipes). Examples include the internet physical network, and the human brain.

Can anyone provide examples of domain specific optimizations that must be done at compile-time and couldn't be restructured in libraries of the paradigm of concurrent data structures that I linked about above?

P.S. afaik parser combinators (non-predictive recursive descent) don't prove lack of ambiguity in grammar, because the global search of Firstk and Followk sets has not been enumerated.

• Type is declared by a class statement, enum statement, inseparably in a function (instance construction) expression, or the identifier associated with the aforementioned declarations (when not anonymous).
  
• Instance construction is declared by a class or enum constructor call expression, a function expression, or literal class expression-- all of which return an instance reference.
  
• Expression constructs an instance or operates on instance reference(s), and returns an instance reference or void.
  
• Functional programming is a function call expression, that may optionally nest (a hierarchy of) function call expression. A referentially transparent (aka pure) function is re-entrant, stateless, partial evaluation agnostic, and thus composable (aka reusable).
  
• Imperative (aka stateful, or state-machine) programming is an ordered sequence of expres​sion(s). Each imperative sequence (in a nested hierarchy of them) is an identifier namespace (aka scope)-- a means to granularize the referential opacity. A statement is a grammatical unit which forms an expression that returns a type of void.
  

Code:

raise First + raise Second handle First => 1 | Second => 2,

what is the value of this expression? It clearly depends on the order
of evaluation.

"If you really wanted to turn off the global internet, you'd have to seek out people on every continent and every country," said Cowie from Renesys. "The internet is so decentralized that there is no kill switch."

"No you can't do that," said Harvard's Faris. "The internet is designed to be robust. Certain links break and then other links are opened."

In Egypt, for example, people who couldn't access the broadband internet were able to place international phone calls to Europe to log on to dial-up internet service, he said, which, of course, operates on phone lines.

Google even announced a service that would let people in Egypt use landline telephones to post to Twitter using voice messages.

"Communication continues and people revert to other modes,"

Shelby wrote:The currency has to be created. If it does not represent an exchange between tangible money, then it means who ever created it, is like a central bank, stealing that value and causing inflation as it spends it into the the ecosystem.

So in essence what Facebook has done is admit that their business model is an economic failure:

http://www.jperla.com/blog/post/facebook-is-a-ponzi-scheme

Now they will take down all the game developers with them, because their system could not sustain economic viability with a free market of game developers charging how they wished.

One thing is a virtual currency is a way for people in the developing world to earn income on Facebook and avoid the issues of money transfer and transactional costs. But the problem is that if Facebook doesn't back this currency with gold or silver, this it will just be stealing value via inflation and ripping off the entire ecosystem, eventually bringing the whole thing down.

The genesis of Facebook's demise will be decentralized social network. It is coming. The Napster or Gnutella version of Facebook is coming. I should know. Hint.

I can't until a year or 1.5 years from now and we do the search on indeed.com for both sets of jobs advertised

I think you'd be hard pressed to expose an average C# programmer to all of it in one place if not for SO. It'd take years of playing with it to come up with the same hard won list. – Allain Lalonde Sep 14 '08 at 18:54
7

I've been writing JavaScript professionally for 10 years now and I learned a thing or three from this thread. Thanks, Alan! – Andrew Hedges Sep 20 '08 at 7:39

@Vincent Robert: please note that arguments.callee is being deprecated. – ken Dec 29 '10 at 21:50

The complexity of functional programming is perhaps a bit easier to explain. It’s certainly possible to write nearly conventional code in Scala. Here, for example, is Scala code for a conventional way to sum the elements of a list of integers:

Code:

    def sum(l: List[int]): int = {
        var result: int = 0
        for (item <- l)
            result += item
        return result
    }

But that’s not “the Scala way”. A good Scala programmer is expected to use this instead:

Code:

    def sum(l: List[int]): int = (0/:l){_+_}

Isn’t that lovely? This code (that appears to be line noise) is probably the most classic example of a catamorphism (a data transform that results in less data out than in). Basically it says, initialize the result to 0, then go from beginning to end through l, and for each item compute the new result to be result+item. Oh wait, isn’t that exactly what our earlier code did? Well, um, yes, but… this way doesn’t use any of that evil nasty mutable state. This code might be darned near illegible to normal people, but it is the pinnacle of purity and virtue in the FP world.
Oh… if you’re one of those people who worries about efficiency, you do not want to know what that tiny little bit of code expands to.

Let me say that I like immutable data and immutable data structures. I wrote an article here about immutable data in Java. One of the things that attracted me to Scala was its full support for immutable data and immutable data structures. But dagnabbit, mutable variables within a method (or function) aren’t a crime and won’t hurt anything when they’re allocated on the stack as is done by the JVM. This mutable vs. immutable fight has been going on since Turing and Church. Pretty much 100% of all actual, working, useful programs have been written with mutable state. So FP programmers, just get over your aversion to it, okay?

Code:

(0/:l){_+_} !!!!

I’m not one to disparage a languages syntax for being too heavy on the symbols, but do you guy realize that looks like a smily version of goatse guy wearing a hat?

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.