Lambda the Ultimate

Just wondering! (edit: I wrote a non-trivial demo app for our CIO once when he was curious about Curl's potential, back when he was undecided on Silverlight vs. Flash vs. DHTML vs. desktop smart client vs. "Mars Rover Project" ;-)).

I like Curl's consistency and relatively gentle slope between simple formatted text and rich applications. I'm not a fan of polyglot programming.

Bracha's Newspeak is constrained in interesting ways; the decisions behind its module system (banning imports, cutting out static) are worth learning.

I have no plans to learn UML before I die. I'm sure they'll be teaching it in hell.

Speaking of Lustre and Esterel, you may also give a try to Lucid Synchrone, a higher-order Lustre-like language extended with various constructs inspired from Esterel.

What was inspired from Esterel?

Lucid-like languages are a good example of abstracting away the language and looking at a more broad category of something. The OP could also search for "intensional transformation" or "intensional programming" in an academic search engine like the ACM Digital Library.

Esterel introduced (?) synchronous semantics, sort of under the abstract state machine model: time step begins, effects happen (and are unified in case of conflict), next time step begins with previous effects + new inputs. Lucid, FRP, etc. took the same semantics, introduced higher-order values, but eliminated explicit effects. Interestingly, we're full circle now: Coherence uses transactions/search for rich unification while Revisions and Cilk do a simpler, more Esterel-like approach of explicit merge operators (hyperobjects/reducers in Cilk parlance).

What was inspired from Esterel?

Mainly valued signals IIRC.

In the same vein, I've been mostly looking at languages that, first, are trying to help us with the constraints of current systems: Blelloch's NESL and scan model languages (now popular for multicore and GPU systems), the Swarm language for moving the computation to data, LINQ's extensions PLINQ, DryadLINQ, and Rx, and many others. At the same time, our computing substrate is changing: one of the most fascinating substrates is biological. There is some really fun language ideas and opportunities here.

My point is that if you pick a constraint or topic, you should find a lot. What about security? Multi-principal programming and privacy are becoming a big deal, leading to: capabilities, information flow (quantitative, differential, ...), PCC, etc. What about programming-by-demonstration? Synthesis is now a big deal, with sketching as the most prominent, but the HCI community has us beat: the PL and SE community is nowhere near where they want us to be.

There's definitely a lot of exciting stuff out there. Well, I suppose topics such as security, moving computations to a GPU, programming with touch, et cetera might bore most people to sleep, but I find it exciting.

You can always dress it up: security => programming with multiple cellphones at the same time, GPUs =L massive physical simulations and AI, biological and neural computing => freaky science, PBD => minority report, ... . If there's something cool, we need an interface to do it.

Regarding security, I have the strange feeling that what have always known "the solution", which is common sense: apply the principle of least privilege. I'm under the impression that it's simple and would work, only that application and system developpers just don't do it.

Is there a reason I'm missing why, in the 21th century, my web browser is still able to open any file I own, other than the file it uses for internal work, some private temp files, and the download locations I explicitely specify?
It might fall under dmbarbour's theory of "path of least resistance" --- people are not yet forced to think about what authority they need -- but I find it a bit hard to accept.

(I didn't name it "capabilities", because I think capabilities are a bit more than that, and other models may also be adequate. Actually I don't care what the developpers of the application I use think of security or use as security paradigm, as long as they respect the POLA)

POLA isn't a solution. It's a principle by which you might judge a proposed solution. I actually favor a different set of principles:

Ka-Ping Yee's Principles for Secure Interaction Design:

Path of Least Resistance

Match the most comfortable way to do tasks with the least granting of authority.

Active Authorization

Grant authority to others in accordance with user actions indicating consent.

Revocability

Offer the user ways to reduce others' authority to access the user's resources.

Visibility

Maintain accurate awareness of others' authority as relevant to user decisions.

Self-Awareness

Maintain accurate awareness of the user's own authority to access resources.

Trusted Path

Protect the user's channels to agents that manipulate authority on the user's behalf.

Expressiveness

Enable the user to express safe security policies in terms that fit the user's task.

Relevant Boundaries

Draw distinctions among objects and actions along boundaries relevant to the task.

Identifiability

Present objects and actions using distinguishable, truthful appearances.

Foresight

Indicate clearly the consequences of decisions that the user is expected to make.

It turns out that object capabilities are also really good for achieving the SID principles.

POLA differs from Yee's Path of Least Resistance in a significant way: POLA is an assertion about how many authorities a component holds, whereas Path of Least Resistance is an assertion about how many authorities a (lazy) agent grants.

This is reflected in how I treat code distribution... e.g. a service 'replicated' to my machine might contain its own authorities for a few low-level services - perhaps an http cache, random number generation, file-like persistence, and time. Since I didn't grant those authorities, I'm not the one responsible for them, nor am I at any additional risk than if I was using a remote service. Under the hood, some carefully chosen services might be implemented via unum pattern in order to optimize them - e.g. no need to go all the way across the network for random numbers. In comparison, a typical POLA approach is to distribute pure code (no embedded capabilities) then use a sandbox or powerbox to control which authorities that program ever holds. This way, the code has no authorities you did not grant, and you can ensure it holds a minimal set. The problem with this: you become responsible for all the broad, low-level stuff in the program's minimal set, and it is very difficult to audit or grok potential abuses of low-level services. Much better if you can focus your attention on granting high-level authorities, such as access to a webcam or GPS.

Ah, well. A lot of smart people get fixated on POLA and confinement to the point of losing sight of the real requirements for security, which inspires such rants as the above. Confinement patterns should be available when necessary, but are far less often necessary than adherence to POLA would suggest.

I don't care what the developpers of the application I use think of security or use as security paradigm, as long as they respect the POLA

Here are some reasons you should care: robust composition and extension of applications/services (e.g. transitive service invocation, support for modular plugins, mashups, scripting, remote debugging), performance, scalability, points-of-failure, simplicity, and administrative overheads.

Security models or mechanisms can differ greatly in other relevant properties while still achieving desired security properties. Object capabilities are a huge win when judged in terms of these other properties, though they can be further augmented with static analysis and control over information-flow.

We've seen this fail, e.g., alert boxes asking you if something is ok just trained users to hit "ok".

Security is hard both in terms of the math and the people, and, unfortunately, we need to combine them. An interesting paper I read recently touching on the more general problem (though often questionable for the CS and SE side of things) is "The Intellectual Challenge of CSCW: The Gap Between Social Requirements and Technical Feasibility".

Take passwords as another simple example of the tension between security and usability. The more complicated the password, the more secure you are, supposedly. However, while our PCs might be protected by an 8 character alpha-numeric password with a special character, our bank accounts at an ATM are protected by a 4-6 digit numeric PIN! It turns out this is often good enough, especially since you have to have the card (easily cloned and not even chipped in the States) to use the PIN. As a result, we are seeing devices move to simple PIN-based passwords rather than complex PC passwords.

It turns out the new hot device solutions for security is just a walled garden: don't allow apps to do much of anything except store some of their own state, access the network, and twiggle some sensors. This is augmented with some vetting and reputation building via an app store. We have seen some abuses (Android apps spying on users) but in general people seem to be happy with it. Nobody that I know of is looking at complex formal models to enhance security in the consumer domain, that is very telling.

I don't see the walled garden as very different from the browser world (process separated, limited storage, etc.), and that is just the story the OS community has been saying for decades.

The problem is the app model sucks. Open up cnn.com or whatever your favorite site is in firebug and see how people like to write apps (in short, linking in lots of third-party stuff and user content). As the app model matures, we'll see the same things as the web model: as an example, people are already linking in advertisement software. It's essentially the web model but worse (perhaps the silver lining of having such an archaic developer environment is that people are slow to do things they could have quickly done on the web, saving us from bad software being created).

Stepping back, traditional desktop security issues are largely solved. Buffer overflows etc. are increasingly not a concern. In contrast, application-level attacks, like XSS, are. I'm serious: there are monthly etc. tallies about attacks. Attackers may or may not hijack your computer (e.g., by heap spraying the JSVM), but they will hack your website account (XSS). Some of the problems seem to be self-inflicted (JS is great for privilege escalation and has no intended support for multiprincipal programming), but others are just hard problems we don't know how to handle (how *do* you do multiprincipal programming? In practice, this is new ground for the computing industry.)

Whatever you think about the walled garden app model, it is where all the innovation seems to be taking place. For example, Apple Google, Microsoft, etc... could eventually pull advertising duties into the OS, meaning they would disallow (by fiat of course) potentially insecure third-party advertising infrastructure. That alone would reduce the needs of many apps for additional privileges. The more they pull into the OS, the less privileges apps need to serve users (innovation and legal concerns of course remain).

My gmail account was hijacked last week, no idea how they did it (used a unique password, always used https) but I know this is a real problem. However, I'm not sure how any of the more sophisticated security schemes could have prevented that.

I'm trying to respond to this in a non-flamey way. If it comes out badly, it's not intended to, and is actually my second rewrite of this response.

it is where all the innovation seems to be taking place

There is great business innovation in the app model; I'm not really qualified to talk about that, but it's interesting to compare something like download.com and Steam/OnLive: the apple/android app stores seem more like download.com to me. There are all sorts of interesting conclusions one can draw from that, e.g., the role of advertising. However... that's not about the technology.

In terms of the technology, as app models support dynamic languages / embedded browsers and browsers go more native, the line really blurs. The only really interesting distinctions to me are that current apps are native and single principal, but I view that almost as an anachronism from starting a new eco-system using old technology. It also ties into the next point:

could eventually pull advertising duties into the OS

Why do you trust Apple more than Google than Flashmob? I agree that I do trust the OS and, as a dual, for managed languages, the language. As a third seeming tangent, why is advertising so special? Similarly, why not use multiple ads in a system, e.g., iAds for the visual ad and then several invisible services for user tracking?

Modern software comes from multiple sources, involves many developers of varying ability, and increasingly, dynamic user content. The web has gained the most critical mass here -- I'm often surprised when I look at just what javascript is running on my favorite site -- but if something is to replace the web, not supporting this in it seems like a step backwards (and thus it would ultimately reappear).

I know this is a real problem. However, I'm not sure how any of the more sophisticated security schemes could have prevented that.

If there was a good solution, it wouldn't be a real problem ;-) (I'm a little facetious here -- e.g., SQL injection attacks are more of a social problem than a technical one.) I think it's just a matter of time for the most part -- we already are making great headway. Key players like advertising frameworks and platforms like Facebook are pretty solid by utilizing a lot of good techniques and effort. The research community has been doing a lot too -- browser-based and search engine malware detectors have a lot to thank for here, and approaches like symbolic execution are only recently being carried over. I'm fairly optimistic. OTOH, I do think this is also one of the biggest language challenges of the decade.

