The dependency-injected style is great for mitigating side-effects and avoiding hard dependencies in code.
The problem is that it's a poor substitute for currying and composition.
Java Developers
191–200 of 321 posts
Re: Java Developers
#192Earlier quoted context omitted.
> OO like in Haskell Please explain. Are you referring to type classes?
Yes. Type classes is a way of doing polymorphism in Haskell, the central point of OO.
OO is more general than that, it's just a general paradigm for code reuse. Polymorphism is one of many forms of code reuse (allowing functions to accept multiple type signatures). I wouldn't call it the "central point" because polymorphism can be done without OOP, and OOP can be done without polymorphism.
Re: Java Developers
#193Blame the 90s : the Gang of Four design patterns book, UML, et al. If you wrote code that did not abstract enough, such as not using factories, it was jaw-droppingly obvious to your colleagues that you were not good enough. FP and Scala owe the sheer verbosity of Java a lot for their current success :-)
God. UML.
Re: Java Developers
#194Earlier quoted context omitted.
Yes. Type classes is a way of doing polymorphism in Haskell, the central point of OO.
I thought the central point of OOP was to encapsulate functions ("methods") and the data ("objects") they operate on, thereby providing a way to structure code? That's why it's called "Object Oriented Programming" and not "Polymorphism X Y". Wikipedia at least seems to agree with me.
That is only in the case of OOP as introduced by Smalltalk.
For example, OOP with multi-methods, does not imply such encapsulation.
Re: Java Developers
#195Earlier quoted context omitted.
Unless you're writing something very simple, you're going to end up re-inventing portions of a framework in order to do what you need to do anyway. In which case you're going to be wasting time. If you're trying to write a complex web application it isn't a good use of your time to implement templating/declarative views/JSON serializers/etc in a low-level language. It's not laziness - it's efficiency. Low level syste…
You can use libraries instead of frameworks to avoid reimplementing/reinventing functionality.
But good frameworks are essentially collections of commonly needed libraries (to solve whatever problem the framework is concerned with) wrapped in (hopefully thin) unifying API.
Re: Java Developers
#196Earlier quoted context omitted.
Yes. Type classes is a way of doing polymorphism in Haskell, the central point of OO.
I thought the central point of OOP was to encapsulate functions ("methods") and the data ("objects") they operate on, thereby providing a way to structure code? That's why it's called "Object Oriented Programming" and not "Polymorphism X Y". Wikipedia at least seems to agree with me.
I think one problem that people have when they are talking about object oriented (or FP for that matter), is that there isn't a clear definition around what it means. Most developers agree that it is some mix of encapsulation, polymorphism and inheritance.
There is a lot of disagreement about which of those is more important. For me polymorphism is the most important, encapsulation is useful sometimes, and inheritance might be a negative attribute. For you encapsulation.
Re: Java Developers
#197Earlier quoted context omitted.
There is a clear ontology in the above classes, and it's nice to formalize that in the language rather than just keep it informal in a naming convention. I mean, why not have subtypes if you have subtypes?
It seems that you argue for subtyping for the sake of subtyping. Up to you man. Peace.
I don't read it that way.
One way of viewing nouns in English is as a hierarchy. At the top of the hierarchy you have "thing", and as you descend the pyramid you get more and more specific. "What is that thing?" -> "What is that animal?" -> "What is that mammal?" -> "What is that ungulate?", etc.
There are times when it is appropriate to use "animal", and times when it is appropriate to use "ungulate". It depends on context. OO allows you to have the same levels of abstraction, and it can be a powerful tool.
NOW, having said that, there are two problems with this:
1) Not everything is a noun. Sometimes you want to deal with verbs.
2) Realistically, these hierarchies (in Java) tend to become overly-complicated over time. That's what OP is talking about.
There are cases, though, like the aforementioned Throwable, where having a deeply (more than 3 layers deep) nested hierarchy is wholly appropriate.
Re: Java Developers
#198Earlier quoted context omitted.
What's your beef with JavaFX? I've been using it recently and it's a surprisingly well designed and nice UI framework. Parts of it are kind of immature and there are occasional surprising holes in its functionality, but that's because the current generation (after dropping the scripting language) is only a couple of versions old.
Mainly FXML (I hate XAML as well) but it's better than Swing.
How would you prefer to define UI layouts? Some other DSL? A binary format?
Re: Java Developers
#199Earlier quoted context omitted.
Are you really generalising to an entire industry from the build procedure for a build tool? Why are you even building Maven in the first place? My experience with Maven has been: 1) Download and unzip 2) Run it and that's all that was necessary. Meanwhile on the fly dependency resolution is very nice and a feature of most modern platforms.
I think I already mentioned why Linux distros build the entire chain from source: they provide support for it, they need to be able to patch it and they can't take responsibility for binaries built in an unknown environment. However, I don't understand why you mix two things: maven concept and design (which is fine) with what I criticized: a build tool that depends on everything that it intends to build in the first…
So Maven is at fault because they prioritise their own development productivity over ..... Linux distributors?
Why package Maven anyway? You aren't likely to add much value by doing that.
Re: Java Developers
#200Earlier quoted context omitted.
Functional programming has been known and researched for decades. Mostly what happens is the obviously good features filter down into more mainstream languages, hence the new stream extension in Java 8, and the rest (lazy by default?) gets left behind.
The key selling point of functional languages is not lambdas, but immutable state and referential transparency. People read "advantages of functional programming" and think "anonymous functions" and "they're talking about scary Haskell" which is wrong. Although lambdas are a big improvement to Java, they are not helping enough to make the language more functional. Java is built upon mutable state to its very core, an…
You can make immutable objects in Java. The result is quite, quite unpleasant IMHO, but so are many other things in Java. You just create an object that has final fields and a constructor (or a builder if you have a more complex object).
Now, nothing stops that immutable object containing a mutable object of course, but that's up to you ... Guava has immutable collections if you want them.
Better language support for immutability would not go amiss though.