7 ms·

The issue is names. Every darn little thing in Java needs a name. If there is no good name, that's a hint that maybe you don't need a new type. Obligatory Cl

by beders 2y ago

The issue is names. Every darn little thing in Java needs a name. If there is no good name, that's a hint that maybe you don't need a new type. Obligatory Clojure example: (defn full-name [{:keys [first-name last-name]}] (str first-name " " last-name)) This defines a function named `full-name`. The stuff between [] is the argument list. There's a single argument. The argument has no name. Instead it is using destructuring to access keys `:first-name` and `:last-name` of a map passed in (so the type of the unnamed argument is just Map) This function works for anything that has a key `:first-name` and `:last-name`. There's no need to declare a type ObjectWithFirstNameAndLastName. It would be quite silly.

continuational 2y ago
Did you forget to include `middle-name`? There's no way to tell.
Spivak 2y ago
In Python you're describing a Protocol. It's actually super reasonable to have a ObjectWithFirstNameAndLastName noun like this. You don't ever need to construct one but you can use it in the type slot and objects you pass in will be checked to conform. You see all kinds of weird specific types floating around the standard lib like this for type hinting. Duck typing is great, what's even better is documenting when when they need to quack or waddle.
- wesselbindt 2y ago
  I think protocols have two major drawbacks regarding readability and safety. When I have a protocol, I cannot easily find its concrete implementations, so it becomes harder to see what the code is actually doing. As for safety, protocols have no way of distinguishing between class Command: def execute(self) -> None: # some implementation and class Prisoner: def execute(self) -> None: # some other implementation The implementor of the Prisoner class might not want the Prisoner class to be able to be slotted in where the Command class can be slotted in. Your type checker will be of no help here. If you use abstract base classes, your type checker can prevent such mistakes. So when it comes to your own code, the drawbacks of the structural Protocols in comparison the nominal ABCs are pretty big. The pros seem non-existent. The pro, I guess, is that you don't have to type the handful of characters "(Baseclass)" with every concrete implementation. But they do have one major advantage: if you have third party code that you have no control over, and you have some part of this codebase that you want to replace with your own, and there's no convenient way to do something like the adapter pattern, because it's somehow a bit deeply nested then a Protocol is a great solution.
motorest 2y ago
> Every darn little thing in Java needs a name. Don't all types need names, regardless of what language you use? Look at typescript, and how it supports structural typing. They don't seem to have a problem with names. Why do you think Java has that problem when nominal type systems simplify the problem? > There's no need to declare a type ObjectWithFirstNameAndLastName. It would be quite silly. Naming things is hard, but don't criticize typing for a problem caused by your lack of imagination. A basic fallback strategy to name specialized types is to add adjectives. Instead of ObjectWithFirstNameAndLastName you could have NamedObject. You don't need to overthink it, with namespaces and local contexts making sure conflicts don't happen. There are two mindsets: try to work around problems to reach your goals, and try to come up with any problem to find excuses to not reach your goals. Complaining about naming sounds a lot like the second.
- jayd16 2y ago
  C# has anonymous types, for example. Kind of like tuples but you can name the fields.
- noduerme 2y ago
  I think Java culture had something to do with the ridiculously verbose names, but even more so the prevalence of Factory and Singleton paradigms in Java created these issues. Maybe because it was the first OO language that a lot of procedural coders came to in the 90s. Those patterns became sort of escape hatches to avoid reasoning about ownership, inheritance and scope. They're still common patterns for emergencies in a lot of ECMA-whatever languages resembling Java: You need a static generator that doesn't own the thing it instantiated, and sometimes you only need one static object itself... but one reaches for those tools only as a last resort. After thinking through what other ways you could structure your code. The super-long-name thing in Java always felt to me like people trying to write GOTO/GOSUB type procedural programs in an OO language.
  - pjmlp 2y ago
    For whatever reason Java gets the blame for what was already common Smalltalk, C++, Clipper 5, Object Pascal, Actor, Eiffel, Objective-C,....before Oak idea turned into Java. To the point many think the famous patterns book used Java, when it is all about Smalltalk and C++ patterns.
sfvisser 2y ago
Really depends on your intent. Ideally code has meaning that reflects your problem domain and not just what happens to work at the moment. Code that just works right now never scales.
tossandthrow 2y ago
Now when you establish full functional languages, most languages will allow you to do fullName = map list \(firstName, lastName) -> firstName + " " + firstName and type it as `funfullName: (String, String)[] -> String`. I have worked on large scale systems in both types and untyped languages and I cannot emphasize strongly enough how important types are.
- noduerme 2y ago
  The only thing with anonymous functions is, when the boss says "please include every user's middle initial", you need to go find every instance of an inline function that resembles this. Consolidating that function in a getter in a class object called Person or User or Customer is a lot nicer.
  - tossandthrow 2y ago
    This is more a question about architecture. But one thing is certain: When you have that one function that is used 165 times throughout the code base, having a type checker is certainly going to help you when you add in the users middle initial.
    - nottorp 2y ago
      > This is more a question about architecture. In an ideal world :) In the real world the customer doesn't know what they want and you can't fully guess what they want or need ahead of time no matter how many diagrams you draw. Incidentally, one of the few good things that came out of the "agile" religion.
      - tossandthrow 2y ago
        You are completely right! And the exact point I tried to communicate. When you decide to have loose architectural structures, you might allow just writing these types of functions adhoc. The further you go in the project, the more your strengthen the architecture, where needed.
