5 ms·

def bark(dog_dict): print("WOOF!" if dog_dict["weight_kg"] > 25 else "Woof") rex = {"name": "Rex", "weight_kg": 35} This code is actually better,

by iopq 5y ago

def bark(dog_dict): print("WOOF!" if dog_dict["weight_kg"] > 25 else "Woof") rex = {"name": "Rex", "weight_kg": 35} This code is actually better, but it would even be better with structs and traits https://gist.github.com/rust-play/ceb5a292a22e55e27d56a83253fe74a4 https://gist.github.com/rust-play/ceb5a292a22e55e27d56a83253... We separate the concept of a Dog, the concept of something that barks, and the actual implementation in this case We also don't immediately print it, but just return a slice so you can print it later or pass it to another function It's a bit longer than the class example, but conceptually cleaner because multiple structs can implement the trait, some of them without a weight and of course I'm only going to print things in my main, the interface only returns a slice which can be passed to other functions

ncmncm 5y ago
Missing the point. If you read just a little farther, you get that extra apparatus has a purpose that is opaque to beginners, that just adds confusion.
- iopq 5y ago
  I'm responding to > And so they would have accidentally re-introduced classes, only this time the existence of classes would have been implicit in the code, and their behaviour ad hoc defined, their invariants spread all over the source files, and with no language-level tooling or introspection to help the programmer. Classes would still exist, but as implicit patterns. You don't need to do this with classes, my design is better than the class design because it's more flexible
  - marcos100 5y ago
    Flexibility usually has a cost. It's not better or worse.
    - ncmncm 5y ago
      Correct! When the language provides apparatus to do the thing, everybody doing the thing is incentivized do it the same way, making libraries implicitly compatible. Cobbling things together yourself (which you can always do: these languages are Turing-complete) you are unlikely to do it compatibly with what anybody else does. This might be why Lisp never developed an ecosystem. Everybody can make their own pile of macros to customize the language for their use, with no standard interfaces that can be composed.
      - lispm 5y ago
        Example: GNU Emacs comes bundled with 1.5 million lines of Lisp code. How was that possible, given that Emacs Lisp has macros?
        ncmncm 5y ago
        You have maybe noticed that Emacs is a single program? (OK, two or three, historically.) Emacs Lisp code that doesn't integrate with the rest of Emacs just doesn't work.
        lispm 5y ago
        What I have noticed is that GNU Emacs is an application development platform for various programs. Example: Org mode. 133 k lines of Emacs Lisp code. https://orgmode.org https://orgmode.org Org mode then is also used by other tools. Somehow these 'Lisp macros' seem to integrate, even though they are written in different times (GNU Emacs started in the mid 80s) by many different authors, for different programs on top of GNU Emacs. That GNU Emacs is a program itself is not different from, say, CPython. That's also a program itself, used to run other code. GNU Emacs has 'packages' and an online archive for that. Developers publish libraries (which other use) and whole solutions, like Org mode. That 'Lisp' itself doesn't have an 'eco system' is no surprise, since Lisp is not a single language, but a family of dialects, developed over the last almost 64 years - either similar ones like Autolisp and Emacs Lisp or different ones like Logo and Racket. Thus these dialects tend to have their own eco-systems. Like Java and C each have their own eco-systems.
- cttet 5y ago
  I disagree. It is maybe better for the author or you as a beginner, but not everyone. One needs data to support claims like that.
  - ncmncm 5y ago
    Again, you miss the point. Identically the same person, at different times, is confused by what seems like pointless extra apparatus, and, later, embraces it as solving a problem they have come, after experience, to recognize. "One needs data" is, in this context, nothing better than meaningless bluster.
    - cttet 5y ago
      You can make a general claim like that and sounds true. But I was referring to how your general claim fits to the specific situation. Conversation is mean to have a deliver and receive end, both side can have problems. "you miss the point" kind of push all the responsibility to the listener. But why you have such a strong confidence about your expression?
Zababa 5y ago
> It's a bit longer than the class example, but conceptually cleaner because multiple structs can implement the trait, some of them without a weight Sounds like premature abstraction. Instead of declaring a class, you have declared an interface.
- iopq 5y ago
  There are no classes in Rust, and it's better for it. That's my point, some abstractions like classes are NOT necessary. There were arguments before Rust 1.0 that people will simply try to emulate classes. But nobody actually bothered, because traits provide enough functionality that you don't actually need to have classes to actually write maintainable and understandable programs. I'm attacking the exact point of the article that you need X. Maybe you actually don't need X, and your programs will be better for it.
  - Zababa 5y ago
    > There were arguments before Rust 1.0 that people will simply try to emulate classes. But nobody actually bothered, because traits provide enough functionality that you don't actually need to have classes to actually write maintainable and understandable programs. It's not only traits. Traits (well, traits objects) are used for dynamic dispatch, traits themselves are used as composable interfaces, and structs + impl blocs are used for basic classes. My point was that your example, implementing a trait that may or may not use a weight for barking, is not making the program better. It's making it more complex for no good reason. Here's what your program could be: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ef14838f18c88d6d7de35f96f0d4d189 https://play.rust-lang.org/?version=stable&mode=debug&editio... Adding traits doesn't make the code better. There's only dogs that are barking. You don't even need to have bark() be a method, a plain function will do.
    - CRConrad 5y ago
      > There's only dogs that are barking. class DogSoundFile constructor Create(MP3File, Weight); ... Bit silly, innit? (Are bigger MP3 files heavier...? :-)
