5 ms·

> 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 struc

> 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.
  - motorest 2y ago
    > For whatever reason Java gets the blame for what was already common (...) Java's problem is that it's hugely successful, and to some it's the only language they ever experience in their formative years. Thus, because poor workmen always blames the tools, Java becomes the root of all evil.
    - pjmlp 2y ago
      That and the historical illiteracy the industry suffers from.
- re-thc 2y ago
  > I think Java culture had something to do with the ridiculously verbose names People complain about this all the time but I'd rather take a verbose name than not knowing what is going on. Sometimes these naming conventions help. Digging into older poorly named, structured and documented codebases is not fun.
  - noduerme 2y ago
    Definitely. If you have functions that only do one thing and are only called a few other place in the code, then by all means, name them explicitly. And I'd rather see that than a bunch of the same inlined anonymous function. I'm not really knocking the naming patterns as much as the data/logic patterns that required them. Factories are not a good thing. They usually imply that globals need to hold references. Obviously, so do Singletons. Global lifecycles in general are just easy to create and really hard to manage on your own. Good comments are better than good function names.
    - motorest 2y ago
      > Factories are not a good thing. They usually imply that globals need to hold references. No. Your statements are fundamentally wrong at many levels. Factories are tools to instantiate objects of a specific type a certain way. They are constructors that don't suffer from the limitations of constructors. A factory does not impose any requirement on object life cycle.
      - lurking_swe 2y ago
        correct. i chuckle when someone talks so authoritatively on a topic they didn’t try to fully understand in the first place.
      - noduerme 2y ago
        How you use a factory matters. A factory that sits as a static function inside the same class it's creating is one thing. It may just be a nicer interface to instantiate the class than the constructor itself. On the other hand, it may do something with the object it's instantiating before passing it back. Such as putting it into global scope, or tying it to something outside its chain. Factories that sit outside the class file are often prone to all kinds of grotesque later mucking-with that causes the instantiated object to bind to other scope, and never be properly garbage collected. That's what I'm talking about. Build better constructors and you won't usually need factories. If you need factories as an API, build them next to the constructor.
- motorest 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. It sounds like you're confusing things. Factories are a way to instantiate objects of a specific type a certain way. Singletons is just a restriction on how many instances of a type there can be. These are not Java concepts, nor are they relevant to the topic of declaring and naming types.
  - bluGill 2y ago
    They are not Java concepts, but abusing them by using in contexts where they are a bad answer is something Java tends to take to the limit. (I fight the same abuse in C++, and it always seems that Java "best practices" is where the idea came from)
- peterashford 2y ago
  tbf those are features of early Java frameworks (particularly the awful java enterprise crap)
jandrewrogers 2y ago
Anonymous types are a thing in some languages. You also have adjacent concepts like anonymous namespaces in which you can dump types that require a name so that the names don’t leak out of the local context. Sufficiently flexible namespaces do solve most of these problems. Java is kind of perverse though.
- gleenn 2y ago
  Java: Map m = new HashMap() {{ System.out.println("I am a unique subclass of HashMap with a single instance!");}};
gleenn 2y ago
All types don't need names exactly like the Clojure example shows. There is no "type" for the argument, likely it's a map under the hood. And maps with keywords are used broadly across Clojure projects as a method of pass groups of data and no, you don't have to name that arbitrary collection of data. Rich Hickey has an amazing presentation on the silliness of a commonly used Java Web Request library where the vast majority of object types required could have just been little nested maps instead of creating a ton of bespoke like types that make it difficult to assemble and manipulate all the bits. The interface he roasts could be completely discarded an nearly no benefits lost in terms of readability or usability. Hickey is also famous for saying he would rather a few data structures and a 100 little algorithms instead of 10 data structures and 10 algorithms per data structure.
- Capricorn2481 2y ago
  > Hickey is also famous for saying he would rather a few data structures and a 100 little algorithms instead of 10 data structures and 10 algorithms per data structure This is a quote from Alan J. Perlis, not Rich Hickey, and it's certainly not what Rich is famous for.
