Weblogs Forum - The Myth of Paradigms and TMTOWTDI

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
The Myth of Paradigms and TMTOWTDI

62 replies on 5 pages. Most recent reply: Jan 16, 2019 7:57 PM by Henna Smith

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 62 replies on 5 pages [ 1 2 3 4 5 | » ]

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

The Myth of Paradigms and TMTOWTDI (View in Weblogs)

Posted: Sep 12, 2006 9:29 AM

Summary
Are there really separate programming paradigms? I don't believe so.

There are two big schisms in the programming community: one along dynamic versus static type checking and another along functional and procedural programming styles. I believe that there is no real difference between these so-called paradigms, and they are just different, but limited ways, at looking at the complete space of programming problems.

No single approach is sufficient.

The big reason for the functional/procedural schism is the fact that computers are in fact machines that do separate yet very important things:

perform actions
perform computations

The other split, dynamic vs static typing, is also artificial. Static typing is undeniably useful for verifying a program's correctness and for improving speed, while dynamic typing is very useful for writing and modifying code quickly and writing programs which are adaptable.

This leads to a separate but intriguing question: why aren't true multi-paradigm languages like Scala and OCaml more popular? I propose that the fundamental problem of being a multi-paradigm language is that there is no clear correct way to do things. They suffer from the challenges of TMTOWTDI (There's More Than One Way To Do It). This may remind you of another reasonably succesful language, Perl, which suffers from severe marginalization. It is a truly multi-paradigm language, which is only used in a specific niche.

What I dislike about TMTOWTDI is the difficulty it brings to mastering a language. If you code intelligently, yet naively, in any of these languages and share it with the communities, you are conforonted with waves of criticism for not following large sets of unwritten rules about how to do things correctly.

The fundamental problem with multi-paradigm languages is that there is often an agreed upon best way to do certain things based on flexibility and performance, which isn't often written down. Why should a language even provide a programmer with alternatives if they aren't good? It just confuses them, and is more likely lead to poorly written code.

Well then what's the answer? These issues seem to be add odds with each other. I don't know the answer. Perhaps mixed language code? Perhaps some unwritten language could unify everything elegantly.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: The Myth of Paradigms and TMTOWTDI

Posted: Sep 12, 2006 10:24 AM

By the following definition of paradigm, there are different paradigms but they can overlap.

Definition of paradigm (from dictionary.com): A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality for the community that shares them, especially in an intellectual discipline.

OO developers see functional constructs in a different way than say Haskell programmers. Having a different paradigm doesn't mean that they don't use them.

Andrew Chase

Posts: 5
Nickname: acechase
Registered: Jul, 2003

Re: The Myth of Paradigms and TMTOWTDI

Posted: Sep 12, 2006 11:28 AM

> What I dislike about TMTOWTDI is the difficulty it brings
> to mastering a language. If you code intelligently, yet
> naively, in any of these languages and share it with the
> communities, you are conforonted with waves of criticism
> for not following large sets of unwritten rules about how
> to do things correctly.

I would say that while annoying, this should not be a significant issue on the whole. I think with all languages there's a two-step learning curve: becoming comfortable with the syntax and semantics; becoming familiar with the best practices of the language. The classic refrain that "any good programmer can learn a new language in a week" applies only to the first step. Regardless of whether a language is procedural, functional, or whatever, it's always going to take a while before you can move past "naive" coding.

> The fundamental problem with multi-paradigm languages is
> that there is often an agreed upon best way to do certain
> things based on flexibility and performance, which isn't
> often written down. Why should a language even provide a
> programmer with alternatives if they aren't good? It just
> confuses them, and is more likely lead to poorly written
> code.

Based on my argument above, I would disagree with your conclusion that the fundamental problem is related to TMTOWTDI. Why should a language provide alternatives? Because in different situations, the best alternative often varies. When I write perl by hand, for instance, I implement my solutions differently than if I am auto-generating the code. Just from personal experience, I would argue that multi-paradigm languages are more difficult because they cover a greater range of functionality, there's simply more to the language that requires learning.

I'm leaving a lot of loose ends here, but I don't know how to wrap things up without going on forever :). Personally, I like to use the best language for the job and I don't mind if that language is different from task to task. I don't see this changing.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Multi-paradigm

Posted: Sep 12, 2006 11:32 AM

/* Why should a language even provide a programmer with alternatives if they aren't good?
*/

Because that's the best answer.

Consider, language A does not offer alternatives. It's OOP or nothing. Want to open a file, you have to do it the OOP way, not the data-oriented way, not the entity-relationship way, and definitely not the proceedural way. Want to iterate through a list, it's OOP too, not the for-loop way, not any conceptually simultaneous way, not anything but OOP.