jakobnissen 5y ago
That was not the point I was trying to make. What I was trying to make it that the need for encapsulation and abstraction does not go away, and that people will re-invent them if they are taken away. More specifically, I think structs, or something like structs, are inevitable. And methods are also inevitable. Whether it be by OOP-style classes that contain both fields and methods, or in the Julia style where you have structs, and global-scoped functions with struct-specific methods, or in the Rust style you linked to with structs that conforms to a trait, which implements the method is not important for my specific point. All three ways add complexity to the language, but such kind of complexity is unavoidable, because it will show up in the code anyway. Even if you use C, which does not have an explicit connection between structs and functions (i.e. methods), you will just write functions where you document that such and such argument should be a pointer to such and such type.

by iopq 5y ago

ncmncm 5y ago

Missing the point. If you read just a little farther, you get that extra apparatus has a purpose that is opaque to beginners, that just adds confusion.

iopq 5y ago
I'm responding to > And so they would have accidentally re-introduced classes, only this time the existence of classes would have been implicit in the code, and their behaviour ad hoc defined, their invariants spread all over the source files, and with no language-level tooling or introspection to help the programmer. Classes would still exist, but as implicit patterns. You don't need to do this with classes, my design is better than the class design because it's more flexible
- marcos100 5y ago
  Flexibility usually has a cost. It's not better or worse.
  - ncmncm 5y ago
    Correct! When the language provides apparatus to do the thing, everybody doing the thing is incentivized do it the same way, making libraries implicitly compatible. Cobbling things together yourself (which you can always do: these languages are Turing-complete) you are unlikely to do it compatibly with what anybody else does. This might be why Lisp never developed an ecosystem. Everybody can make their own pile of macros to customize the language for their use, with no standard interfaces that can be composed.
    - lispm 5y ago
      Example: GNU Emacs comes bundled with 1.5 million lines of Lisp code. How was that possible, given that Emacs Lisp has macros?
      - ncmncm 5y ago
        You have maybe noticed that Emacs is a single program? (OK, two or three, historically.) Emacs Lisp code that doesn't integrate with the rest of Emacs just doesn't work.
        lispm 5y ago
        What I have noticed is that GNU Emacs is an application development platform for various programs. Example: Org mode. 133 k lines of Emacs Lisp code. https://orgmode.org https://orgmode.org Org mode then is also used by other tools. Somehow these 'Lisp macros' seem to integrate, even though they are written in different times (GNU Emacs started in the mid 80s) by many different authors, for different programs on top of GNU Emacs. That GNU Emacs is a program itself is not different from, say, CPython. That's also a program itself, used to run other code. GNU Emacs has 'packages' and an online archive for that. Developers publish libraries (which other use) and whole solutions, like Org mode. That 'Lisp' itself doesn't have an 'eco system' is no surprise, since Lisp is not a single language, but a family of dialects, developed over the last almost 64 years - either similar ones like Autolisp and Emacs Lisp or different ones like Logo and Racket. Thus these dialects tend to have their own eco-systems. Like Java and C each have their own eco-systems.
cttet 5y ago
I disagree. It is maybe better for the author or you as a beginner, but not everyone. One needs data to support claims like that.
- ncmncm 5y ago
  Again, you miss the point. Identically the same person, at different times, is confused by what seems like pointless extra apparatus, and, later, embraces it as solving a problem they have come, after experience, to recognize. "One needs data" is, in this context, nothing better than meaningless bluster.
  - cttet 5y ago
    You can make a general claim like that and sounds true. But I was referring to how your general claim fits to the specific situation. Conversation is mean to have a deliver and receive end, both side can have problems. "you miss the point" kind of push all the responsibility to the listener. But why you have such a strong confidence about your expression?

Zababa 5y ago

> It's a bit longer than the class example, but conceptually cleaner because multiple structs can implement the trait, some of them without a weight Sounds like premature abstraction. Instead of declaring a class, you have declared an interface.

iopq 5y ago
There are no classes in Rust, and it's better for it. That's my point, some abstractions like classes are NOT necessary. There were arguments before Rust 1.0 that people will simply try to emulate classes. But nobody actually bothered, because traits provide enough functionality that you don't actually need to have classes to actually write maintainable and understandable programs. I'm attacking the exact point of the article that you need X. Maybe you actually don't need X, and your programs will be better for it.
- Zababa 5y ago
  > There were arguments before Rust 1.0 that people will simply try to emulate classes. But nobody actually bothered, because traits provide enough functionality that you don't actually need to have classes to actually write maintainable and understandable programs. It's not only traits. Traits (well, traits objects) are used for dynamic dispatch, traits themselves are used as composable interfaces, and structs + impl blocs are used for basic classes. My point was that your example, implementing a trait that may or may not use a weight for barking, is not making the program better. It's making it more complex for no good reason. Here's what your program could be: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ef14838f18c88d6d7de35f96f0d4d189 https://play.rust-lang.org/?version=stable&mode=debug&editio... Adding traits doesn't make the code better. There's only dogs that are barking. You don't even need to have bark() be a method, a plain function will do.
  - CRConrad 5y ago
    > There's only dogs that are barking. class DogSoundFile constructor Create(MP3File, Weight); ... Bit silly, innit? (Are bigger MP3 files heavier...? :-)

jakobnissen 5y ago

That was not the point I was trying to make. What I was trying to make it that the need for encapsulation and abstraction does not go away, and that people will re-invent them if they are taken away. More specifically, I think structs, or something like structs, are inevitable. And methods are also inevitable. Whether it be by OOP-style classes that contain both fields and methods, or in the Julia style where you have structs, and global-scoped functions with struct-specific methods, or in the Rust style you linked to with structs that conforms to a trait, which implements the method is not important for my specific point. All three ways add complexity to the language, but such kind of complexity is unavoidable, because it will show up in the code anyway. Even if you use C, which does not have an explicit connection between structs and functions (i.e. methods), you will just write functions where you document that such and such argument should be a pointer to such and such type.