josephg 2y ago
> Don't all types need names, regardless of what language you use? No. - In very dynamic languages (like javascript), most types arguably don't have names at all. For example, I can make a function to add 2d vectors together. Even though I can use 2d vectors in my program, there doesn't have to be a 2d vector type. (Eg, const vecAdd = (a, b) => ({x: a.x+b.x, y: a.y+b.y}) ). - Most modern languages have tuples. And tuples are usually anonymous. For example, in rust I could pass around 2d vectors by simply using tuples of (f64, f64). I can even give my implicit vector type functions via the trait system. - In typescript you can have whole struct definitions be anonymous if you want to. Eg: const MyComponent(props: {x: number, y: string, ...}) {...}. - There's also lots of types in languages like typescript and rust which are unfortunately impossible to name. For example, if I have this code: #[derive(Eq, PartialEq)] enum Color { Red, Green, Blue } fn foo(c: Color) { if c == Color::Red { return; } // What is the type of 'c' here? } Arguably, c is a Color object. But actually, c must be either Color::Green or Color::Blue. The compiler understands this and uses it in lots of little ways. But unfortunately we can't actually name the restricted type in the program. Rust can do the same thing with integers - even though (weirdly) it has no way to name an integer in a restricted range. For example, in this code the compiler knows that y must be less than 256 - so the if statement is always false, and it skips the if statement entirely: https://rust.godbolt.org/z/3nTrabnYz https://rust.godbolt.org/z/3nTrabnYz But - its impossible to write a function that takes as input an integer that must be within some arbitrary range.
- relaxing 2y ago
  The named integer range thing is interesting. I guess it depends on what you goal is. Could you use asserts? Could you wrap the integer in an object and embed the restriction logic there?
  - whilenot-dev 2y ago
    Doable in TypeScript[0], but I'd wager if that's really necessary. [0]: https://www.typescriptlang.org/play/?#code/C4TwDgpgBAogdgVwLYQE4ENgQDwDkoQAeWcAJgM5SJIBGaANFAIIDGLBxEZl1dqA2gF0oAXihCAfKOZt+AcgA2XAObAAFnOFESFKLgBQUKAH4ZLfrzSDDUAFyxqaTDlyN+AOk+sWjb-KVwqhqCghIA3Pr6oJBQAJJwwABK6IE4AGIcOjzIfIwAKplcupaoUmIwhCwKCKQ48MhOWNh5Eoz1KBhNaRLhkdHQBWLxSSnKOABMAAyMAIyTk+FAA https://www.typescriptlang.org/play/?#code/C4TwDgpgBAogdgVwL... from StackOverflow[1] [1]: https://stackoverflow.com/questions/39494689/is-it-possible-to-restrict-number-to-a-certain-range https://stackoverflow.com/questions/39494689/is-it-possible-...
GrantMoyer 2y ago
The types of closures are unnamable in C++ and Rust; each closure has a unique type that can't be written out. Function types (that is, "function item" types) in Rust are also unnamable.
marcosdumay 2y ago
You kind of answered your question, didn't you? Because the types in typescript don't need names. And the type "object with firstName and lastName" is one such type that doesn't need a name. So: > They don't seem to have a problem with names. Yes. The problem is much smaller there, and mostly caused by programmer cultures that insist on naming everything.
dharmab 2y ago
I frequently use anonymous types in my unit tests in Go. I create a custom type describing the inputs, behaviors and expected outputs of a test case. I create a collection of these cases, and use Go's standard library testing package to run the test cases concurrently scaling to the CPU's available threads. Here's a simple example: https://github.com/dharmab/skyeye/blob/main/pkg/bearings/bearing_test.go https://github.com/dharmab/skyeye/blob/main/pkg/bearings/bea...

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.
- motorest 2y ago
  > For whatever reason Java gets the blame for what was already common (...) Java's problem is that it's hugely successful, and to some it's the only language they ever experience in their formative years. Thus, because poor workmen always blames the tools, Java becomes the root of all evil.
  - pjmlp 2y ago
    That and the historical illiteracy the industry suffers from.
re-thc 2y ago
> I think Java culture had something to do with the ridiculously verbose names People complain about this all the time but I'd rather take a verbose name than not knowing what is going on. Sometimes these naming conventions help. Digging into older poorly named, structured and documented codebases is not fun.
- noduerme 2y ago
  Definitely. If you have functions that only do one thing and are only called a few other place in the code, then by all means, name them explicitly. And I'd rather see that than a bunch of the same inlined anonymous function. I'm not really knocking the naming patterns as much as the data/logic patterns that required them. Factories are not a good thing. They usually imply that globals need to hold references. Obviously, so do Singletons. Global lifecycles in general are just easy to create and really hard to manage on your own. Good comments are better than good function names.
  - motorest 2y ago
    > Factories are not a good thing. They usually imply that globals need to hold references. No. Your statements are fundamentally wrong at many levels. Factories are tools to instantiate objects of a specific type a certain way. They are constructors that don't suffer from the limitations of constructors. A factory does not impose any requirement on object life cycle.
    - lurking_swe 2y ago
      correct. i chuckle when someone talks so authoritatively on a topic they didn’t try to fully understand in the first place.
    - noduerme 2y ago
      How you use a factory matters. A factory that sits as a static function inside the same class it's creating is one thing. It may just be a nicer interface to instantiate the class than the constructor itself. On the other hand, it may do something with the object it's instantiating before passing it back. Such as putting it into global scope, or tying it to something outside its chain. Factories that sit outside the class file are often prone to all kinds of grotesque later mucking-with that causes the instantiated object to bind to other scope, and never be properly garbage collected. That's what I'm talking about. Build better constructors and you won't usually need factories. If you need factories as an API, build them next to the constructor.
motorest 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. It sounds like you're confusing things. Factories are a way to instantiate objects of a specific type a certain way. Singletons is just a restriction on how many instances of a type there can be. These are not Java concepts, nor are they relevant to the topic of declaring and naming types.
- bluGill 2y ago
  They are not Java concepts, but abusing them by using in contexts where they are a bad answer is something Java tends to take to the limit. (I fight the same abuse in C++, and it always seems that Java "best practices" is where the idea came from)
