371–379 of 379 posts
Earlier quoted context omitted.
White space is bad for readability anyways. I don't think that would be doable.
> White space is bad for readability anyways. Question{Which|of|these|sentences|is|easier|to|read;This|one?} Or this one in the next line?
As someone who strongly dislikes complicated languages, it's obvious to me that it's a matter of personal preference; personal aesthetics, if you like. If the choice is between complexity in the language and elsewhere, often I'd rather it be elsewhere. But while that preference is entirely subjective, what isn't subjective is the distribution of that preference among programmers. I think that we can say with as much…
Funny to see this > As someone who strongly dislikes complicated languages while > Working on OpenJDK at Oracle as if Java was uncomplicated…
Earlier quoted context omitted.
Flexibility usually has a cost. It's not better or worse.
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 ma…
Earlier quoted context omitted.
> Classes are not just unnecessary, they're a bad abstraction. And yet, there are approximately 0 examples of the "closure-backed classes" example you give, while every vaguely popular language except C has some variant of polymorphic classes, from StandardML to Lisp. Your closure example is not used in any langauge because it's extremely un-ergonomic. If the langauge doesn't have some kind of concept of "interface"…
Using C, which doesn't even have closures, as an example of why this doesn't work is rather silly. How can you have closure-based classes without closures? The ergonomics are beyond horrific in this case but I don't see how that's relevant. > And yet, there are approximately 0 examples of the "closure-backed classes" example you give, while every vaguely popular language except C has some variant of polymorphic class…
Oh, good. That sugar actually already exists in most OO languages, and usually it's called...
class
The problem of getting sweet ergonomic syntax for the concepts of encapsulation, polymorphism, possibly inheritance (with additional sub-divisions mainly on whether multiple- or single-ancestor), interface, abstract class, type class, trait, structural typing, etc, etc. Currently implemented in varying combinations and to varying degrees in different languages.
So make up your mind: Do you have something against syntactical sugar for all those, or don't you?
Earlier quoted context omitted.
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 th…
> 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…
class DogSoundFile
constructor Create(MP3File, Weight);
...
Earlier quoted context omitted.
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 ma…
So would this argument not apply to the use of Templates in C++? Everyone can design their own--what is to keep these from slopping all over the landscape?
Yes, AFAICS arguably it would.
> Everyone can design their own--what is to keep these from slopping all over the landscape?
Who says there is anything to do that?
Earlier quoted context omitted.
So would this argument not apply to the use of Templates in C++? Everyone can design their own--what is to keep these from slopping all over the landscape?
> So would this argument not apply to the use of Templates in C++? Yes, AFAICS arguably it would. > Everyone can design their own--what is to keep these from slopping all over the landscape? Who says there is anything to do that?
> you are unlikely to do it compatibly with what anybody else does
Earlier quoted context omitted.
> So would this argument not apply to the use of Templates in C++? Yes, AFAICS arguably it would. > Everyone can design their own--what is to keep these from slopping all over the landscape? Who says there is anything to do that?
I was referring to > you are unlikely to do it compatibly with what anybody else does
Earlier quoted context omitted.
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 th…
> 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…
But almost every time you actually won't ship a program that just prints stuff to the console
That's why I did it that way, because how you actually output won't be println, but probably to a window or a socket, or whatever
The core functionality of passing a slice will be actually useful in those cases, you can include this code in your final program