Lambda the Ultimate

Hi, I'm looking for a good online forum that focuses on the practical details of building compilers. I've posted a lot of material on LLVM over the years, however that forum is really dedicated to issues specific to LLVM and not compilers in general. Similarly, LtU is more focused on theory than practice (which is not to say that I'm not interested in theory.)

I'd like to find some place where I could post questions about things like efficient multimethod dispatch, garbage collection algorithms, and so on, and not feel like I was off-topic.

Also, when it comes to feedback I would favor quality over quantity.

Any suggestions?

- Synopsis -

What is Code Disease?

A code disease is a factor of code that harms or destroys expected ease of software development and maintenance. Often propagating problems up to the business execution and strategic levels, code diseases are costly and risk-inducing. As its strong name indicates, a code disease is very serious and potentially threatening, with its first victims the morale and sanity of the developers who live with it daily, and its final victims the customers who are punished for relying on your business’s affected systems.

Please find the PDF here - Diseases in Code (rev. 2)

LtU is the first place I've posted this, so hopefully I can get a bit of feedback!

I recently created a proposal for a StackExchange site for Programming Language Theory. It is currently in the Definition stage and it requires a plethora of good quality questions - questions which you would expect to see on the actual site once it is created. There are already a few example questions. However most of the questions are by users who seem to be only enthusiasts. We need more followers who are experts at PLT to give the site a definite shape.

With respect to detected contradictions in large information system, according to [Russo, Nuseibeh, and Easterbrook 2000]:

"The choice of an inconsistency handling strategy depends on the context and the impact it has on other aspects of the development process. Resolving the inconsistency may be as simple as adding or deleting information from a software description. However, it often relies on resolving fundamental conflicts, or taking important design decisions. In such cases, immediate resolution is not the best option, and a number of choices are available:

• Ignore - it is sometimes the case that the effort of fixing an inconsistency is too great relative to the (low) risk that the inconsistency will have any adverse consequences. In such cases, developers may choose to ignore the existence of the inconsistency in their descriptions. Good practice dictates that such decisions should be revisited as a project progresses or as a system evolves.

• Defer - this may provide developers with more time to elicit further information to facilitate resolution or to render the inconsistency unimportant. In such cases, it is important to flag the parts of the descriptions that are affected, as development will continue while the inconsistency is tolerated.

• Circumvent - in some cases, what appears to be an inconsistency according to the consistency rules is not regarded as such by the software developers. This may be because the rule is wrong, or because the inconsistency represents an exception to the rule that had not been captured. In these cases, the inconsistency can be circumvented by modifying the rule, or by disabling it for a specific context.

• Ameliorate - it may be more cost-effective to ‘improve’ a description containing inconsistencies without necessarily resolving them all. This may include adding information to the description that alleviates some adverse effects of an inconsistency and/or resolves other inconsistencies as a side effect. In such cases, amelioration can be a useful inconsistency handling strategy in that it moves the development process in a ‘desirable’ direction in which inconsistencies and their adverse impact are reduced."

It is not generally proper to post call-for-papers on LtU. Exceptions have been made, for broad workshops likely to appeal to many LtU readers. I hope the 2014 ML Family workshop also qualifies.

The ML Family workshop intends to attract the entire family of ML languages, whether related by blood to the original ML or not. Our slogan is ``Higher-order, Typed, Inferred, Strict''. Designers and users of the languages fitting the description have many issues in common, from data representation and garbage collection to fancy type system features. As an example, some form of type classes or implicits has been tried or been looked into in several languages of the broad ML family. We hope the ML Family workshop is a good forum to discuss these issues.

Also new this year is a category of submissions -- informed opinions -- to complement research presentation, experience reports and demos. We specifically invite arguments about language features, be they types, garbage collection, implicits or something else -- but the arguments must good and justified. Significant personal experience does count as justification, as do empirical studies or formal proofs. We would be delighted if language implementors or long-time serious users could tell, with examples from their long experience, what has worked out and what has not in their language.

The deadline for submitting an abstract of the presentation, up to 2 PDF pages, is in a month. Please consider submitting and attending!

Recent Turing Award winner Leslie Lamport's talk at the Build 2014 Conference, Thinking for Programmers. I do wonder if the level of specification (thinking) Leslie recommends here is realistic/necessary in this day of apps, web pages, and mostly non-systems/non-critical programming mostly done by app developers with little to no formal education in mathematics or computer science.

"If you don't start off with a spec, every piece of code you write is a patch".

What do you think, when applied to the programming environments of today (apps, web pages, non-critical systems, etc...). Does it go too far to assume this level of thinking?

It appears that too many developers do not understand actors, and that actors have not been explained very well. My thought is that a model that behaves, to a degree, like actors might go a long way to explaining actors through analogy, especially if that model can be implemented with a minimum of code. Mind, the model is only an approximation. But even so, you may find it interesting/informative.

more

In the past few months I've thought about HyperCard some, in the context of an app that would use a high granularity fiber-VM implemented with coroutines as continuations. Imagining fiction-based docs about such a VM, I supposed one character might decide "I want to clone HyperCard" and then look at issues from that perspective. One reason this is interesting is because HyperCard downplayed exactly what happened in terms of time-order when events were processed: objects executed HyperTalk scripts in response to event stimulus like mouseUp, and other events. In principle these might run in parallel with each other — except Mac apps at the time rarely exposed concurrent semantics, and no way to coordinate via locks to avoid interference was provided in the language.

(I see a daemon-based implementation, with the UI in another process that is just viewer, frontend, and editor, so you can expose both a browser interface and native widget app UI at the same time for the same daemon runtime. This would include remote shell connections to run scripts in the daemon the same way you could run commands in HyperCard from a little message dialog box. The main disadvantage with this model is that you can write really unpleasant things with it, like distributed fork bombs, that you can't stop end users from deploying. In other words, it would be easy to be evil, which gives me moral qualms. The last time I said this to a coworker months ago, he said what people do with tools I write is not my problem.)

As an excuse to talk about HyperCard, I'm using a Hacker News discussion to source an interesting remark from Programming Languages are the Least Usable, but Most Powerful User Interfaces (uw.edu) (Andrew Ko).

In the top comment as of this moment, HN user jasonwatkinspdx supposes:

If the hypercard model had the value I think it does, someone else should have surfaced and gained momentum.

I especially like suppositional reasoning, so this sort of remark is one I enjoy. A reply I have in mind writing here (if anyone likes this topic) has at least two parts: 1) what would happen if someone deployed an updated HyperCard style tool, and 2) how folks pursue options in tech that yield max personal advantage rather than intrinsically useful basic infrastructure.

