Lambda the Ultimate

Ponies? I think he wanted unicorns...

* multi-core, multi-note runtime environment (can relocate a computation from one box to the next and back again)

IDEs are being developed.

I believe he talks about distributed computing not IDEs.

Good debugger which supports back-stepping

Er, that is still a dream.

go go gadget ocaml.

I assume he meant for Dodo...

I think this question would have been more clearly expressed in French.

Have the code in software for simpler and cheaper hardware, move the code into hardware for speed.

As far as I know that's still the direction in hardware, especially on cell phones where the major advances have been. The pushing codecs into hardware to get video processing to work at low electrical consumption has been a major advance of the last 5 years and it has exactly followed this model.

Not sure why people are so enamoured with optional/soft/gradual typing, when it seems like such a burden when reasoning about code. That is the goal after all, and it seem much better achieved by static typing with support for dynamics where needed (and preferably dynamics that are safe, ie. safe casts/typecase); thus, you always know just by looking at the types whether you're in a dynamic or static context, with static being the default. Admittedly, most statically typed languages do not have good support for dynamics, but that isn't a fundamental limitation.

Not sure why people are so enamoured with optional/soft/gradual typing, when it seems like such a burden when reasoning about code. [...] thus, you always know just by looking at the types whether you're in a dynamic or static context.

People want the rapid application development properties commonly associated with dynamic typing, and the optimization and meaningful static analyses often associated with static typing. They often see 'soft typing' as the means to achieve both.

It should be easy to see why people are enamored with the idea, especially if you aren't generously assuming they'll follow that idea to its logical ends. To most people, a 'hybrid' is the 'best of both worlds' with nary a thought that it might also be the 'worst of both worlds'.

The hybrid procedure/function in Scheme and ML certainly are flexible, for example, but the potential side-effects in functions can greatly hinder optimizations - including partial-evaluations, eliminations, and reordering... especially where one function takes another as an argument. Further, worse than merely hindering optimizations, they make it very difficult to reason about in which contexts an expression could be reused or distributed (i.e. can this 'function' be used in multi-threaded code? which dynamic vars does it need?).

Rather than a hybrid, something like a weave or layering is often only slightly less flexible yet far more practical in terms of other engineering properties (reuse and deep composition, optimization, concurrency, disruption tolerance, security, distribution, etc.) because you - and your compiler - can do more reasoning about it.

What you propose, Sandro, is something closer to a weave or layering between static and dynamic 'contexts'... though far too short on details to evaluate.

Opposing both of you, I believe that the sharing of manifest types between developers is required primarily by a deeply flawed development and code-distribution architecture that involves treating 'libraries' and 'applications' as deliverables. The most obvious problems I see with the common design are (a) the heavy reliance on ambient authority and trust (by both developer and client!), (b) the weak control by the developer over (truly) global instantiation patterns (and therefore persistence, sharing, run-time upgrade), (c) difficulty integrating with foreign resources.

I believe the future to involve 'tierless programming' where a developer may compile up a procedure in an IDE, feed it a few capabilities identifying remote resources and service registries, execute, and within milliseconds have new objects actively integrating with resources (web-cameras, unmanned systems, etc.) across the world. Ideally, the location or IDE at which the object-graph is instantiated has no lasting effect on where the processing is performed. The capabilities linked by the IDE/user would be far more critical. Those capabilities may optionally come from the IDE itself, to support debugging or IDE-as-a-browser.

In such an architecture, the developer could control instantiation-patterns with an iron fist. If one wants an instance-per-user, then one provides an instance-factory. If one wants a shared instance for all users, one provides a common resource. If one wants different instances for different domains, that can be done too. Singleton pattern would be unnecessary, and 'global' resources would be just as truly global as you need them to be. Because instancing is controlled at a global scale and from common initial capabilities, live upgrades can also be achieved without much difficulty, though it may take some careful design to ensure the upgrade 'capability' is unlikely to trouble active systems.

For 'client-side' security, foreign code hosted on a client's machine should obtain no more authority than would the same foreign code running on a foreign machine under ideal network conditions. If achieved, it means that the distribution of code is for performance, disruption-tolerance, and resilience. This is achievable using capability security. To be clear: ideally, all application and library code is considered foreign and untrustworthy.