Langauge B offers multiple paradigms, but restricts when they can be used. Sure, you can use functional programming, but only in number-crunching code, not in input/output code, and not as a glue between other paradigms. And you can use OOP, but only in cases that have been judged by a committee to be a good fit for OOP.

And language C offers multiple paradigms, and guidance, but doesn't get in your way. Want to shoot yourself in the foot? This language won't stop you. Don't want to shoot yourself in the foot? Well, this language still own't stop you.

Is there a good answer? Not that I can see.

Keith Gaughan

Posts: 17
Nickname: kgaughan
Registered: Feb, 2003

Re: The Myth of Paradigms and TMTOWTDI

Posted: Sep 12, 2006 12:36 PM

I'm not sure I'd classify dynamic and static typing as programming paradigms. A few years back, Chris Pressey did a good write-up on various proper programming paradigms. Unfortunately, the original's no longer online, but here's a cache: http://tinyurl.com/godnr

Dalius Dobravolskas

Posts: 1
Nickname: dado1945
Registered: Sep, 2006

Re: The Myth of Paradigms and TMTOWTDI

Posted: Sep 12, 2006 12:37 PM

> Well then what's the answer?
PyPy (http://en.wikipedia.org/wiki/PyPy) if/when it will be completed. Python solves half of the problem by being simple and useful (problems you want to solve).

but for now answer is: 42 (http://en.wikipedia.org/wiki/The_Answer_to_Life,_the_Universe,_and_Everything)

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Paradigm or Style?

Posted: Sep 12, 2006 1:34 PM

iirc (which in this case is doubtful) when people started talking about programming paradigms they were using paradigm in a more specific and stronger sense than the dictionary definition - they were riffing on Kuhnian paradigm shifts to suggest that the existing programming paradigm would be over-turned and replaced by a new paradigm.

"The Structure of Scientific Revolutions"
http://www.des.emory.edu/mfp/Kuhn.html

In that sense, multi-paradigm is a contradiction in terms.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Paradigm or Style?

Posted: Sep 12, 2006 1:50 PM

OK, I'll say style from now on. I picked up multi-paradigm from Stroustrup's various books, where he constantly reminds the world that C++ is multi-paradigm, a better C, ...

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

functional/procedural schism

Posted: Sep 12, 2006 1:54 PM

Consider that when you want certain kinds of computations performed, functional programming is often the correct way to do things. When you want to write a controller for an assembly line robot then then procedural programming is usually the best approach.

Huh?

"The authors noticed that through a judicious use of matrix and vector manipulation, a functional language can deal with the problem almost as efficiently as procedural languages like C or Oberon. Besides this, the possibility of reasoning about algorithms, in order to prove that the programs are correct, gives Clean and Haskell a clear advantage over languages like C and Oberon."

A.B. SOARES et al., "FUNCTIONAL LANGUAGES IN SIGNAL PROCESSING APPLIED TO PROSTHETIC LIMB CONTROL", SAMS, 2002, Vol. 42, pp. 1377–1389, Taylor & Francis

What's the difference between
- perform actions
- perform computations
when the world is a value in the program?

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: The Myth of Paradigms and TMTOWTDI

Posted: Sep 12, 2006 2:10 PM

… except there is really no true multi-paradigm language out there. Perl does not support static typing. Ocaml and Scala do not support dynamic typing. I think Strongtalk http://www.strongtalk.org/ supports both (but is beta). What about imperative, OO, dataflow, constraint based and relational programming? And all the libraries, do you implement them five times, once for each paradigm? Is it possible to implement all that in a lifetime?

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

C++ is multi-paradigm ?

Posted: Sep 12, 2006 2:13 PM

This leads to a separate but intriguing question: why aren't true multi-paradigm languages like Scala and OCaml more popular? I propose that the fundamental problem of being a multi-paradigm language is that there is no clear correct way to do things.
I'm not qualified to discuss C++, but I have heard (even before Max mentioned it) that C++ is multi-paradigm - and that should suggest that there are other reasons for Scala and OCaml not being more popular.

If you code intelligently, yet naively, in any of these languages and share it with the communities, you are conforonted with waves of criticism for not following large sets of unwritten rules about how to do things correctly.
Was that your experience? With which language?

The fundamental problem with multi-paradigm languages is that there is often an agreed upon best way to do certain things based on flexibility and performance, which isn't often written down.
In my experience that is the fundamental problem with programming languages, period. That's part of what learning a programming language means.

-snip-
Well then what's the answer? These issues seem to be add odds with each other. I don't know the answer. Perhaps mixed language code? Perhaps some unwritten language could unify everything elegantly.
Which "multi-paradigm" languages have you used?

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: The Myth of Paradigms and TMTOWTDI

Posted: Sep 12, 2006 2:15 PM

What about imperative, OO, dataflow, constraint based and relational programming?
"Oz unifies into one simple and coherent framework the functional, object-oriented, and logic flavors of programming."
http://www.mozart-oz.org/features.html

Jesse Williamson

Posts: 9
Nickname: chardan
Registered: Dec, 2005

Re: The Myth of Paradigms and TMTOWTDI

Posted: Sep 12, 2006 2:53 PM

It's been mentioned already, but I'll highlight it again: new techniques are discovered when you aren't sure what the best way to do it is going to be. What if you've guessed wrong?

Not to get off-topic, but one thing that has long suprised me is that I don't know of a "real" language that at least has implementations of most "classical" algorithms and data structures built into its library.

If your language can express those well, it's probably doing a very good job at at least something... but sometimes the implementation techniques aren't known when the language was developed. C++ is an excellent example of this, and you could even argue for Perl.

While do that often not having a "good way to do it" being well documented is a problem, I find that I usually ultimately prefer flexibility when it also gives me that elusive quality of "expressiveness".

The lack of it is one reason I personally don't enjoy programming in Java very much.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: functional/procedural schism

Posted: Sep 12, 2006 4:02 PM

/* [Diggins] Consider that when you want certain kinds of computations performed, functional programming is often the correct way to do things. When you want to write a controller for an assembly line robot then then procedural programming is usually the best approach.

[Guouy] Huh?
*/

I don't like to put words in Diggins's mouth, but I believe the idea here is that you can usually get better control of timing in a procedural language. Sometimes a "helpful" language (regardless of programming style, functional, procedural, OOP, etc.) will cache values, or the garbage collector will decide to run, or something. That means a computation will run in 5 microseconds one time, 2 microseconds the next (because of a cached value) and 15 the next (because of the garbage collector).

Assembly line robots often need to be hard real-time, so this kind of uncertainty is a bad thing. So these kinds of niceties are usually prohibited somehow.

On top of that, if I tell a functional language to compute value, but don't say what steps to use, I will end up with the correct value (and if I got rid of caching and garbage collection, etc., it will take the same amount of time every time to get that value). However, if it takes three microseconds too long to get that value, how can I optimize things in a functional language to shave off that time?

In a procedural language I'm supposed to have control over what steps are taken, and if I need to shave off time I have a little more control of possible optimizations (I can find out, for instance, exactly how many functions will be called, and I can potentially get rid of the overhead associated with calling functions if necessary [the L4 microkernel is famous for using message passing that is actually faster than function calls, so if nothing else I could use whatever L4 uses]).

Leo Lipelis

Posts: 111
Nickname: aeoo
Registered: Apr, 2006

Re: The Myth of Paradigms and TMTOWTDI

Posted: Sep 12, 2006 5:44 PM

Christopher,

"why aren't true multi-paradigm languages like Scala and OCaml more popular?"

I believe the answer is much simpler than it seems. I don't know about Scala, but I don't use OCaml because it has wacky syntax and because it doesn't have rich libraries included with it. In other words, it lacks the "batteries included" aspect of Java and Python. Even with Ruby it is sometimes hard to find a library that's above version 0.2.

When you just want to do some work, the last thing you want is to mess around with unmaintained or poorly maintained bindings.

Also, I wouldn't want to use a language where every assignment looks like this:

a :==:::===!@#$@ 5 when I should just type a = 5

Even a := 5, while semi-acceptable, is too much.

I also don't like typing __self. in Python.

It's really small things like that, plus lack of "batteries included", that stops people like me from using the language.

Ever since Java came out the bar has been raised in terms of what we expect from the language. I want it all to be in the box: GUI, DB access, security, date/calendaring logic, collections, everything. I don't want to be digging around the entire net for these things.

Even Python sucks in this respect. It comes with TKinter for GUI. That's horrible. You have to hunt around for Python bindings for wxWidgets or some such to have a pretty GUI. That's really a big stumbling block. Another question is, how easy it is to use for web programming? Is there mod_ocaml? Is it a huge headache to set up (like setting up rails was a huge headache the last time I tried... sure once it's all setup properly, it's easy to use).

I think it's not the theoretical aspects that stop languages from being adopted, but rather, pragmatical ones, like price (free is best), "batteries included" aspect, easy to read and type syntax, and so on. If after installing OCaml my library hunt was over for 99% of my projects, yea, I'd consider it seriously.

Flat View: This topic has 62 replies on 5 pages [ 1 2 3 4 5 | » ]

Previous Topic

Next Topic