On Sat, Jun 4, 2011 at 10:44 AM, Julian Leviston <jul...@leviston.net>wrote:
> Is a language I program in necessarily limiting in its expressibility? > Yes. All communication architectures are necessarily limiting in their expressiveness (in the sense defined by Matthias Felleisen). For example, can't easily introduce reactivity, concurrency, and constraint models to languages not already designed for them. Even with extensible syntax, you might be forced to re-design, re-implement. and re-integrate all the relevant libraries and services from scratch to take advantage of a new feature. Limitations aren't always bad things, though (e.g. when pursuing security, scalability, safety, resilience, modularity, extensibility, optimizations). We can benefit greatly from favoring 'principle of least power' in our language designs. > > Is there an optimum methodology of expressing algorithms (ie nomenclature)? > No. From Kolmogorov complexity and pigeon-hole principles, we know that any given language must make tradeoffs in how efficiently it expresses a given behavior. The language HQ9+ shows us that we can (quite trivially) optimize expression of any given behavior by tweaking the language. Fortunately, there are a lot of 'useless' algorithms that we'll never need to express. Good language design is aimed at optimizing, abstracting, and refactoring expression of useful, common behaviors, even if at some expense to rare or less useful behaviors. Is there a good or bad way of expressing intent? There are effective and ineffective ways of expressing intent. We certainly want to minimize boiler-plate and noise. If our languages impose semantic properties (such as ordering of a collection) where we intend none, we have semantic noise. If our languages impose syntactic properties (such as semicolons) where they have no meaning to the developer, we have syntactic noise. If our languages fail to abstract or refactor some pattern, we get boiler-plate (and recognizable 'design patterns'). But we also don't want to sacrifice performance, security, modularity, et cetera. So sometimes we take a hit on how easily we can express intent. is there a way of patterning a language of programming such that it can > extend itself infinitely, innately? Yes. But you must sacrifice various nice properties (e.g. performance, securability, modularity, composition) to achieve it. If you're willing to sacrifice ad-hoc extension of cross-cutting features (e.g. reactivity, concurrency, failure handling, auditing, resource management) you can still achieve most of what you want, and embed a few frameworks and EDSLs (extensible syntax or partial evaluation) to close the remaining expressiveness gap. If you have a decent concurrency and reactivity mode, you should even be able to abstract and compose IOC frameworks as though they were normal objects.
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
