4 ms·

No comment about OO in general, but I think Java/C# is a damn fine language design, avoiding many problems of newer paradigms. Here's an example: 1) Java: star

No comment about OO in general, but I think Java/C# is a damn fine language design, avoiding many problems of newer paradigms. Here's an example: 1) Java: starts out with one opaque string type, because that's what OO methodology says. Changes the internals when needed. All clients continue to work forever. 2) Haskell: starts out with strings as exposed linked lists of characters, because functional methodology says exposed algebraic types are OK. Sticks with this mistake for many years, then recognizes that opaque would be better and introduces a new type Text. Can't change the old one or make them compatible. Moreover the new type exists in strict and lazy variants, because Haskell methodology says people want that. 3) Rust: starts out with two string types, because the language design suggests both should exist (String and &str). It's not just about strings. The same happens with compilation speed, binary compatibility, etc. "Modern" languages get it wrong and can't fix it, Java 1.0 gets it right and it stays right.

willtim 9y ago
Those are good points, but really not an argument against FP. String could have originally been an abstract data type in Haskell. There are of course disadvantages to the Java string approach, in that there is potentially a lot of code duplication inside the String class. There will also always be some situations that will require you to unpack the string into an array of chars, because a particular method does not exist. There are plenty of things that Java got wrong. Threads and concurrent programming in Java is particularly difficult to get right without expert knowledge. Haskell makes concurrent programming much easier. I've worked with both professionally and feel that Haskell got more things right.
Tarean 9y ago
In the early days haskell favored conceptual elegance heavily above practicality. I'd argue that java strings aren't perfect either, though. You can't seamlessly use the string interface for binary data or char arrays for instance. Also, java has various streaming implementations that all use completely different interfaces so maybe lazy java strings would have been helpful.
thegeomaster 9y ago
The String and &str thing is a common criticism of Rust, but I feel it's a bit shallow when said without context. Maybe it's just me, but it makes sense when you consider Rust's ownership semantics (which are a new idea in language design, so you can't really look at how other languages solved issues arising from them). Basically, when you have the notion of ownership/lifetime in a language, you have to make a distinction between an owned and a borrowed thing. When you pass an owned thing to a function, you give up your ownership of it, and can't use it anymore. When you pass a borrowed thing, you keep the ownership, and the compiler tries to prove that, based on ownership info it has, it lives long enough for the operation to be safe. Just as String and &str are owned-borrowed counterparts, you also have e.g. Vector<u8> and &[u8] (the former is an owned vector, the latter is a read-only, borrowed view into that vector) and many more examples of this dichotomy. I don't see how this could have been solved in Rust without having those two types.
- deleted 9y ago
  [deleted]
imtringued 9y ago
Rust doesn't have two string types. They have one string literal type (str&) and a poorly named string buffer (String).
- cesarb 9y ago
  Actually, Rust has four string types: str/String, CStr/CString, OsStr/OsString, and Path/PathBuf.
  - steveklabnik 9y ago
    Only str is in the language. The others are standard library types. Libraries may introduce more types too. We almost made str a library type but the downsides outweighed the upsides.
tome 9y ago
> functional methodology says exposed algebraic types are OK No, it absolutely doesn't. Functional methodology is absolutely orthogonal to data abstraction.

willtim 9y ago

Those are good points, but really not an argument against FP. String could have originally been an abstract data type in Haskell. There are of course disadvantages to the Java string approach, in that there is potentially a lot of code duplication inside the String class. There will also always be some situations that will require you to unpack the string into an array of chars, because a particular method does not exist. There are plenty of things that Java got wrong. Threads and concurrent programming in Java is particularly difficult to get right without expert knowledge. Haskell makes concurrent programming much easier. I've worked with both professionally and feel that Haskell got more things right.

Tarean 9y ago

In the early days haskell favored conceptual elegance heavily above practicality. I'd argue that java strings aren't perfect either, though. You can't seamlessly use the string interface for binary data or char arrays for instance. Also, java has various streaming implementations that all use completely different interfaces so maybe lazy java strings would have been helpful.

thegeomaster 9y ago

The String and &str thing is a common criticism of Rust, but I feel it's a bit shallow when said without context. Maybe it's just me, but it makes sense when you consider Rust's ownership semantics (which are a new idea in language design, so you can't really look at how other languages solved issues arising from them). Basically, when you have the notion of ownership/lifetime in a language, you have to make a distinction between an owned and a borrowed thing. When you pass an owned thing to a function, you give up your ownership of it, and can't use it anymore. When you pass a borrowed thing, you keep the ownership, and the compiler tries to prove that, based on ownership info it has, it lives long enough for the operation to be safe. Just as String and &str are owned-borrowed counterparts, you also have e.g. Vector<u8> and &[u8] (the former is an owned vector, the latter is a read-only, borrowed view into that vector) and many more examples of this dichotomy. I don't see how this could have been solved in Rust without having those two types.

deleted 9y ago
[deleted]

imtringued 9y ago

Rust doesn't have two string types. They have one string literal type (str&) and a poorly named string buffer (String).

cesarb 9y ago
Actually, Rust has four string types: str/String, CStr/CString, OsStr/OsString, and Path/PathBuf.
- steveklabnik 9y ago
  Only str is in the language. The others are standard library types. Libraries may introduce more types too. We almost made str a library type but the downsides outweighed the upsides.

tome 9y ago

> functional methodology says exposed algebraic types are OK No, it absolutely doesn't. Functional methodology is absolutely orthogonal to data abstraction.