Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maximally Powerful, Minimally Useful

blog.higher-order.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Maximally Powerful, Minimally Useful

#21

Post by HackinOut »

wyager wrote: post #19
HackinOut wrote: post #14

For programming languages, a paradigm allowing to be "as expressive as necessary" is LOP[1] (Language Oriented programming). With it you can basically choose your level of expressiveness while you develop your program (with different levels for different parts of your program). The frustrating trade-off between expressiveness and readability[2] is the main reason I love this paradigm. Unfortunately LOP has never been…

Could you not just use an expressive programming language and limit yourself to its more readable components?

Do you have a language in mind?

If you ban (for your whole program) some components then I guess you would loose some expressiveness.

Also I don't know if you can categorize "components" as more or less readable. For some problems a "component" might be highly readable while totally inappropriate for another problem. I see some cases where using more components makes the code more readable.

This is an art of using language features (paradigms etc...) and design patterns that will be the most readable while powerful enough to solve your problem. I love doing it with Lisp or Ruby which are languages with a very modular syntax. But it's time consuming so I'm doing it only for substantial projects I really care about. It's much more efficient to use conventional well established programming style (think RoR for example) and less bug-prone (more secure etc...) because it's well tested by many.

Re: Maximally Powerful, Minimally Useful

#22

Post by HackinOut »

HackinOut wrote: post #14

For programming languages, a paradigm allowing to be "as expressive as necessary" is LOP[1] (Language Oriented programming). With it you can basically choose your level of expressiveness while you develop your program (with different levels for different parts of your program). The frustrating trade-off between expressiveness and readability[2] is the main reason I love this paradigm. Unfortunately LOP has never been…

Also relevant is D. Knuth's literate programming.

Re: Maximally Powerful, Minimally Useful

#23

Post by evincarofautumn »

bunderbunder wrote: post #16
evincarofautumn wrote: post #6

A familiar example is “goto” versus structured programming. “goto” is supremely expressive—conditional jumps are sufficient to express all of the usual structured programming constructs. But sacrificing “goto” enables much more powerful reasoning about programs because it restricts the shape of the control flow graph to common patterns: “while”, “do…while”, “for”. One of the core features of functional programming is…

> rather than “for” loops, it’s often easier to think in terms of the common patterns: “map”, “reduce”, “filter”. It is. My lament there is that, at least in my experience, optimizers haven't caught up in this department. So while I invariably start with the higher-order operations, all too often the profiler subsequently informs me that I need to replace that code with a for loop. I suspect that side effects are the…

> I wish I could work in a language that only allows them in functions that explicitly declare that they want to use them, though.

That’s what Haskell does. The big scary M-word just gives you all the other features you end up wanting from your effect system once you have one. See my explanation here: http://programmers.stackexchange.com/questions/258011/altern...

Re: Maximally Powerful, Minimally Useful

#24

Post by codygman »

bunderbunder wrote: post #16
evincarofautumn wrote: post #6

A familiar example is “goto” versus structured programming. “goto” is supremely expressive—conditional jumps are sufficient to express all of the usual structured programming constructs. But sacrificing “goto” enables much more powerful reasoning about programs because it restricts the shape of the control flow graph to common patterns: “while”, “do…while”, “for”. One of the core features of functional programming is…

> rather than “for” loops, it’s often easier to think in terms of the common patterns: “map”, “reduce”, “filter”. It is. My lament there is that, at least in my experience, optimizers haven't caught up in this department. So while I invariably start with the higher-order operations, all too often the profiler subsequently informs me that I need to replace that code with a for loop. I suspect that side effects are the…

Haskell and steam fusion will turn them into iterative loops for you automatically ;)

Re: Maximally Powerful, Minimally Useful

#25

Post by platz »

danidiaz wrote: post #8

Seems related to the Rule of Least Power: http://en.wikipedia.org/wiki/Rule_of_least_power , http://c2.com/cgi/wiki?PrincipleOfLeastPower

An example (somewhat) from the business world: integrated vs modular. For example, Apple (ios) is integrated and they have complete freedom to design their hardware and software stack from the ground up. This allows them full expressiveness. In contrast, Google (android) is modular, and they integrate/source components from commodity vendors. It's less expressive, perhaps a degraded experience compared to apple, but much more modular.

The interesting bit is that the traditional wisdom in business is "in the end modular approaches to technology always defeat integrated approaches", although how this will play out in Apple's case is hard to predict, because I suppose Apple is kind of special. However if we apply the traditional business wisdom to the software domain here, I wonder the same holds: that the expressive/integrated approach is more powerful initially (where may the modular woudln't be able to get "off the ground"), but over time it looses ground to the constrained/modular approach as the modular benefits are allowed to scale to their full potential.

http://stratechery.com/2013/clayton-christensen-got-wrong/

Re: Maximally Powerful, Minimally Useful

#26

Post by JadeNB »

codygman wrote: post #24
bunderbunder wrote: post #16

Earlier quoted context omitted.

> rather than “for” loops, it’s often easier to think in terms of the common patterns: “map”, “reduce”, “filter”. It is. My lament there is that, at least in my experience, optimizers haven't caught up in this department. So while I invariably start with the higher-order operations, all too often the profiler subsequently informs me that I need to replace that code with a for loop. I suspect that side effects are the…

Haskell and steam fusion will turn them into iterative loops for you automatically ;)

Just in case anyone is confused (I did a double take), I think that you mean stream fusion (http://google.com/search?q=Haskell%2Bstream%20fusion).
Post reply on HN