3 ms·

That's another thing: "high-meta" languages allow individual developers to re-invent the flow-control wheel in their own image (personal preferences). Consisten

by tabtab 8y ago

That's another thing: "high-meta" languages allow individual developers to re-invent the flow-control wheel in their own image (personal preferences). Consistency is often more important for team readability than factoring (compact code). One man's "clever" can be another's spaghetti code. What works well for individual projects often doesn't scale to larger and often-changing teams.

chriswarbo 8y ago
That argument can certainly be applied to Lisps, with their extensive macro systems, but that's mostly orthogonal to programming paradigm. Lisps aren't necessarily functional: Common Lisp is highly imperative, and even Scheme is 'the ultimate imperative' https://dspace.mit.edu/handle/1721.1/5790 https://dspace.mit.edu/handle/1721.1/5790 ! As for that `ifThenElse` example, there's nothing "meta" going on at all and there's no fancy control flow: it's just a (very simple) function. Consider a function like: renderPage User page register = page renderPage Guest page register = register Doesn't look like 'clever spaghetti' to me: we branch between 'User' and 'Guest', returning a different one of our arguments for each. Yet this is identical to that 'ifThenElse' function, except for the names (which are irrelevant to the machine). This is what I meant by writing "more meaningful, domain-specific alternatives". Not to "re-invent control flow", but to avoid talking about control flow, and just use functions. Note that we can do pretty much the same in any language, e.g. Python: def ifThenElse(c, x, y): return {True: x, False: y}[c] def renderPage(session, page, register): return {User: page, Guest: register}[session] Nothing "meta" or "re-inventing the flow-control wheel" there; just some functions. Of course, this isn't a great idea in Python since Python is impure and uses eager evaluation. Note that such "meta" "reinvented control structures" appear all over the place in OOP, due to dynamic dispatch, e.g. class User: def renderPage(page, register): return page class Guest: def renderPage(page, register): return register These are the two solutions to the "expression problem": - FP restricts the allowed values but allows new functions to use them. For example, adding an Admin session would be hard (need to rewrite renderPage), but adding a renderAvatar function is easy. - OOP restricts the allowed functions (methods), but allows them to use new values. For example, adding an Admin class would be easy, but adding a renderAvatar method would be hard (need to rewrite User and Guest).
- kbp 8y ago
  > and even Scheme is 'the ultimate imperative' https://dspace.mit.edu/handle/1721.1/5790 https://dspace.mit.edu/handle/1721.1/5790 ! Scheme isn't, lambda is. That paper is about how lexical closures alone are enough to simulate a lot of imperative concepts like assignment, loops, and gotos (they do cheat and use set! in a couple places, but the point of the paper is how much lambda application can do all on its own). Your broader point about Lisps not being particularly functionally oriented is correct, though; they're some of the most unopinionated languages you could imagine.

by tabtab 8y ago

chriswarbo 8y ago

That argument can certainly be applied to Lisps, with their extensive macro systems, but that's mostly orthogonal to programming paradigm. Lisps aren't necessarily functional: Common Lisp is highly imperative, and even Scheme is 'the ultimate imperative' https://dspace.mit.edu/handle/1721.1/5790 https://dspace.mit.edu/handle/1721.1/5790 ! As for that `ifThenElse` example, there's nothing "meta" going on at all and there's no fancy control flow: it's just a (very simple) function. Consider a function like: renderPage User page register = page renderPage Guest page register = register Doesn't look like 'clever spaghetti' to me: we branch between 'User' and 'Guest', returning a different one of our arguments for each. Yet this is identical to that 'ifThenElse' function, except for the names (which are irrelevant to the machine). This is what I meant by writing "more meaningful, domain-specific alternatives". Not to "re-invent control flow", but to avoid talking about control flow, and just use functions. Note that we can do pretty much the same in any language, e.g. Python: def ifThenElse(c, x, y): return {True: x, False: y}[c] def renderPage(session, page, register): return {User: page, Guest: register}[session] Nothing "meta" or "re-inventing the flow-control wheel" there; just some functions. Of course, this isn't a great idea in Python since Python is impure and uses eager evaluation. Note that such "meta" "reinvented control structures" appear all over the place in OOP, due to dynamic dispatch, e.g. class User: def renderPage(page, register): return page class Guest: def renderPage(page, register): return register These are the two solutions to the "expression problem": - FP restricts the allowed values but allows new functions to use them. For example, adding an Admin session would be hard (need to rewrite renderPage), but adding a renderAvatar function is easy. - OOP restricts the allowed functions (methods), but allows them to use new values. For example, adding an Admin class would be easy, but adding a renderAvatar method would be hard (need to rewrite User and Guest).

kbp 8y ago
> and even Scheme is 'the ultimate imperative' https://dspace.mit.edu/handle/1721.1/5790 https://dspace.mit.edu/handle/1721.1/5790 ! Scheme isn't, lambda is. That paper is about how lexical closures alone are enough to simulate a lot of imperative concepts like assignment, loops, and gotos (they do cheat and use set! in a couple places, but the point of the paper is how much lambda application can do all on its own). Your broader point about Lisps not being particularly functionally oriented is correct, though; they're some of the most unopinionated languages you could imagine.