For 'developer-side' security, the developer of a service should be able to limit the distribution of sensitive things - usually information and authority (capabilities) - such that untrusted hosts cannot gain access to them except via betrayal by a trusted host. For capabilities, one also wishes the ability to revoke trust from a compromised machine and thereby revoke direct access to those capabilities and thereby limit further compromise. To this end, one needs the ability to specify restrictions on what gets distributed, and where. This is feasible utilizing some of the designs aimed initially at DRM, excepting preventing distribution to an untrusted host is a lot more practical than preventing further distribution from an untrusted host. Trust may be expressed via a combination of certificates and escalation policies. Limiting distribution of capabilities is far more readily defined (and enforced) than is limiting distribution of information... but E language style sealers/unsealers can help for the 'information' angle via making the capability a requirement to access certain information from certain sources.

Favoring such an architecture still benefits from safety-analysis within a 'build', but benefits much less when comes time to integrate with the outside world. There is a limit to how much you can trust any 'manifest type' document. Even if you could trust it initially, it may become dated during the run, or be breached maliciously. So you don't trust such an API document - not for anything really important, like security.

Fortunately, once security is separate from safety, you don't really need to care whether the foreign code you host is "safe" except to maximize performance (i.e. by avoiding the extra conditions for fail-safety). Types in the foreign code aren't going to much help this purpose, either - at least not in any trustworthy way that avoids need for fail-safety conditions.

To be clear: ideally, all application and library code is considered foreign and untrustworthy.

IMHO: Exactly what leads to thinking of software architectures in the most general sense as first and foremost all based on a dynamically federated, dynamically distributed system model, which can then be collapsed into fewer 'tiers' as trust boundaries become known.

If you look at it from the perspective of a programmer who puts a lot of value in the guarantees provided by a language with strong static typing, but would like the ability to occasionally "break the rules" in instances in which the type system can't cleanly handle what they're trying to do, what you say makes a lot of sense.

However, a programmer who generally likes dynamically typed programming languages might see things a little differently. They may be more interested in allowing the compiler to make more aggressive optimizations in key areas and have the compiler catch a few stupid mistakes here and there, but they probably don't have much interest in having most of their program statically typed (perhaps they should, but that's a separate issue).

Another category of programmer who might prefer optional/soft/gradual typing is one who finds a dynamically typed language more productive for prototyping/exploratory programming, but wants the safety of static typing for the final product. At the start of the project, they may not be interested in adding any type annotations at all, but as their understanding of the problem becomes more clear they'll want to start adding annotations to the code.

At the start of the project, they may not be interested in adding any type annotations at all, but as their understanding of the problem becomes more clear they'll want to start adding annotations to the code.

Experience has taught me that working out the types upfront clarifies my understanding far more quickly than cobbling together bits of inconsistent code. This benefit is contingent on a low management overhead for type information, as with type inferred languages. Not the first time this has been said of course, so take that personal anecdote for what its worth.

The most likely reason for this request is so that fewer concepts are necessary to distinguish functional code from imperative code (i.e. so the former looks more like the latter). Essentially, the author of the OP is aiming for 'purity' to really mean 'all side-effects are confined'.