MrBuddyCasino 2y ago
This is easy and idiomatic in Golang with its combination of Interfaces and Duck Typing. Why is it that dynamically typed languages usually develop static typing extensions (including Clojure)? Perhaps people don’t enjoy hunting down tedious spelling issues such as last-name vs family-name?
_kidlike 2y ago
you are just describing a function. Not a type. And as others replied, the issue of naming a type exists in all languages.
kitd 2y ago
This sounds like passing JS objects around and having dependencies between caller and callee on their content being undefined and assumed. I can't think of much worse than that for anything other than a trivial codebase. At least in Javascript you have JSDoc.
nottorp 2y ago
If we're philosophizing here: 1. This (or maybe a less trivial form of this) will bite you in the ass when you end up using other people's unnamed types. Or even when you use your own unnamed types that come from code you haven't touched in three years. 2. That's what interfaces are for in Java. Or at least modern Java.
- ido 2y ago
  I’ve first learned Java in introduction to programming in 2001 and that’s what interfaces were for back then already.
  - Viliam1234 2y ago
    Interface are more fundamental to Java than classes. Sadly, at the beginning, many people came to Java from C/C++, and they did the thing we used to call "writing C/C++ code in Java".
    - nottorp 2y ago
      I'm late to the Java party, I first did anything serious in it in 2009-10 and it was Android not "traditional" Java. So no idea about early Java's history. The interfaces is the only thing i loved from it.
      - Viliam1234 2y ago
        One day I will write a Java project that won't contain a single "class" keyword (it will have interface, anonymous classes, and static methods), as a piece of art.
WhyNotHugo 2y ago
This is my main obstacle when wanting to create a simple data-class for 6 variables that I pass as arguments in a couple of places. I already have ItemReference, ItemStatus, ItemVersion and ItemMetadata, what do I call that new type which has an item's path, version, status, uid and hash?
rockyj 2y ago
Not just names, but a separate file and a package to fit in. I need a small data object, sorry, you have to put it in a separate file and then think of the package it goes in and so on and so forth. Not to mention in Spring you then need to annotate it with something. That is why I say Java development is a pain.
peterashford 2y ago
Meh. OOP has lots of nouns, FP has lots of verbs.

by beders 2y ago

continuational 2y ago

Did you forget to include `middle-name`? There's no way to tell.

Spivak 2y ago

In Python you're describing a Protocol. It's actually super reasonable to have a ObjectWithFirstNameAndLastName noun like this. You don't ever need to construct one but you can use it in the type slot and objects you pass in will be checked to conform. You see all kinds of weird specific types floating around the standard lib like this for type hinting. Duck typing is great, what's even better is documenting when when they need to quack or waddle.

wesselbindt 2y ago
I think protocols have two major drawbacks regarding readability and safety. When I have a protocol, I cannot easily find its concrete implementations, so it becomes harder to see what the code is actually doing. As for safety, protocols have no way of distinguishing between class Command: def execute(self) -> None: # some implementation and class Prisoner: def execute(self) -> None: # some other implementation The implementor of the Prisoner class might not want the Prisoner class to be able to be slotted in where the Command class can be slotted in. Your type checker will be of no help here. If you use abstract base classes, your type checker can prevent such mistakes. So when it comes to your own code, the drawbacks of the structural Protocols in comparison the nominal ABCs are pretty big. The pros seem non-existent. The pro, I guess, is that you don't have to type the handful of characters "(Baseclass)" with every concrete implementation. But they do have one major advantage: if you have third party code that you have no control over, and you have some part of this codebase that you want to replace with your own, and there's no convenient way to do something like the adapter pattern, because it's somehow a bit deeply nested then a Protocol is a great solution.

motorest 2y ago

> Every darn little thing in Java needs a name. Don't all types need names, regardless of what language you use? Look at typescript, and how it supports structural typing. They don't seem to have a problem with names. Why do you think Java has that problem when nominal type systems simplify the problem? > There's no need to declare a type ObjectWithFirstNameAndLastName. It would be quite silly. Naming things is hard, but don't criticize typing for a problem caused by your lack of imagination. A basic fallback strategy to name specialized types is to add adjectives. Instead of ObjectWithFirstNameAndLastName you could have NamedObject. You don't need to overthink it, with namespaces and local contexts making sure conflicts don't happen. There are two mindsets: try to work around problems to reach your goals, and try to come up with any problem to find excuses to not reach your goals. Complaining about naming sounds a lot like the second.