Unless someone does so first, later I'll quote a paragraph from Andrew Ko's original piece: the part about value of text programming languages in contrast with graphical user interfaces. I want to keep this first post short, as a seed for discussion, if any. I'm more interested in the programming language angle — how does a runtime behave and how does this model appear in the language — than I am in the business model of an app, which is off topic here. Also completely on topic is Andrew Ko's original blog post (same as the HN link above).

F# is the first MS language to go open source. The F# team is now going further into the Open World to allow community contributions to the core language, library and tool set. This means the F# team will now take pull requests :)

From a recent blog post on the topic:

"Prior to today (April 3, 2014), contributions were not accepted to the core implementation of the F# language. From today, we are enabling the community to contribute to the F# language, library and tools, and to the Visual F# Tools themselves, while maintaining the integrity and unity of the F# language itself.

In more detail:
•Contributions can now be made to the core F# compiler, library and tools implementation.
•Proposed changes will be rigorously moderated by ourselves and other community contributors from Microsoft Research and the F# community.
•The full tests for the F# compiler and library are now available.
•In time, the full source code and test suite for the Visual F# Tools will be made available."

Blueprints enable anyone to rapidly prototype and build playable content without touching a line of code. Use Blueprints to author level, object and gameplay behaviors, modify user interface, adjust input controls

WHAT CAN YOU DO WITH BLUEPRINT?

Tutorial Videos