Lambda the Ultimate

When thinking about what pains are worst when writing code, it seems like it all boils down to dependencies. Even as a user, the problem seems to be the same. Ehrm, correction, as a user I get frequently insanely mad at dependency problems. As a programmer, it is more of the moaning kind.

My first thought was to do a better make language, since this was where most of my pains were. Then I realized, it is bigger than this. Just building the thing isn't all there is, installing it, remember what was installed and why, be able to remove some of it that seems to be in the way, and so on. Not to mention configuration problems. Now, why was that configuration set in that way, who depends on it? What would happen if I changed it? Sometimes I don't even know how to find the answers.

My current thought is to deal with this once and for all. Let's make dependencies a first class entity in the programming language, make it externally visible and then watch what would happen.

The questions I haven't been able to figure out any answers to yet are:

1. How should this be implemented?
2. What could this achieve?

Has anyone been there before me, as usual, and written some vice word on the subject?

Anyone having similar ideas?

I would like to present my project; it might be interesting in light of the 'Learnable programming' discussion. The Pooh language lives here It has the following features:

• Does not force to introduce OO concepts from the start; non strict OO viewpoint.
• Makes flow visible by tracing of the program flow; the -x command line option instructs the interpreter to trace each statement and evaluation results + intermediate values.
• A focus on readability and clarity in syntax and semantics
  • no statement delimiters - no semicolons
  • all function parameters are passed as named parameters;
  • all variables declared in function are local;
• Variable must be defined before use, similar to strict mode in Perl; variable is defined if value is assigned to a name.
• The language has closures and can do objects by prototyping; has higher order functions like map/fold/filter .
• If a non local variable is referenced, then it must have the prefix outer . ; references to global variables from a function must have prefix global . ; object member references must have prefix this .
• the Pooh language has green threads / co-routines / generators like Lua; so there are nice for loops like in Python. The local variety of this idea is called Pooh routine.

Thank you for your attention.

Things are too quiet lately, so maybe its time to start a fun thread. I used this question as a lead in to a presentation on live programming I recently gave at a working group, but I thought it would be fun to gather a bunch of predictions if anyone is willing.

What will programming look like in 2020? Keep in mind that programming in 2012 mostly resembles programming in 2004, so could we even expect any significant changes 8 years from now in the programmer experience? Consider the entire programming stack of language, environment, process, libraries, search technology, and so on.

The source for the REBOL 3 system has been released under an Apache 2.0 license.

The github repository is at: https://github.com/rebol/r3

tl dr - how does one learn to do DSLs as good as how STEPS people apparently do them?

So the STEPS progress report indicates that knowing how to make really good concise DSLs is a super power for programmers who want to avoid having too many lines of code. I have perused things like Fowler's DSL book, and am wondering if that is pretty much close enough, or if there's some other things one would have to know and practice in order to get STEPS quality/style magic bullet DSLs? Frankly, the times I've seen people make their own language in industry, they've almost all inevitably been a train wreck. "When faced with a problem, some people say, 'I know! I'll create a DSL!' Now they're faced with two problems."

The eighth draft of the Scheme R7RS-small standard has just been published. This draft contains editorial corrections to the seventh draft, as well as changing the definition of eqv? on inexact numbers to the style of R6RS operational equivalence.

This draft will be used for the ratification vote by the Scheme community, though we will continue to correct mistakes before the final draft. Details on the ratification vote will be published at scheme-reports.org and on the scheme-reports@scheme-reports.org mailing list.

An implementation based on a paper I posted on LtU a couple years ago. It turned out to offer a great programming model, which looks like REST but dynamic, like Google Docs vs. a static Web site. The eventual consistency aspect allows server scalability and offline modification of data for clients. Versions merge later when connectivity is back, like distributed source control. link

I've been thinking. Sorry, I can't help it. There is no 'off' switch on this thing.

A ubiquitous problem in programming is Entanglement.

We want clean, documented, specified interfaces, but it is all too easy to create an inadvertent reliance on undocumented, unspecified features of a particular implementation, which may or may not be correct according to the actual intended/specified interface and which may or may not be carried forward or repeated in future implementations of that intended interface. This is a problem because it means code breaks later, when a new implementation comes along.

Another Entanglement problem is that when we import a given library, we implicitly import all of that library's dependencies, and all of their dependencies, ad nauseam; often the transitive closure of stuff that gets imported contains a lot of duplicated functionality where subcomponents relied on "similar" services by importing different libraries where they could reasonably have imported the same library.

Finally, it is all too easy to create an implementation of some specification which fails to actually fully meet that specification, and not realize the fact because it works for the particular instance of our program. This is a related problem, because use of the library then causes bugs in other programs.

It seems to me that we don't really want to import ephemeral, overspecific, and possibly buggy implementations of functionality; we want to import hopefully less-ephemeral _specifications_ of functionality. Instead of saying "give me library foobar, located at /path/to/foobar" we should be saying "import a library which implements the foobar specification, where the specification file is located at /path/to/foobar."

The distinction is admittedly small from the programmer's POV, but this would allow the linker to pick an implementation (where multiple implementations meeting the spec are available) to optimize performance, or size, or other considerations. It would also provide for an executable specification that tests all (and only) the functionality guaranteed by the specification when some programmer asserts that their library meets the spec. Where different subcomponents import similar functionality from different sources implementing the same spec, the linker could simply relink them all to a shared source, eliminating redundant branches of their dependency trees. And finally, we should be testing our libraries anyway, right? Why not build the test suite directly into the standard library, along with more than one implementation of each? In using them, surely we'd discover bugs a lot faster.

If code breaks when a different library implementation is swapped in, then it means the specification test suite is failing to test some property that the code relies on. That means that either the specification test suite is incomplete, or the code that purports to rely on an import meeting exactly that specification is wrong. This would make detecting inadvertent Entanglement issues very much easier. Likewise, an executable test suite for each library being part of a language's standard would make a huge contribution to bug testing all new or updated versions of the standard library, allow providing multiple library versions optimized for different constraints and purposes transparently, and make it absolutely clear what a specification does and does not guarantee.

Parameterized modules have been discussed here before. Gilad Bracha has blogged about it. dmBarbour has posted here about linkers as constraint solvers.

I imagine providing a debugging version of each standard library, created specifically to protect against Entanglement. These should implement all of the spec -- and, where possible, do absolutely nothing else reliably. Where the spec doesn't specify, for example, which element of a set is returned or what order things are evaluated in, the debug library versions should deliberately randomize these things. Where the spec says an error may be thrown in the library, the debugging version should occasionally do so for no reason at all, exposing code that has no error recovery capabilities. Once your program runs correctly in debug mode (using the debugging versions of all libraries), you can simply relink in performance mode.

So, anyway, I'm just throwing this out there for your consideration and feedback.

Ray

(As seen posted on an Obj Cap list today)

Uniqueness and Reference Immutability for Safe Parallelism. 2012.

We provide a novel combination of im- mutable and unique (isolated) types that ensures safe paral- lelism (race freedom and deterministic execution). The type system includes support for polymorphism over type quali- fiers, and can easily create cycles of immutable objects. Key to the system’s flexibility is the ability to recover immutable or externally unique references after violating uniqueness without any explicit alias tracking. Our type system models a prototype extension to C# that is in active use by a Mi- crosoft team. We describe their experiences building large systems with this extension. We prove the soundness of the type system by an embedding into a program logic.

Hi there.

Not a very serious project, but I'm currently building tag clouds describing various programming languages at http://plwords.herokuapp.com/.

In case some of you want to contribute their feeling / knowledge about common programming language, some tag clouds really need more contributions!