8 ms·

Some guy almost 20 years ago argued, that if you end up with a bunch of "design patterns" then your language is not good enough.) http://norvig.com/design-patt

Some guy almost 20 years ago argued, that if you end up with a bunch of "design patterns" then your language is not good enough.) http://norvig.com/design-patterns/design-patterns.pdf http://norvig.com/design-patterns/design-patterns.pdf

deleted 12y ago
[deleted]
jarcane 12y ago
16 of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++ for at least some uses of each pattern Things like this are literally why I switched from Python to Racket almost immediately once I discovered the latter. So much time spent fighting an imperative language to do something that seemed like it should just be easier in the first place.
- taeric 12y ago
  Racket is an imperative language, as well. Right? Don't get me wrong, I love Racket. Just I don't think of it as !imperative. I am also unconvinced that the imperative nature of many languages is the problem. Not sure what it is.
  - dschiptsov 12y ago
    Racket is "mostly functional" which means that very few "impure" data structures (mcons, for example) and operations are marked explicitly (by convention).
    - taeric 12y ago
      That does nothing to talk about imperative versus not, though. Does it? The entire for* and let* class of bindings are imperative, in that the order matters. Same with (begin and friends.
      - dschiptsov 12y ago
        let* is nothing but nested lets, which, in turn, are nested lamdas. (let* ((a 1) (b a)) (+ a b)) is an abbreviation for (let ((a 1)) (let ((b a)) (+ a b)))) which, in turn, is a syntactic sugar for ((lambda (a) ((lambda (b) (+ a b)) a)) 1) There is no "assignment", only lexicaly scooped bindings, which are "stateless" and "declarative". Looping constructs in Racket are just syntactic sugar - layered macros, based on what they call "contracts", I suppose. In CL looping constructs are micro-DSLs.
        taeric 12y ago
        Yeah, I chose a somewhat poor example. My main point was that order matters, you have to do A before B. You can not do them at the same time, or something different happens. (Contrasted with a language like VHDL where everything typically happens at the same time.) Simply put, functional is not necessarily the opposite of imperative. I took to googling to see if someone had made my point better already. The best I found quickly is this[1]. It is a good read. As it points out that we are most likely both stuck on different numbers in the "opposite of imperative" definition world. I will say that throwing out mutability with the bathwater is perhaps the single most frustrating thing with most functional advocacy. [1] https://existentialtype.wordpress.com/2013/07/18/what-if-anything-is-a-declarative-language/ https://existentialtype.wordpress.com/2013/07/18/what-if-any...
      - tel 12y ago
        Imperative requires order but they are not identical. Imperative tends to mean "sequence of instructions which operate on an exterior set of mutable state cells" versus functional which often means "set of expressions which reduce into values". Each can model the other, but let is clearly functional in this model since its meaning derives entirely from a reduction semantics.
        taeric 12y ago
        See my link down thread. I think this really comes down to the murkiness in definitions of declarative and imperative. I did find a later definition that points out that these are no longer duals of each other. I was actively avoiding the obviously imperative functions, though. Not sure why. That is, I could have simply said that the existence of all of the functions that end in exclamation points shows the language is imperative.
  - jarcane 12y ago
    Goodness. My apologies for instigating a terminology war, I should not have been so imprecise. I think tel is mostly on the right track of what I mean when I compare Racket to traditional ALGOL languages, but it is also true to say that Racket is not strictly non-imperative either: it is ultimately a multi-paradigm language, just one that culturally leans harder towards a functional-declarative style. My early projects were just as lousy with mutable state and in-order processing as anything I wrote in Python; but I got better. I think what really drove me to Lisp and FP languages was the notion of nearly everything being first-class values, from functions to objects, and it's this quality, compared to the tedium of building yet another !"¤&¤&! constructor pattern that really attracted me. This, plus things like macros, the way the language allows for function composition so readily, is what made Lisp feel like 'how programming should've been all along' for me. Haskell as well induced that same reaction in other ways (mmm ... curry ...), though I'm still not entirely convinced that such strict purity is practical.
    - taeric 12y ago
      If my subthread sounded at all like an attack against Lisp and Racket, than I humbly apologize. So far, I am loving the language and what can do with it. And I like currying and such, as well. Even use it in Racket quote often. Isn't too uncommon to see something like in my projects. ((compose (curry func1 val1) func2 func3) seed) I think what really makes Racket so amazing to me is just how easy it is to iteratively write a function. Start with a core, and gradually append around it more and more till it is done. Testing with values throughout the whole process. I also like the literature around Lisp. Land of Lisp and SICP are both very well written and just plain fun to read.
      - jarcane 12y ago
        Yes. I find sometimes that programming in Racket and other Lisps is so efficient, that whenever something starts looking tedious, I start reconsidering if there's a more elegant way I'm missing to implement it. Learning it, hacking it, and reading about it (and Scheme and other Lisps as well as Haskell) have done marvelous things for my programming skills. Today I wrote a struct system in 29 lines of code. Kinda hard sometimes to do that and then even think about going back to, well, much of anything but another Lisp or composable FP language, really.