peterashford 2y ago
tbf those are features of early Java frameworks (particularly the awful java enterprise crap)

jandrewrogers 2y ago

Anonymous types are a thing in some languages. You also have adjacent concepts like anonymous namespaces in which you can dump types that require a name so that the names don’t leak out of the local context. Sufficiently flexible namespaces do solve most of these problems. Java is kind of perverse though.

gleenn 2y ago
Java: Map m = new HashMap() {{ System.out.println("I am a unique subclass of HashMap with a single instance!");}};

gleenn 2y ago

All types don't need names exactly like the Clojure example shows. There is no "type" for the argument, likely it's a map under the hood. And maps with keywords are used broadly across Clojure projects as a method of pass groups of data and no, you don't have to name that arbitrary collection of data. Rich Hickey has an amazing presentation on the silliness of a commonly used Java Web Request library where the vast majority of object types required could have just been little nested maps instead of creating a ton of bespoke like types that make it difficult to assemble and manipulate all the bits. The interface he roasts could be completely discarded an nearly no benefits lost in terms of readability or usability. Hickey is also famous for saying he would rather a few data structures and a 100 little algorithms instead of 10 data structures and 10 algorithms per data structure.

Capricorn2481 2y ago
> Hickey is also famous for saying he would rather a few data structures and a 100 little algorithms instead of 10 data structures and 10 algorithms per data structure This is a quote from Alan J. Perlis, not Rich Hickey, and it's certainly not what Rich is famous for.

josephg 2y ago

> Don't all types need names, regardless of what language you use? No. - In very dynamic languages (like javascript), most types arguably don't have names at all. For example, I can make a function to add 2d vectors together. Even though I can use 2d vectors in my program, there doesn't have to be a 2d vector type. (Eg, const vecAdd = (a, b) => ({x: a.x+b.x, y: a.y+b.y}) ). - Most modern languages have tuples. And tuples are usually anonymous. For example, in rust I could pass around 2d vectors by simply using tuples of (f64, f64). I can even give my implicit vector type functions via the trait system. - In typescript you can have whole struct definitions be anonymous if you want to. Eg: const MyComponent(props: {x: number, y: string, ...}) {...}. - There's also lots of types in languages like typescript and rust which are unfortunately impossible to name. For example, if I have this code: #[derive(Eq, PartialEq)] enum Color { Red, Green, Blue } fn foo(c: Color) { if c == Color::Red { return; } // What is the type of 'c' here? } Arguably, c is a Color object. But actually, c must be either Color::Green or Color::Blue. The compiler understands this and uses it in lots of little ways. But unfortunately we can't actually name the restricted type in the program. Rust can do the same thing with integers - even though (weirdly) it has no way to name an integer in a restricted range. For example, in this code the compiler knows that y must be less than 256 - so the if statement is always false, and it skips the if statement entirely: https://rust.godbolt.org/z/3nTrabnYz https://rust.godbolt.org/z/3nTrabnYz But - its impossible to write a function that takes as input an integer that must be within some arbitrary range.

relaxing 2y ago
The named integer range thing is interesting. I guess it depends on what you goal is. Could you use asserts? Could you wrap the integer in an object and embed the restriction logic there?
- whilenot-dev 2y ago
  Doable in TypeScript[0], but I'd wager if that's really necessary. [0]: https://www.typescriptlang.org/play/?#code/C4TwDgpgBAogdgVwLYQE4ENgQDwDkoQAeWcAJgM5SJIBGaANFAIIDGLBxEZl1dqA2gF0oAXihCAfKOZt+AcgA2XAObAAFnOFESFKLgBQUKAH4ZLfrzSDDUAFyxqaTDlyN+AOk+sWjb-KVwqhqCghIA3Pr6oJBQAJJwwABK6IE4AGIcOjzIfIwAKplcupaoUmIwhCwKCKQ48MhOWNh5Eoz1KBhNaRLhkdHQBWLxSSnKOABMAAyMAIyTk+FAA https://www.typescriptlang.org/play/?#code/C4TwDgpgBAogdgVwL... from StackOverflow[1] [1]: https://stackoverflow.com/questions/39494689/is-it-possible-to-restrict-number-to-a-certain-range https://stackoverflow.com/questions/39494689/is-it-possible-...

GrantMoyer 2y ago

The types of closures are unnamable in C++ and Rust; each closure has a unique type that can't be written out. Function types (that is, "function item" types) in Rust are also unnamable.

marcosdumay 2y ago

You kind of answered your question, didn't you? Because the types in typescript don't need names. And the type "object with firstName and lastName" is one such type that doesn't need a name. So: > They don't seem to have a problem with names. Yes. The problem is much smaller there, and mostly caused by programmer cultures that insist on naming everything.

dharmab 2y ago

I frequently use anonymous types in my unit tests in Go. I create a custom type describing the inputs, behaviors and expected outputs of a test case. I create a collection of these cases, and use Go's standard library testing package to run the test cases concurrently scaling to the CPU's available threads. Here's a simple example: https://github.com/dharmab/skyeye/blob/main/pkg/bearings/bearing_test.go https://github.com/dharmab/skyeye/blob/main/pkg/bearings/bea...