Interesting! The most important difference between frameworks and libraries seems to be the "don't call me, I'll call you" pattern. Frameworks call your code, while libraries get called by your code.
It's easy to see why "don't call me, I'll call you" leads to unreadable code. A piece of code is readable if you can understand how it works, not just what it does, and a big part of "how it works" is figuring out the control flow. Inverted control flow makes code less readable, regardless of any other benefits it might have.
Viewed in that light, it's hard to see how moving to better languages like Haskell would solve the problem. Functional programmers pass functions around all the time, so a lot of functional "libraries" are actually frameworks that insist on calling your code in complicated ways, making it conform to very precise types required by the framework. There's certainly no shortage of abstraction in Haskell code. As a result, it seems that most Haskell programmers don't even try to understand the control flow of their programs, because it's almost impossible.
I wonder if we could have a principled approach to programming that discourages the "don't call me, I'll call you" pattern, and encourages code that you can simply read from top to bottom. Do this thing, then do that thing, then do the other thing. It would probably be unlike anything that exists in academia today.
Strange, since I started using Django a while ago, I would say it encourages me to keep my own code a lot more organized. Are Java frameworks so much different?
As for functional programming, I only mix bits and pieces here and there. One thing I find quite discouraging about JavaScript, is that (in the code I have been reading) you can define a function within another function, and pass that on to other parts of the program. I have found it really difficult to work out what is going on in the code.
In a basic Python script, define the functions at the top then write something to call them at the bottom. Its easy to see where the code starts and ends - well a whole lot easier than looking for function definitions within other function definitions. It just seems unorganized to me. I know that it is supposed to be a benefit of functional programming that you can do so many things with functions, but I find it makes debugging difficult, especially at the start. Is Haskell better at keeping the code organized? I have never used it.
I really like your work, but not sure that it lies on the right side of the framework/library divide. For example, to realize the full benefits of your approach, you define a new programming language with "no escape hatches". That's the most extreme kind of framework thinking!
> Frameworks hurt sharing. I'd really like to give you this fork Jimmy, but you're gonna need a knife and plate to use it. The framework checks out all your girlfriends for you, the framework won't let anyone dirty get through, the framework will wait up until you get in, the framework will always find out were you've been, the framework keeps you healthy and clean. Frameworks embrace, extend and hold on to greedily.
We are not so much defining frameworks as we are new ways of computing. In that sense, it's not really something that will be ready tomorrow (or ever). I do use glitch as a library in C# for UI and compiler programming (hard to program very interactive UI and compilers otherwise), but that is with lots of escape hatches :)
Yes: for example the x86 MOV instruction is actually a family of instructions. You can see the leakage in the restrictions on which combinations of addressing modes you can use.
code that you can simply read from top to bottom. Do this thing, then do that thing, then do the other thing.
It's called "imperative/procedural programming", and has been around for as long as computers if not longer (in the form of instructions to humans). I think the problem in frameworks is not so much the inverted flow of control as it is the extraneous use thereof --- control flow that bounces around between many functions is difficult to follow in general. It all comes down to the fact that abstractions have a cost and benefit; the important point is when to make the decision to use one in which the benefits outweigh the costs..
+1 for the last sentence.
I get this nice "do this, then do that" understandability feeling when I work with python scripting of cloud services (e.g. AWS with boto). You get all the powerful apis and OOP mechanics boiling down to readable procedural code with helper functions.
There are several examples of simple libraries in Java that makes you realize it is possible to provide solutions to problems without the "culture" that predominates the ecosystem.
For example Simple (http://simple.sourceforge.net) is a great XML serialization framework that does very well what it is supposed to do.
And there are others I haven't used, but you look at the API and think, this is what I want.
I was very impressed with jDBI (http://jdbi.org/) even if we could not use it because of Maven.
Just had a look at jDBI and it doesn't exactly look like a simple library to me. There's a lot of run-time annotation processing.
Have a look at jOOQ if you haven't seen it yet. There is a pre-compilation stage which generates DAO for you and they can then be used with static type guarantees.
That pre-compilation step, though... How does that play with the IDE? I'm looking into various (more) modern ORM/DB-talky-to-things, and checked out jOOQ but was turned off by that pre-compilation step. I like having my errors bright and red when I type.
I also don't like code generation. I'm not closed-minded to it, just don't like it if I can avoid it.
> but was turned off by that pre-compilation step. I like having my errors bright and red when I type.
Too bad. Once you have code generation built in your development process (e.g. combining things with Flyway: http://blog.jooq.org/2014/06/25/flyway-and-jooq-for-unbeatab...), I'm sure you'll get a hang of how things work with jOOQ, and most importantly, you'll get your errors bright and red when you type (or when you build)
> That pre-compilation step, though... How does that play with the IDE?
It doesn't integrate with the IDE and I am not too fond of it either.
But if you want ORM as a library in Java, I don't think there is any other option possible. Java has no meta-programming support, and annotations are going to be processed at run-time which is even worse than pre-compilation.
I don't see any reason it shouldn't be possible to support pre-compilation steps as part of the IDE. Unless you are actively editing the bits that are compiled, it seems like this should work, but I am not an expert on what goes on behind the curtains of IDEs.
The main advantage is when doing something like this is Haskell the code you pass around can't have arbitrary side effects, so you don't actually need to worry so much about where it is called.
Yeah, I agree that having no side effects helps quite a bit. But you still need to understand control flow to reason about time and space complexity, which are a sort of "unavoidable effects".
If "it is almost impossible to understand control flow in Haskell" as you posit, then how are so many people making time and space efficient Haskell libraries?
> As a result, it seems that most Haskell programmers don't even try to understand the control flow of their programs, because it's almost impossible.
The abstractions used in Haskell code almost always use existing and already well understood abstractions such as Monads, Monoids, Functors, and Applicatives. I most certainly have to understand my control flow in Haskell programs and it is not impossible.
> There's certainly no shortage of abstraction in Haskell code.
I've typically found said abstractions to be sound and needed (or at least justified) however.
It's easy to see why "don't call me, I'll call you" leads to unreadable code. A piece of code is readable if you can understand how it works, not just what it does, and a big part of "how it works" is figuring out the control flow. Inverted control flow makes code less readable, regardless of any other benefits it might have.
Viewed in that light, it's hard to see how moving to better languages like Haskell would solve the problem. Functional programmers pass functions around all the time, so a lot of functional "libraries" are actually frameworks that insist on calling your code in complicated ways, making it conform to very precise types required by the framework. There's certainly no shortage of abstraction in Haskell code. As a result, it seems that most Haskell programmers don't even try to understand the control flow of their programs, because it's almost impossible.
I wonder if we could have a principled approach to programming that discourages the "don't call me, I'll call you" pattern, and encourages code that you can simply read from top to bottom. Do this thing, then do that thing, then do the other thing. It would probably be unlike anything that exists in academia today.