In terms of the technology, as app models support dynamic languages / embedded browsers and browsers go more native, the line really blurs. The only really interesting distinctions to me are that current apps are native and single principal, but I view that almost as an anachronism from starting a new eco-system using old technology

The point is that we didn't need managed languages or better security models to make device apps safe and reliable, we just needed an app store. Whatever anachronisms remain are pretty irrelevant.

Why do you trust Apple more than Google than Flashmob? I agree that I do trust the OS and, as a dual, for managed languages, the language. As a third seeming tangent, why is advertising so special? Similarly, why not use multiple ads in a system, e.g., iAds for the visual ad and then several invisible services for user tracking?

I trust Apple or Google a lot more than I do someone I've never heard of before. It all comes down to who to blame. Blaming a small time app developer isn't very useful, while blaming Apple is. I'm much more likely to trust a small time app developer if Apple takes care of advertising.

Browser cookies exist primarily for marketing and advertising reasons. Take that reason away by including infrastructure in the OS (and forcing apps to use that infrastructure), and we can get rid of cookies, life becomes better for everyone. Cookies won't come back from that, they are just too horrible.

Clean slates are great... but a temporary fix: 1) you throw away the baby with the bathwater and think you've solved it... but 2) you're just starting on a new ball of mud. There may be solutions to the problems, but what about the app store model qualifies as one?

