News for hackers. Stuff that matters.
Re:Why it’s hard for programmers to write a program to flatt... by dragonwriter on Friday February 24, 2017 @12:40PM (#13725747)
> One of the problems is that for Java the task is underspecified: Flatten a list of what? Sure this one is integers, is that always the case or should the list take <object>?

Well, I don't Java much, but I think that even if the result List is just integers, the source list has to be (invalid syntax) List<Integer | List<Integer>>, which is somewhat problematic to type as anything but List<Object> given Java's lack of sum types.

Re:Why it’s hard for programmers to write a program to flatt... by bushin on Friday February 24, 2017 @01:02PM (#13725950)
More precisely List<Integer | List<Integer | List <Integer | List<Integer | ...> :) That would be trivial in functional languages.
Re:Why it’s hard for programmers to write a program to flatt... by dragonwriter on Friday February 24, 2017 @02:00PM (#13726554)
It would be trivial in languages with sum types and support for recursive signatures/constructors, which doesn't describe all statically-types functional languages. And there's no reason such a language would have to be functional, though most are.
Re:Why it’s hard for programmers to write a program to flatt... by dllthomas on Friday February 24, 2017 @02:32PM (#13726898)
Interfaces are (open) sum types. Or close enough for government work.
Re:Why it’s hard for programmers to write a program to flatt... by dragonwriter on Friday February 24, 2017 @02:39PM (#13726985)
Yes, but Java (unless I missed a recent change) doesn't let you assign new interfaces to existing types, so short of either wrapping Lists and Ints in containers implementing a common interface and demanding that the input be in the wrapped form, that doesn't actually help.
Re:Why it’s hard for programmers to write a program to flatt... by dllthomas on Friday February 24, 2017 @02:48PM (#13727090)
Faced with this problem, I would precisely wrap Lists and Ints in containers implementing a common interface and demand that the input be in that form (actually, the input is text right? so I'd parse it into that form - assuming I couldn't get away with just manipulating the textual representation).

Note that in the genuine sum-type case you're wrapping, too.