jayd16 2y ago
C# has anonymous types, for example. Kind of like tuples but you can name the fields.
noduerme 2y ago
I think Java culture had something to do with the ridiculously verbose names, but even more so the prevalence of Factory and Singleton paradigms in Java created these issues. Maybe because it was the first OO language that a lot of procedural coders came to in the 90s. Those patterns became sort of escape hatches to avoid reasoning about ownership, inheritance and scope. They're still common patterns for emergencies in a lot of ECMA-whatever languages resembling Java: You need a static generator that doesn't own the thing it instantiated, and sometimes you only need one static object itself... but one reaches for those tools only as a last resort. After thinking through what other ways you could structure your code. The super-long-name thing in Java always felt to me like people trying to write GOTO/GOSUB type procedural programs in an OO language.
- pjmlp 2y ago
  For whatever reason Java gets the blame for what was already common Smalltalk, C++, Clipper 5, Object Pascal, Actor, Eiffel, Objective-C,....before Oak idea turned into Java. To the point many think the famous patterns book used Java, when it is all about Smalltalk and C++ patterns.

sfvisser 2y ago

Really depends on your intent. Ideally code has meaning that reflects your problem domain and not just what happens to work at the moment. Code that just works right now never scales.

tossandthrow 2y ago

Now when you establish full functional languages, most languages will allow you to do fullName = map list \(firstName, lastName) -> firstName + " " + firstName and type it as `funfullName: (String, String)[] -> String`. I have worked on large scale systems in both types and untyped languages and I cannot emphasize strongly enough how important types are.

noduerme 2y ago
The only thing with anonymous functions is, when the boss says "please include every user's middle initial", you need to go find every instance of an inline function that resembles this. Consolidating that function in a getter in a class object called Person or User or Customer is a lot nicer.
- tossandthrow 2y ago
  This is more a question about architecture. But one thing is certain: When you have that one function that is used 165 times throughout the code base, having a type checker is certainly going to help you when you add in the users middle initial.
  - nottorp 2y ago
    > This is more a question about architecture. In an ideal world :) In the real world the customer doesn't know what they want and you can't fully guess what they want or need ahead of time no matter how many diagrams you draw. Incidentally, one of the few good things that came out of the "agile" religion.
    - tossandthrow 2y ago
      You are completely right! And the exact point I tried to communicate. When you decide to have loose architectural structures, you might allow just writing these types of functions adhoc. The further you go in the project, the more your strengthen the architecture, where needed.

MrBuddyCasino 2y ago

This is easy and idiomatic in Golang with its combination of Interfaces and Duck Typing. Why is it that dynamically typed languages usually develop static typing extensions (including Clojure)? Perhaps people don’t enjoy hunting down tedious spelling issues such as last-name vs family-name?

_kidlike 2y ago

you are just describing a function. Not a type. And as others replied, the issue of naming a type exists in all languages.

kitd 2y ago

This sounds like passing JS objects around and having dependencies between caller and callee on their content being undefined and assumed. I can't think of much worse than that for anything other than a trivial codebase. At least in Javascript you have JSDoc.

nottorp 2y ago

If we're philosophizing here: 1. This (or maybe a less trivial form of this) will bite you in the ass when you end up using other people's unnamed types. Or even when you use your own unnamed types that come from code you haven't touched in three years. 2. That's what interfaces are for in Java. Or at least modern Java.

ido 2y ago
I’ve first learned Java in introduction to programming in 2001 and that’s what interfaces were for back then already.
- Viliam1234 2y ago
  Interface are more fundamental to Java than classes. Sadly, at the beginning, many people came to Java from C/C++, and they did the thing we used to call "writing C/C++ code in Java".
  - nottorp 2y ago
    I'm late to the Java party, I first did anything serious in it in 2009-10 and it was Android not "traditional" Java. So no idea about early Java's history. The interfaces is the only thing i loved from it.
    - Viliam1234 2y ago
      One day I will write a Java project that won't contain a single "class" keyword (it will have interface, anonymous classes, and static methods), as a piece of art.

WhyNotHugo 2y ago

This is my main obstacle when wanting to create a simple data-class for 6 variables that I pass as arguments in a couple of places. I already have ItemReference, ItemStatus, ItemVersion and ItemMetadata, what do I call that new type which has an item's path, version, status, uid and hash?

rockyj 2y ago

Not just names, but a separate file and a package to fit in. I need a small data object, sorry, you have to put it in a separate file and then think of the package it goes in and so on and so forth. Not to mention in Spring you then need to annotate it with something. That is why I say Java development is a pain.

peterashford 2y ago

Meh. OOP has lots of nouns, FP has lots of verbs.