One can, of course, write for/while loops inside a functional program (so long as it's turing complete) using something like monadic programming. This sort of program description might be useful for complex functional searches (i.e. for planning and AI).

Personally, I'd favor achieving termination properties for the functional subset, and carefully add both impurity and non-termination in higher layers.

Personally, I'd favor achieving termination properties for the functional subset, and carefully add both impurity and non-termination in higher layers.

Exactly how is it possible?

I mean, that if you have terminating functional base feature set, you cannot add non-termination in higher layers. At least, by simple combination of features.

I can cite PiSigma as an example of contradictory optinion. They added non-termination right into core language.

Consider a terminating core language, and a Delay monad for expressing non-terminating programs.

But we cannot translate core+Delay into pure core language. Or can we?

So I see that pair as a whole basis, instead of basis extension.

you cannot add non-termination in higher layers. At least, by simple combination of features

You cannot use features from a terminating, pure, functional language subset to add non-termination or communication effects.

But that doesn't mean you cannot add non-termination or communication effects in higher layers, i.e. via introducing a primitive that cannot be used inside the 'functional language subset' (i.e. any sub-program using a certain primitive will be in the 'higher layer').

The trick is to guarantee that code in the lower layer cannot invoke code in the higher layer. As Sandro suggests, introduction of a special 'delay' monad is one way to achieve this.

You are probably right in the motivation. But IMHO this makes things worse. The hidden concept of time is sneaking in with the open concept. The real complexity in switching from for/while to map/fold/take is to stop thinking of algorithms in terms of do A then do B then do C.... There is no way to be pure and still think in terms of ordering operations. At least that's my $.02. So assuming you are correct about the motivation it sounds like a bad idea.

The reason I guessed at that particular motivation is that, when I was first getting into language design, I had some similar thoughts on the subject of 'purity'.

At this time, I agree with you: "There is no way to be pure and still think in terms of ordering operations." Ideally, for a 'pure' language, the lazy, lenient, strict, etc. evaluation orderings (among others) always result in the same outcome (modulo performance). And that can be achieved by ensuring that the pure language subset is also strongly normalizing (in addition to confining communications effects), and that the concept of 'time' or 'delay' is introduced to the language more explicitly.

My motivation is so that you can write a side effect-free function using Java-like syntax. I am not going to force programmers to learn new ways if they don't want to. I just want to make it easy to go the functional route if they desire to.

Example:

# Side effect-free iterative style function
int sum_iter(int[] values)
{
   int s = 0
   loop foreach (value in values)
   {
      .s += value
   }
   return s
}

# Functional version
def sum_func(int[] values) = `fold values` + `seed 0`

The base language is continuation-based, so there is a notion of do A then do B then do C... in dodo anyways.

That is correct! The software I write needs to be fast.
Really fast. We mesure our latency in microseconds and often improve speed by avoiding allocating on the heap and creating copies of objects.
The other challenge is that it is also very complicated software to reason about. There are large bodies of business code with many edge case scenarios.

Why do I need to throw away the guarantees of strong static typing and functional pureness when I am writing a critical segment of code?

If I am serialising an object so that it can go out on the network,
it is much faster to express it using mutability: (e.g. adding data to a pre-allocated byte-vector on the stack).

The end result, though is that I can still write a pure function:

serialize(trade: Trade) : Vector[Byte8]

For all intents and purposes the function is pure:
-> It causes no side-effects
-> The output is purely dependent on its input
-> run it twice with the same input and you'll get the same result back

Additionally, if this was some complex risk calculation, I could then use these guaranteed properties to cache or parallelize the computation if my static & dynamic analisys showed me it made sense.

The function uses mutability internally??? so what?? why do I have to throw away a for and while loop when it's good for the job?

** For the people who may think: you should really be writing this stuff on an FPGA: yeah, we tried, but there's no way you can deliver results within a reasonable timescale. We also ran into problems where it wasn't any quicker because of the overhead of getting the data in and out of there. If the software were simple you could do it, but as it's business logic it's dependent on large amounts of referential data that sit cached in hashmaps in ram.

*** Why a single language? Simple: Language interop is too expensive (speed of execution, speed of development) because it involves writing adapters and marshalling.

how does .net's approach fare as a middle ground?

The output is purely dependent on its input
...but as it's business logic it's dependent on large amounts of referential data that sit cached in hashmaps in ram.

Assuming these hash maps of ram are static you are really passing a pointer to large data structures and that's something FP has no problems with. Just predigest the data. Now if those hash maps are dynamic you really do have state in a fully meaningful sense and you aren't going to get much benefit from functional safety.

why do I have to throw away a for and while loop when it's good for the job?

Because they aren't good for the job for pure functions. They encourage exactly the things you are trying to avoid: side effects, interdependencies so you can't cache or parallelize.... Either you don't need side effects in which case you want to use looping structures that are much more powerful in other ways; or you do need them. Quite simply for and while aren't good looping structures for non imperative code, they aren't good for the job.

And if you need them there are type safe ways of getting them:

fac n = result (for init next done)
        where init = (0,1)
              next   (i,m) = (i+1, m * (i+1))
              done   (i,_) = i==n
              result (_,m) = m

for i n d = until d n i