Modern software requires multiprincipal composition and a host of security-sensitive features. I mean this in a very real sense. Cookies are a great example: they're just a form of persistence for otherwise sandboxed apps; HTML5 has various *new* forms of this and even Flash, a different technology, has its own system. The security challenges are intrinsic (and, with the increasing role and sophistication of software, increasing!). Saying the app store solves it doesn't make it true. E.g., apps also have a persistence layer: how else do you save game state between phone use during disconnected operation?

As the app store matures, components (#include, script="blah.src", "import antigravity", whatever) will come back. Advertising has already demonstrated that; there are multiple advertising platforms. There are many other reasons to compose software from different parties -- I'm surprised that's a contentious point.

I'm not arguing that composition is evil, far from it. Composition is great, but many of the components that you compose with should basically be trusted parties. That is, rather than including someone else's code in your app, it is often better just to link with a trusted service. Perhaps the service comes from the OS, or perhaps its a third party that is vetted and installed on the device separately from your app. The state of composition today...the app composes services by including their code, we have no idea about the integrity or trust worthy-ness of that code, or even if it is really the code that the app developer thought they were reusing. Instead, if I link to an advertising service, that service should have some level of reputation within the ecosystem, and there should be no way to circumvent that.

The apps should have privledges, we know who to blame if something goes wrong (the app), but those privledges shouldn't automatically extend to third-party code.

App stores are a clean slate where we can begin implementing more sane policies with regard to composition. Its still early, we have Apple saying "no third-party components" which is of course unrealistic and easily gamed. But there are better solutions than just going back to the crazy web model. If anything, we will see the web model move toward a better app model.

Right, I think we're in agreement. Not sure if the web platform will be the one to substantially fix the composition problem, but the problem isn't going to go away for anyone in the general end-user application space. The OS vs. the browser providing the services, to me, is an implementation detail (though important) -- for example, program analysis, hardware, and hypervisers all have also been demonstrated to be effective for certain properties, and we are starting to see all of them being used.

The insight that security controls *need* to be richer is the tricky one to me. What are they? Who turns them? Adoption issues? I have one vision for the important knobs here -- see my W2SP 2010 paper -- and some experience in getting different people to turn them -- see my Oakland 2010 and, to a lesser extent, WWW 2010 one -- but there's a lot more to the issue (e.g., user and third-party control of their data rather than application providers/composers like facebook, automated agents like search engines and browser filters, the role of collaborative security features to bridge the CSCW gap, etc.).

You and Leo (and many others) have observed tension between security, flexibility, and usability in our modern application architecture. Some would conclude this tension is necessary, that there will always be a trade off between these properties. In the capability security community, however, we understand this tension to be a consequence of the modern application architecture and life-cycle (including development with of shared libraries, distribution model, maintenance and upgrade). Security, flexibility, and usability can coexist, but we'll need to redesign much of our architecture to make it happen.

Take passwords as an example. Currently, we use identity-based security for dozens of sites. This isn't very secure: people tend to use the same passwords at every site. This isn't very flexible or composable: we run into all sorts of problems with delegation. (When Bob is acting on behalf of Alice, whose name and password does Bob use?) And it isn't very usable: name and password repeatedly become a barrier to getting work done, over and over again.

Take those annoying 'permission' dialogs as another example. As Leo mentions, those just interfere with usability and train users to press 'Ok' without really understanding what rights they are granting or how they might be abused. Even worse, the rights are usually really low level and coarse grained... e.g. access to a network or a filesystem. Low-level services and APIs are pretty much impossible for users to grok and audit, just like low-level code is pretty much immune to static analysis. Even coarse-grained access to UI, seemingly benign, subjects us to click-jacking and denial of service.

Users can't reason about low-level authority. Any grant of authority MUST be at a level of abstraction and granularity that users can understand.

The reason to seek better security models is to improve usability, flexibility, and performance.

The object capability model allows us to isolate identity-based security to just an initial portal login for human users (since humans can't remember capabilities) that grants access to a user agent. It allows very fine-grained delegation, which makes services much more flexible and extensible and allows multi-principal composition.

And alternative application models based on ocaps and fine-grained object APIs (rather than sandboxing and VMs) have been developed that avoid issues for those dialogs. For example, we can treat applications as shards of remote services replicated to our machine, rather than something we download then run in a sandbox. In the few cases we need limited confinement, that can be expressed as part of the API on our side (e.g. pass a pure function to this method).

Even under these conditions, reputation and trust will still be an important part of the application architecture, especially the distribution model... e.g. similar to how users might trust services requested Amazon or Google more than from an arbitrary site. But we don't need the walled gardens.

There may, however, be some tension between security and profitability. If our web-apps were to be rich, high-performance, extensible and secure, the app-stores would splinter and be much more competitive.

Capabilities are flexible, but the point is it's unclear how to actually use them (or any other current technology) to solve CSCW problems in a full (i.e., contextual) system.

Ocaps won't help you solve a problem before you even define it. (And CSCW consists of many poorly defined problems.) They also won't solve a problem that has no solution.

But there are many capability patterns for solving specific CSCW-related problems. You probably underestimate how much work has been done, if you haven't been reviewing history and keeping up with the capability security community.

I am on the ocaps list etc.

Rewriting your statement a bit:

But there are many assembly instructions for solving specific CSCW-related problems. You probably underestimate how much work has been done, if you haven't been reviewing history and keeping up with the compiler community.

-- from a CSCW viewpoint, we're in the assembly level of security controls. Adding DAC, ocaps, provenance tracking, etc. is still very low level. Technical solutions for CSCW problems start more like the paper @ WWW last year on machine learning of security policies for Facebook. I would agree that the infrastructure for deploying such solutions sucks (and, for example, might benefit from an ocap layer), but that's just a stepping stone.

Furthermore, an interesting question posed by the paper I cited originally is whether it is even possible to close the socio-technical gap -- for one interpretation, is end-user security AI-complete? (I don't really want to argue that one, but it's pretty darn deep!)

CSCW is an uber-broad ill-defined subject covering such things as e-mail, IRC/IM, MUDs/MOOs, Croquet Project / Second Life / virtual worlds, collaborative editing, bookmarking and sharing views, teleconferencing, remote learning, blogs, wikis, distributed version control systems, bulletin boards, project management software, bug tracking, calendars, workflow, electronic trade and contracts, et cetera.

I'm saying that there are many ocap patterns to secure and federate many specific applications of these classes.

If this seems low level it's only because CSCW isn't so much a domain as a cloud thereof, and everything looks low-level when your head is in the clouds.

The WWW paper, while I have my own critiques, suggests that we're not very far off (... in decades) of usefully automated social models for security. It isn't even alone in the field.

Indeed, I think that's going to be one of the defining technology arenas for the next long while: duplicating what Google achieved for search for other domains. Social data is here, now we're starting to build it into our systems. Netflix, voting, finance, Amazon, and Google have a head start, but it's growing. Sociology/psychology aren't the same soft sciences we might have found hokey before. You're right in that I'm picking out a subset of CSCW research, but that's largely because I have an engineer's viewpoint and get to stand on the shoulders of others.

(Bringing this back to LtU land: I'm still not sure about the implications for PL. Sort of like Norvig's question about how you do test / verify a search engines.)

While it is true that a token + a secret provides a higher degree of security than a secret alone there are other factors to consider. In the case of a password the threat model allows for an unlimited number of offline attempts. For that reason the search space has to be very large. For most devices that use a PIN the threat model is online guesses where revocation is possible after a small number of failed attempts, hence the much smaller search space.

It's interesting that you say nobody is looking at formal models to enhance security in the consumer domain. The biggest problem at the moment is something that was predicted by formal methods. The current generation of attacks against chip and pin work by faking the terminal that the card authenticates against. That this lack of authentication would create problems was evident in the specification from the start, but it's only being looked at many years after chip and pin was introduced.

I need to experience a language to really understand it, which must be a common need.

I think you also need a good description of why the language was designed the way it is. For example, if Newspeak was just a binary with incomprehensible documentation, then it would be a lot like looking at a "doctored Algol" back in the days when there was the first release of Simula. In that case, your only hope of really understanding it would be to see 20-50 years into the future, a'la Alan Kay.

Speaking of Newspeak, your response above suggests to me you should read up heavily on Newspeak, since there is no doubt in my mind that the basic ideas in it are best suited to your conversational programming. In addition, there have been many papers over the history of computer science about conversational programming, including Gerald Jay Sussman's Ph.D. thesis on expert debugging.

Also, side question: Part of what you are discussing here is better tooling and interactivity. You mention that no language after going higher-level than assembler mattered to you. In what regard did your productivity improve? What sort of text editor/IDE/tools did you use as a professional software engineer?

Yes, I need documentation for a language, like everyone else, but to really understand it I need to use it.

Thanks, Newspeak is really a neat language, and I was especially interested in reflection via mirrors.

To me, for reflection to work requires disallowing changes to existing instances, and changing classes that affect new instances. After the changes, it may be necessary to make instances of either the unchanged class or changed class. In addition, it may be necessary to keep more than the original and one change, or may be necessary to stop an instance, discard the original class, and restart the instance using a changed class.

My approach to reflection is probably better described as keeping several versions of a class, rather than mirroring. However, I do not have working code; thus, it may be necessary for me implement reflection via mirrors, if my current plan does not work well.

I added some info to my LtU profile concerning languages, IDE, and tools.

You should watch Gilad Bracha's Lang.NET Symposium 2009 talk about the Hopscotch IDE.

Also, Gilad has some good blog posts I recommend reading:
Through the Looking Glass Darkly

Patterns of Dynamic Typechecking; I found his description of abstracting over expressions to be very similar to how we do some stuff here at work, even if we are not collectively bright enough to articulate it to each other in that fancy way.

Foreign functions, VM primitives and Mirrors ; Gilad explains why the way Hotspot was designed reduces the programmer's power, disallowing them control over the land of milk and honey

Not as much as I would like; I am slowed by dyslexia.

Thanks for the additional references to Gilad Bracha's work. I skimmed a couple of documents about Hopscotch and will study it further.

I couldn't find Gerald Jay Sussman's paper on expert debugging. Rather, I found it but do not have access to ACM papers:(

All old MIT stuff under old DARPA grants is free material and available on dspace. http://dspace.mit.edu/

As for dyslexia, have you considered e-readers that can do text-to-speech?

Thanks again.

I got along for 65 years without text-to-speech and had not tried such a program. I just tried the "Text-to-Voice" plug-in for Firefox, but have not decided how much help it can provide. One must read with it to see nuances like X², which it pronounces X 2. It reads just a wee bit faster than I do, so it is hard to keep up. Need to check some others.

Newspeak & Hopscotch are very nice and for some things will improve productivity, imo. Thanks again Z-Bo

oops

I didn't know about this language: I haven't finished reading about it, but its syntax is really good, so thanks for the link.

Mainstream languages should be a given, but to truly understand Scala, Javascript, or F#, you have to really live in them. Smaller academic languages are generally designed to emphasize a few points, and it is not necessary to live in these languages to get these points.

Is Scala really taking off in the job market? It seems that at the level needed to program Scala well, the jobs would be more language agnostic and just go after the best programmers (who can use any language well).

Perhaps the OP should start designing/implementing his own languages. It is the next step to better understanding after you've taken in lots of languages.

Scala is taking off in the job market, at least in a relative sense. See http://www.indeed.com/jobtrends?q=scala.

This one is better, and does yourself a service by providing relative comparison: scala, java, haskell, F#, ocaml, c# Job Trends: Relative

As you can see, the world market for Java and C# jobs is saturated. On the other hand, the opportunity for new and emerging markets using newer technologies is growing rapidly.

To put this in context, Sean is right about the mainstream, if you look at this chart as well: scala, java, haskell, F#, ocaml, c# Job Trends: Absolute

Furthermore, 3000% of 3 is less impressive than 10% of 100,000. If you "drill down" into their data set, you see there are 500 Scala jobs vs. 112,000 Java jobs.

For even better metrics, this would need to be compared with labor data from organizations like the Bureau of Labor Statistics (the department of the US government that constitutes Ben Bernanke's "foot soldiers").

When we say taking off I mean trends not absolute numbers. So I repeated the absolute numbers, but without Java and C#, which hid everything else. (Btw you have to discount the Haskell numbers as they are mostly not PL job related. For instance the first page of job listings on indeed.com yields only two programmer jobs). Looking at that it is clear that (a) Scala is taking off, but it's not very far off the ground yet, and (b) Indeed's relative numbers are meaningless for small absolutes.

That is even better than what I tried.

Get an IDE and it will really take off.

Working on it as we speak :-) (i.e getting an IDE).

You don't have a proven strategy for a convenient, responsive IDE?

Perhaps I am mistaken.

At SPLASH, one of the speakers about meta-environments commented that Scala would have been better designed if it was co-evolved with an IDE. I of course got up to augment that perspective, and argued that neither meta-environment research nor Scala designers could produce both a language with its ambition and a good IDE. One example I gave was understanding complexity of the compiler pipeline and how features depend upon one another. It is not clear to me how building Scala using meta-environment tools like ASF+SDF or Stratego and so on would result in as rich of a language.

It would be nice to see a pure "design paper" about these trade-offs; I have had to learn most of this stuff through reading very old papers (from the 1980s) and experimentation with various language ideas. You would be one of the people presumably qualified to write such a paper.

A "good" IDE for Scala is still a problem. The Eclipse IDE is the official one and it's plagued by continuous problems (I'm on the mailing list). It's not just not having all the nice refactoring tools and syntax awareness that the Java IDEs have. It's also stability and speed issues.

I'm not blaming anyone here. I understand good IDE support for a language like Scala is hard. I think it's a good lesson for language designers now and really for years now that if you want a good number of people to use your language then you should also think about implementing something more than an Emacs mode. I'm constantly surprised that even to this day, many developers don't get it. I blame it on a kind of geek machismo where Emacs and Vim are perceived as the tool for the hardcore hacker. This is coming from someone that has Vi(m) keybindings for all his IDEs.

I am painfully aware of the Eclipse issues. That's why my company, Scala Solutions, and I personally make it our highest priority issue to improve things. Judge us in two months, when the new IDE will be out (first beta should be earlier than that).

After 20 years of emacs, I have now switched to the Eclipse IDE that we have in development for working on the 100K line Scala project, and I am not looking back. It's not yet as feature-rich as the Java IDE, but in terms speed and stability we are getting where we want to be.

Meanwhile, the IntelliJ Scala IDE is already very usable and it's also steadily improving.

I blame it on a kind of geek machismo where Emacs and Vim are perceived as the tool for the hardcore hacker.

That is silly.

It took me 14 years as a programmer to understand most if not all the problems involved in IDE and tooling a language. A lot of it involves knowing the right academic resources to consult and the right keywords to type into ACM Portal/Digital Library.

I am pretty sure I still have holes in my knowledge base, and also lack the depth and breadth of experience Martin has. Ergo, why I suggested he write a paper about it. I would actually like to see the meta-environment camp write a similar paper about why a language designed the way Scala was is the wrong approach. But I do not want it to be flame fodder, which it probably would be.

My point was that there is still a tendency by many developers and language designers to this day to discount the importance of IDEs. They don't understand that an IDE like Intellij narrows the productivity gap when programming in Java vs programming in Scala. And some would say that they would be more productive using Scala vs Java, but because of smart IDEs like Intellij they're not. I agree.

I'm curious: in what way do you think those tools impose limits or at least barriers to developing a sophisticated language?

I've only seen these tools used with fairly simple imperative or functional languages. If a meta tool was used to develop a Scala level languages without too many compromises, we'd definitely take more notice.

From his wording, I though Z-Bo might have seen some specific issues.

I am more interested in developing a doussier on language design, from the perspective of efficient prototyping.

This is kind of like the art of compiler design, like handrolling parsers, except rather than using the tricks a master compiler writer would use to handroll solutions, figuring out automated ways to achieve the same efficiencies. For example, from knowing what bottlenecks are in traditional parser generators, you can predict why you'd be better off handrolling the parser rather than generating one. I find that sort of engineering deeply interesting, even if others view it more as mush-work that they can't wait to be over with. I like empirical software engineering, especially when you marry it with automated engineering techniques like parser generators and meta environments.

I have a broader pet project that is the basis for wanting to learn about all these details.

The only limitation with meta-environments is how good their help is, and how well you understand how to use such tools, and what sort of generation abilities they provide. For example, if the meta-environment is really just something very naive and doesn't allow for equational reasoning, then that's pretty primitive and you'll have to role your own.

Access oriented programming doesn't appear to be very scalable. Every read and write can trigger events. Reads and writes are not idempotent, which greatly restricts abstraction and refactoring. System behavior would seem to depend heavily upon the order in which events are injected. I can't even imagine how to remove or maintain elements at runtime. Here is a paper on this recipe for mudballs.

I'm curious. What do you find interesting about it?

I suppose it could be seen as a cousin to the various reactive and dataflow paradigms, which offer somewhat more discipline.

System behavior would seem to depend heavily upon the order in which events are injected.

This is correct. However, in a nondeterministic system, all you need to do is reliably produce a deterministic order for whatever it is that you need to be deterministic. Constraints on events determine the order in which they are injected; that is pretty much inline with current mainstream concurrency theory, such as the stuff done by Gul Agha and Montanari (separately). They might not be called 'events' necessarily, and this problem is more commonly discussed by theoreticians under the name "Brock-Ackerman Anomaly" and "Kahn's Principle".

This is like saying dynamic typing is bad compared to static types because less is decided at compile-time.

I suppose it could be seen as a cousin to the various reactive and dataflow paradigms, which offer somewhat more discipline.

I don't believe those paradigms offer more discipline, they just flip the view of things (Leo Meyerovich had a comment on here recently stating exactly that). Yeah, you cited Bobrow's paper, and, yeah, his argumentation there is a recipe for disaster and not good design advice. And, yeah, Loops is a horrible programming system.

I guess my point is to try to separate the pearls from the swine-waste.

all you need to do is reliably produce a deterministic order for whatever it is that you need to be deterministic

If behavior is locally specified or otherwise constrained, that would be feasible. But the whole point of access-oriented programming is non-local specification of behavior - injecting triggers to properties visible in other modules/objects. It is not clear that, at scale, one could do as you suggest.

But I think you are putting a small box around this idea.

By the way, functional I/O agents can still be non-modular; this is a good counter-example of why I don't buy into your argument that all we need to do is have something that looks feasible. I/O modularity is a tricky beast to tame, or it would have been solved already. I view access-oriented programming as changing the emphasis on what the programmer focuses on when programming; it's about what, not when. Brock-Ackerman just points out that Kahn Principle doesn't extend to a very degenerate case (nondeterministic agents). But even functional I/O can be non-compositional. "Ambiguity" and "meagerness" are alternative ways to understand the problem.

In concurrency theory, mathematicians use nets, because they can actually show things like how sharing a variable works or how communication works, and they tend to use global techniques to prove properties of a system such as firing rules (e.g. Petri nets) or a system of equations. I don't see the task of a programmer as any different from the mathematicians, and how we focus on describing the problem syntactically can probably be somewhat separated from how the solution works.

I think, though, what you mean by "at scale" is "Open system". And I would agree that an open system designed this way would basically be a mess.

The fallacy of the beard is to argue that one whisker is not a beard, and two whiskers is not a beard, and three whiskers is not a beard, and to induce that no number of whiskers will make a beard - that a quantitative difference does not make a qualitative difference.

The scales programmers work at are quantitatively very different than the scales that mathematicians work at. What is in practice a relatively simple business application would be massive compared to the arguments and proofs used in mathematics. There are significant qualitative differences due to scale. I believe it fallacy to treat a programmer's task the same as a mathematician's.

Large scale closed systems look a great deal like open systems. You get to a hundred diverse software components, and deal with the reuse constraints of a few development iterations, and no developer will be able to hold the relationships in his or her puny human head. The system will be maintained by a team of developers, each with a narrow view. Even the threat and vulnerability models aren't so different - security can be compromised by buggy components or anomalies of composition (such as deadlock or glitches or infinite loops or cache coherency issues or update floods). Thinking about all large projects as 'open' seems wise, in general. But if the architecture is good, one can reason about properties by construction.

Access-oriented programming isn't interesting for in-the-small programming. We could just use getters and setters. The ability to attach ad-hoc triggers to properties only becomes unique to the paradigm at the larger scale of component configuration or composition; it's essentially an architectural constraint. Therefore, that is the scale at which access-oriented programming should prove itself.

functional I/O agents can still be non-modular

I agree. If we functionally model stateful event-stream processing elements, we're going to inherit various issues related to functions, state, and event-streams.

I don't buy into your argument that all we need to do is have something that looks feasible

I do not recall presenting such an argument.

I think you are putting a small box around this idea.

Like a coffin? ;)

I prefer to not dilute the meaning of phrases like 'access-oriented programming' by using a larger box than necessary.

I agree that some variation on access-oriented programming might not have the same problem. But it isn't clear to me what you're imagining.

I view access-oriented programming as changing the emphasis on what the programmer focuses on when programming; it's about what, not when

Could you explain your view? Similar has been claimed of functional programming, constraint programming, logic programming, et cetera in the past, and it always strikes me as grandiose. But, in this case, the view also seems entirely unjustified. The idea of triggering effectful actions upon each observation or update of a property seem to cover aspects of both 'what' and 'when'. The order-of-effects makes the 'when' rather significant.

I suppose if you control effects so they are monotonic and commutative, you could have a more declarative ('what' not 'when') model.

AmbientTalk/2 is also a beautiful example of language design for actually existing programmers, IMHO, though the syntax is a bit more conservative than I'd like.