Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 really trendy. Hope it will change soon.

[1] http://en.wikipedia.org/wiki/Language-oriented_programming

[2] For programming languages I would rather speak of readability (as opposed to analyzability) because a program is often not written in stone but "alive" (it's modified, enhanced over time...). It probably does not apply to the other fields discussed in the article though.



This trade-off is also why I love Lisp. Although you can easily write something totally incomprehensible, people well versed in Lisp manage to be very expressive with a very powerful language. Of course lisp macros are the key.

It's extremely easy to do LOP with Lisp thanks to s-expressions (all those parenthesis :). But you can be much more expressive with LOP.

EDIT: elaborating


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.


Also relevant is D. Knuth's literate programming.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: