Sorry, but this article starts off with an excellent example of why this is horrible:
val x: String = "hello"
String x = "hello"
The first line reads: "value X is of type String and contains hello"
The second line reads: "String x contains hello"
val and : are fluff and add nothing. Arguments about it being tougher to parse would have some merit if this wasn't all figured out almost 50 years ago.
indeed.
The simpler a string is to use, the more abused it will be. Programmers, forever, have used strings to represent other types, including really complicated types, with machinations of various appending formats; eg: PROJECT-33/3293, where code is built to pull apart the string to get values. This is awful. Strings are not type safe in the loose sense of the word. (Nothing is intrinsically mandating the format, so invariably you will find other code doing PROJECT-33-3293, or PROJECT/32/3293 or whatever.)
This is especially seen as map keys, rather than just using a first class, class. An obviously especially bad form of this is,
String key = storeId + partId;
as you can't differentiate between 12 + 3 and 1 + 23, but the compiler won't tell you this.
Finally, although not particularly important, all this string formatting parsing is far less efficient than just simple bean classes.
> The type interrupts the flow of data from "hello" to x, so one thing that pops into mind is that this is typecasting the value to a string before storing it. Nope.
> Another possibility I instinctively see this as is doing a comparison and assigning the result (either true or false in this case) to x. Nope.
You can write it as
val x = "hello" : String
if you prefer. In fact that's a great advantage of this syntax: any expression can be optionally ascribed with a type. If you write the type first then it becomes too intrusive (and too much like a typecast, which absolutely should be intrusive).
> And human-language wise, colon is "description: explanation"
True enough, but what other syntax would fit in postfix position? In human language we'd probably use commas ("Bob, chef"), but that seems a bit too ambiguous in a programming language.
I wish I could sufficiently express my frustration for this. It's such a common mistake too. If you design a language with a type for text, and your language has a type called "string" oh God please God let those two be the same thing.
There are so many languages in which the type "string" is not the one to use for strings...
Sorry to belabor the point, but this is exactly what parent was saying.
> changing something like
> ("foo",
> "bar",
> "baz")
> to
> ("foo")
> actually breaks the code.
Of course it breaks the code because the first thing is a tuple and the second is a string. He's implying that the second thing shouldn't be a string. I'm saying that's nuts.
If the language explicitly says how strings are defined, libraries that go "Eh, I'll just shove nonsense bytes in this data structure and claim that's a string" are broken by definition.
That's just as true in Java as in Rust. The problem is languages like C++ or D which just don't care and have a "string" type that might just be some bytes.
Agreed, specifically it creates ambiguities in parsing (for computers but worse: for humans). Given Foo(x), you can’t tell if it’s a function call or a generic type without knowing what x refers to. You need context from afar to disambiguate.
I'd argue that a mutable by-value string type is not suited to most applications, hence why many other languages have avoided providing that style of string type as their core string type.
Is it, though? I think real cases might frequently be less complicated, in Java at least. As is evident from the candidate experiences that the original commenter describes, there's a lot more complexity in strings than is immediately obvious.
I agree with 'Gunax that that's likely to be tripping people up - as I mentioned in the comment to which you're replying, albeit in a somewhat recent edit, this has not nothing to do with why our own similar interview problems don't revolve around any operation on strings.
To me this just looks like they're arguing for using class types rather than raw strings. The parsing seems kind of orthogonal and a special case of the kinds of validation you might want to do.
It's also misleading in that the code is still doing validation, just in a different place.
> being able to pass a list and get an integer in return, makes it very easy to reason about what you can do with these values
I disagree; to paraphrase Ian Malcolm: what you can do with these values is less important than what you should do with these values. For example, we can add a distance to a currency, if they're both int or float; that doesn't mean we should.
The most obvious example of this is "stringly-typed programming", where pretty much everything is "string". Can I append a user-input string to an SQL statement string? Sure; but I shouldn't. Can I append a UserInput to an SQLStatement? Not without conversion (i.e. escaping)!
So much this. Strings can contain anything… json, JavaScript, invalid utf8, you name it! I’ve seen type systems (poorly) re-implemented in already typed languages around string usage.
Fair points. We can see similar examples in other languages, e.g. C++ strings are "like C++" and a pain to use, while Java strings are "not like Java" and a pleasure to use. Maybe language design really isn't about general-purpose elegance, but about finding good special-purpose solutions.
Why are you guys stuck on 's' definitely being a string? It could just as easily be a struct or anything else imaginable, in which case, you're back to not knowing anything about it from the name 's' without going to look it up.
You can contrive simple examples about basic data types all you want, the simple cases and built in types are precisely where it's not a problem. Go read the src for Go's Unicode package as an example, you get 60 line methods with stuff like 't1' used all over the place and the value of t1 is assigned pages away from where it's actually used.
imagine thinking the difference between parsing a string and using a pre-parsed datastructure was "trivial for everyone" because you could count off how many classes of character were involved
one major difference is that you don't have to write the parser at all the other way
The second line reads: "String x contains hello"
val and : are fluff and add nothing. Arguments about it being tougher to parse would have some merit if this wasn't all figured out almost 50 years ago.
reply