InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Programming Languages: More Powerful with Less Freedom?

Posted by Sadek Drobi on Mar 21, 2008

Sections
Development,
Architecture & Design
Topics
Language ,
Java ,
Architecture ,
Programming
Tags
Languages ,
Language Features ,
Haskell ,
Functional Programming

In quest for more power, C# has recently been grown with new features and Java might follow soon the same path. While extending the choice of features provides programmer with more freedom, does this necessarily provide more power? And does a language need to offer a lot of freedom and flexibility to be genuinely powerful? 

Reg Braithwaite believes that this is not necessarily true. In response to Azubuko Obele’s statement that “people who argue for languages with more power are actually arguing for less rules”, Braithwaite asserts that there is no causal relationship between power and freedom even though the two are correlated in many languages, e.g. Ruby. According to Reg, Python is “a considerably more powerful language than Java” even though both are “built with the philosophy that removing certain programmer freedoms would produce better programs”. In Python, features were not rejected simply because they could be potentially misused but rather when they were judged unnecessary, either because there were already “a perfectly serviceable way” to achieve the desired outcome or because they concerned things “that don’t matter, like indentation”. And this approach did not prevent from adding new features to the languages if those could “fit within Python’s style and design æsthetic”.  

Some functional languages also impose strict rules, which does not mean they offer less power: 

Haskell is quite possibly the most extremely limiting language in common use: there is one way to do everything, mathematically pure functional programming. You have strong, expressive static typing 

[…] 

Likewise, the Factor programming language imposes a single, constraining set of rules on the programmer: programmers switching to Factor must relinquish their local variables to gain Factor’s higher-order programming power.

Hence, Reg argues that “languages can provide more power while also providing more rules and, paradoxically, less freedom.” What really matters, according to him, is careful design that follows a guiding philosophy and brings coherence into the language. The languages can then provide more power by letting programmer achieve more with less and it can be grown without “throwing more [often unrelated] features on top of the pile”:

Good design in every field accomplishes the “antigravity” trick of accomplishing more with less. With poor design, adding new power requires adding more check boxes, more features, more ways to do things that interact with each other unexpectedly.

While sharing Braithwaite’s opinion that power and freedom are not necessarily correlated, one of commentators, Daniel, argues that power of a language does not depend on rules it imposes on programmers but on “computer language "theorems" it provides: 

A computer language is not akin to rules, but akin to mathematics. […] So, compare it to algebra. The more theorems you have, the more powerful you are. Are theorems freedom? Not, of course not. Theorems are fundamental truths that can be combined to more easily achieve further results.

According to Daniel, what makes the difference between languages is to which extent theorems they provide are constructs that are easy for human minds to deal with: 

For instance, in machine code there is no "for" loop as most of us would understand them. What you have are conditional jumps based on CPU flags. 

But from that we developed a very useful construct, which is the "for" loop.
Now, even though the "for" loop is a very powerful construct, it is often prone to misuse. Few people can really truly simulate in their minds a "for" loop, so errors in that construct are not uncommon. 

Now, a "foreach" (list iterator or mapper) construct might not be as flexible as a "for" construct, but it is easier for us to understand.

Daniel advocates for using such easy to understand constructs because this limits the risk of misusing them and makes a language more “prone to correct programs”. Even though these constructs can be “powerful and easy to use at the same time”, this is not always the case and some “theorems” prone to be misused are actually more powerful. Hence, not only is there no direct correlation between freedom and power, but one may need to renounce to some power in the name of code quality.  

In spite of underlying conceptual difference, these two approaches don’t oppose each other. Based on arguments of both Reg and Daniel, one could argue that to be genuinely powerful, a language needs to have a carefully conceived design that guarantees the coherence of different features and to offer constructs that make sense for humans in order to limit the risk of misuse and to rise the quality of code.

So what, exactly, is "power"? by Bruce Rennie Posted
Re: So what, exactly, is by Sadek Drobi Posted
  1. Back to top

    So what, exactly, is "power"?

    by Bruce Rennie

    So, what does "power" in a programming language mean to you? How about "freedom"?

    I suspect that I'll get quite a few different answers to those questions. Hence the never-ending language wars.

    Someone write me a language that creates what I want, dammit!

  2. Back to top

    Re: So what, exactly, is

    by Sadek Drobi

    Power in a programming language IMO is its ability to express a given problem in an abstract, safe, concise and effecient way. The meaning of power here is itself abstract and obviously relative. I guess the language we need is there, we just need to find and adopt it :)

Educational Content

Jesper Boeg on Priming Kanban

In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.