nathan7 12y ago
Most of these slides are about patterns that are provided for as functions by the language, or are otherwise obsoleted by the more powerful abstraction features of FP languages. The writers of this presentation are very much aware of the smell that is patterns.

deleted 12y ago

[deleted]

jarcane 12y ago

16 of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++ for at least some uses of each pattern Things like this are literally why I switched from Python to Racket almost immediately once I discovered the latter. So much time spent fighting an imperative language to do something that seemed like it should just be easier in the first place.

taeric 12y ago
Racket is an imperative language, as well. Right? Don't get me wrong, I love Racket. Just I don't think of it as !imperative. I am also unconvinced that the imperative nature of many languages is the problem. Not sure what it is.
- dschiptsov 12y ago
  Racket is "mostly functional" which means that very few "impure" data structures (mcons, for example) and operations are marked explicitly (by convention).
  - taeric 12y ago
    That does nothing to talk about imperative versus not, though. Does it? The entire for* and let* class of bindings are imperative, in that the order matters. Same with (begin and friends.
    - dschiptsov 12y ago
      let* is nothing but nested lets, which, in turn, are nested lamdas. (let* ((a 1) (b a)) (+ a b)) is an abbreviation for (let ((a 1)) (let ((b a)) (+ a b)))) which, in turn, is a syntactic sugar for ((lambda (a) ((lambda (b) (+ a b)) a)) 1) There is no "assignment", only lexicaly scooped bindings, which are "stateless" and "declarative". Looping constructs in Racket are just syntactic sugar - layered macros, based on what they call "contracts", I suppose. In CL looping constructs are micro-DSLs.
      - taeric 12y ago
        Yeah, I chose a somewhat poor example. My main point was that order matters, you have to do A before B. You can not do them at the same time, or something different happens. (Contrasted with a language like VHDL where everything typically happens at the same time.) Simply put, functional is not necessarily the opposite of imperative. I took to googling to see if someone had made my point better already. The best I found quickly is this[1]. It is a good read. As it points out that we are most likely both stuck on different numbers in the "opposite of imperative" definition world. I will say that throwing out mutability with the bathwater is perhaps the single most frustrating thing with most functional advocacy. [1] https://existentialtype.wordpress.com/2013/07/18/what-if-anything-is-a-declarative-language/ https://existentialtype.wordpress.com/2013/07/18/what-if-any...
    - tel 12y ago
      Imperative requires order but they are not identical. Imperative tends to mean "sequence of instructions which operate on an exterior set of mutable state cells" versus functional which often means "set of expressions which reduce into values". Each can model the other, but let is clearly functional in this model since its meaning derives entirely from a reduction semantics.
      - taeric 12y ago
        See my link down thread. I think this really comes down to the murkiness in definitions of declarative and imperative. I did find a later definition that points out that these are no longer duals of each other. I was actively avoiding the obviously imperative functions, though. Not sure why. That is, I could have simply said that the existence of all of the functions that end in exclamation points shows the language is imperative.
- jarcane 12y ago
  Goodness. My apologies for instigating a terminology war, I should not have been so imprecise. I think tel is mostly on the right track of what I mean when I compare Racket to traditional ALGOL languages, but it is also true to say that Racket is not strictly non-imperative either: it is ultimately a multi-paradigm language, just one that culturally leans harder towards a functional-declarative style. My early projects were just as lousy with mutable state and in-order processing as anything I wrote in Python; but I got better. I think what really drove me to Lisp and FP languages was the notion of nearly everything being first-class values, from functions to objects, and it's this quality, compared to the tedium of building yet another !"¤&¤&! constructor pattern that really attracted me. This, plus things like macros, the way the language allows for function composition so readily, is what made Lisp feel like 'how programming should've been all along' for me. Haskell as well induced that same reaction in other ways (mmm ... curry ...), though I'm still not entirely convinced that such strict purity is practical.
  - taeric 12y ago
    If my subthread sounded at all like an attack against Lisp and Racket, than I humbly apologize. So far, I am loving the language and what can do with it. And I like currying and such, as well. Even use it in Racket quote often. Isn't too uncommon to see something like in my projects. ((compose (curry func1 val1) func2 func3) seed) I think what really makes Racket so amazing to me is just how easy it is to iteratively write a function. Start with a core, and gradually append around it more and more till it is done. Testing with values throughout the whole process. I also like the literature around Lisp. Land of Lisp and SICP are both very well written and just plain fun to read.
    - jarcane 12y ago
      Yes. I find sometimes that programming in Racket and other Lisps is so efficient, that whenever something starts looking tedious, I start reconsidering if there's a more elegant way I'm missing to implement it. Learning it, hacking it, and reading about it (and Scheme and other Lisps as well as Haskell) have done marvelous things for my programming skills. Today I wrote a struct system in 29 lines of code. Kinda hard sometimes to do that and then even think about going back to, well, much of anything but another Lisp or composable FP language, really.

nathan7 12y ago

Most of these slides are about patterns that are provided for as functions by the language, or are otherwise obsoleted by the more powerful abstraction features of FP languages. The writers of this presentation are very much aware of the smell that is patterns.