I'm surprised to see that "Windows Powershell" supports more paradigms than Common Lisp :). Oz seems to be the Michael Phelps of programming languages, supporting 8 paradigms out of the box. - Sanjeev Singh

It seems odd to classify "Visual programming language" as a "paradigm". Tinkertoy is a visual programming language that's isomorphic with Common Lisp (alternatively, it can be thought of as a graphical editor for Common Lisp). Does it have a different paradigm from Lisp? - Laurence Gonsalves

Every language is isomorphic with machine code :). I think it's worth including a "visual" paradigm if the visual aspect of the language allows you to express something much easier than in text (e.g. visual spreadsheet cells vs plain BASIC). I don't know enough about Tinkertoy to know if that counts. - Sanjeev Singh

By isomorphic I mean that you can translate between Tinkertoy and Common Lisp in either direction without any real loss of information. (you may lose spacing when translating from Lisp to Tinkertoy) I've seen Tinkertoy described as a visual programming language, and at other times described as a List editor/environment. - Laurence Gonsalves

Anyway, my point is just that whether a programming language is visual or not seems like it's orthogonal to the paradigm(s) of the language. To me, "paradigm" feels like it should be about deep semantics, while "visual" is about surface representation. Compare BNF to "railroad diagrams". They have identical expressive power, but one is textual and one is graphical. - Laurence Gonsalves

I think it is orthogonal in most cases, but in some cases, the visualness provides important usability benefits and in those cases, it should count as a separate paradigm (it sounds like Tinkeytoy wouldn't meet this bar). I see each paradigm as simply an easy way to express a certain kind of computation. I mean, you can do constraint programming in C too, it's just more painful / less usable, but I wouldn't argue that constraint programming is orthogonal. - Sanjeev Singh

I find "reasoning engine paradigms" (constraint programming, logic programming, rule programming, data-flow languages) unhelpful because you can't re-express the capability above the basic language level, so either all users of your system must program in the core language itself, or else they lose the benefit. Constraints are very useful for visual layout, for example, but a constraint language doesn't help you write a window manager or a GUI toolkit unless you're willing to inject code at runtime. - ⓞnor

(It's more useful, I think, to make that reasoning engine a system service or library that anyone can use when they need it.) I think of the other paradigms as defining things you *can't* do, with machine language as the ultimate multi-paradigm language. Functional, OO, or communicating-sequential-process models all basically prevent you from doing some key thing in order to make analysis more tractable. "Multi paradigm languages" let you exchange one straitjacket for another on the fly. - ⓞnor

I agree that visual programming is not a paradigm. It gets confused with other paradigms, especially dataflow and object/relational data definition languages, that are readily visualized. - ⓞnor

How I wish we have some digg/reddit/techmeme only for wikipedia articles - Varun Mahajan

Laurence, Egnor: what do you guys think is the best way to express that some language has a visual component that makes some operations an order of magnitude easier (like spreadsheets)? - Sanjeev Singh

I'm not sure if I understand the question. I'm not denying that being visual potentially enhances the usability of a language. (I'm actually a bit of a VPL fan, actually.) I just wouldn't call "visual" itself a paradigm, any more than I would call "text based" a paradigm. - Laurence Gonsalves

Sanjeev, I'd call it a visual language, or a visualizable language. I would argue that all languages are deeply visual, at least by conventional usage (which matters at least as much as formal syntax): blocks and indentation and formatting are important and necessary to the process of constructing and understanding programs. Conventional math notation, which almost all languages adopt, is highly spatial, and parentheses and braces have the physical appearance of containment. - ⓞnor

LabView, Lotus 1-2-3, Befunge, and Python all use spatial arrangement to represent concepts in very different ways, and they all offer very different means for the programmer to edit the program under development. Calling three of them "visual" and one "textual" seems like it sort of does a disservice to all of them, or to whatever discussion we're trying to have about paradigms. - ⓞnor

Lotus 1-2-3 and Befunge both use alpha-numeric characters, and Befunge programs are text files. Are they "visual"? (Is that question even interesting other than as a definitional exercise?) - ⓞnor

I think there are two parts to the definition of a paradigm: (1) whether it provides some descriptive power (if I tell you a language is functional, how much can you infer about it?) (2) is it really a different enough way of thinking about a problem. I agree that "visual" falls down on (1), but rather than simply excluding it completely from a discussion of paradigm, it needs to somehow be included because it often qualifies under (2). - Sanjeev Singh

For example, given the exact same problem, the Lotus 1-2-3 user probably thinks about and models the solution very differently from the python user (even if they are the same person). So here is the crux of the issue. If you take (1) as the definition of paradigm, then yes, visual is not a paradigm. If you take (2), then it definitely qualifies under some circumstances, though perhaps there is some better terminology that can be used in these cases. - Sanjeev Singh

Perhaps we can call visual programming a "paradigm group". Mostly I would call it as the family of paradigms where programs are *not* expressed as a prose-like stream of text tokens. - ⓞnor