I don't think frameworks are flawed, but platforms and languages.
I mean, just look at the Web. DOM, Web Components, Indexed DB or WebGL could all be considered features of the Web-Platform and they seem all to have awful APIs.
The primary issues that make frameworks flawed
31–40 of 43 posts
Re: The primary issues that make frameworks flawed
#32It's kind of a circular argument here. "Frameworks, which I define as things with these problems, have all these problems." A more insightful article or even series would start with the problems and then focus on how various frameworks and libraries either fall into the trap or transcend it.
Re: The primary issues that make frameworks flawed
#33I think the question that is left unanswered here is - if not frameworks, what should we use? Conceptually, there are only two solutions either: a - write everything from scratch, which I think we all agree will be disastrous. or b - compose tons of libraries together - for a typical webapp, that means connecting your ORM library to your routing library, to your template rendering library, to your authorization libra…
(b) can look like this:
Luminus is a Clojure micro-framework based on a set of lightweight libraries. It aims to provide a robust, scalable, and easy to use platform. With Luminus you can focus on developing your app the way you want ...
Re: The primary issues that make frameworks flawed
#34I think the question that is left unanswered here is - if not frameworks, what should we use? Conceptually, there are only two solutions either: a - write everything from scratch, which I think we all agree will be disastrous. or b - compose tons of libraries together - for a typical webapp, that means connecting your ORM library to your routing library, to your template rendering library, to your authorization libra…
You're overestimating the complexity of (b). Composing libraries is pretty trivial, and in my experience easier than learning to do meaningful work in a framework, and certainly easier than working around framework limitations.
The problems with (b) isn't the composition, which is easy, but the availability of quality libraries. Popular libraries are often written (and re-written, and re-written, and re-written) as plug-ins for specific frameworks. For example, it used to be hard to find a JavaScript drag-and-drop library that worked independently of JQuery.
That said, I'll take that pain over the pain of a framework. When you get to the interesting bits of an application, it's so much easier to evolve my own design than to work around framework design decisions.
Re: The primary issues that make frameworks flawed
#35I do wonder if some issures (especially about composability) are actually caused a layer deeper, in the programming languages.
For example, java has some very peculiar ideas about typing and metaprogramming that encourage a "plugin" approach an tie your codeto 3rd party libs stronger than would be necessary.
Some examples:
- Classes that implement an interface now have it as a dependency: If the interface class is not present, your class won't compile. This even though the interface class usually doesn't contain any additional information (exception being "extends" clauses)
- the same is even true for annotations - even if those annotations don't even end up in the compiled class at all.
- the language itself offers an extensive range of tools to package your code into discrete units with well-defined inputs and outputs. It offers significantly less tools to wire those units together and actually make then into a complete piece of software. In the end, if you roll your own solution, you often get to choose between "bowl of spaghetty" or "needlessly complicated". Frameworks stepped in to solve that problem (or at least make it look as if all the complexity were justified).
- the reflection API encourages adding your own semantics to java language constructs and in a way extending the language - except there is no way to coordinate reflection usage by different frameworks.
Re: The primary issues that make frameworks flawed
#36If you aren't using a framework, you are writing your own framework. Moving from project to project will be a pain, for you and others. Disliking frameworks is not very different from disliking DRY, conventions and abstractions.
In my experience, I've been able to completely avoid the framework, rather than building my own. I end up with pretty much the same controller and db access code, absolutely no implicit logic, a "main" entry point (in my case typically in the form of a @ServletContextListener class), and maybe 100-150 lines of boilerplate - i.e. the stuff that is usually implicit, such as reading config files, connecting to a database, etc.
Re: The primary issues that make frameworks flawed
#37I have to say, I disagree with virtually every conclusion here. I don't doubt that there are some bad frameworks, or indeed that some developers have a habit of reaching for the closest framework even when it's not the best solution to a particular problem. This was most obviously demonstrated to me once when several applicants for a developer role submitted a simple CLI coding exercise as an entire Rails app , despi…
I think it depends on the platform, and libraries available on said platform.
On the JVM, I create webapps using a @ServletContextListener class, which essentially is a "main" that gets the servlet context passed to it. You could call this implicit, but it is at least the only implicit thing you need. I have 5 lines that read in and left merge some config files. I manually invoke a spring context for setup/teardown of stateful stuff like database connections, queue connections, etc, and initialization of core services using these. Some more lines to set up the Jersey controllers on the servlet, maybe asset-pipeline or something else for handling static files, and we're up to a total of 100-150 lines of initialization/boilerplate.
The win here is that there is absolutely nothing implicit about my app besides from the invocation of "main". My main beef with frameworks is the implicitness. Great when it works, but I'm so tired of hitting some kind of bug where some implicit thing stops happening for whatever reason and having to trace it down in the framework bowels.
In my experience, there is very little difference between learning a framework vs learning a platform (JVM servlets) and a few core libraries (spring-context, Apache's data source for DB connections, JMS for queue stuff, Jersey for servlets, spring-security for auth).
Re: The primary issues that make frameworks flawed
#38Earlier quoted context omitted.
You don't need much CS theory in order to develop and maintain a CRUD app. I've been a programmer who gets paid to write code for 11 years now, and I'd say most of the code I've seen wasn't that much complicated than a CRUD app. Also, I don't feel the need to be called an engineer. I just write code, hoping that it would work most of the time, under as many diverse circumstances as possible and trying to meet the cli…
Some insights inspired from theory help a lot with writing CRUD apps. (Also of course, inspired from outside and then explored further by `theoreticians'.) The most successful of these are now invisible . Either because they are available libraries or so ingrained in the background of what we are doing. See for example regular expressions, parsers, garbage collection, databases, file systems, CPUs. For CRUD apps, "Ou…
> See for example regular expressions, parsers, garbage collection, databases, file systems, CPUs.
Of course we're all standing on the shoulders of giants. So does the milk-man, who goes door to door using a vehicle of which he doesn't know much about how it was built/what its underlying principles are (is it a Otto-based engine? or a Diesel one? does the milk-man need to know the laws of TD?), but that vehicle is paramount to the milk-man's financial success, so to speak.
All I'm saying is that we don't all need to be like Rudolph Diesel, Nikolaus Otto or James Clerk Maxwell, we can still do our jobs as programmers perfectly fine the same as a regular milk-man does, we don't need to know the theory behind CPUs, garbage collection and the like in order to write code that does stuff.
Don't get me wrong, I get what you're saying and understand your points, I just think that right at this moment the programming world needs more "milk-man-like programmers", because if we build walls around our profession ("you can only be a programmer if you know CS theory" and the like) then nothing good would come out of it. I mean, we will certainly build some cool, nice programs, but the world right now doesn't needs just some, few "cool, nice programs", the world needs lots and lots of code. In order to have lots and lots of code we need more programmers.
Re: The primary issues that make frameworks flawed
#39Saying that Monad should be used instead of frameworks, because frameworks don't compose? Monads don't compose, and the workarounds are ugly and still a topic of active research.
I can't upvote this enough.
I want to use PFP techniques. I have debugged numerous bugs after which I wished that the return type of a function encoded the effect the function has.
But, boy, do they make it hard?! I really do wish that PFP advocates stop deluding themselves and make a better pitch for why and how what they advocate be used by the industry. The first version of Wadler's "Monads for Functional Programing" [1] paper came out in 1992. The paper "Monad Transformers and Modular Interpreters" [2] came in 1995. Swiestra's free monad paper [3] was published in 2008. The Eff Monad paper [4] came in 2013.
Think of all the advances computing has made since 1992. Programmers in the industry have worked hard equipped with their tools deemed primitive. Hell, people have caused real world revolutions armed with nothing but PHP. Yet, the PFP folks haven't gotten around to compose multiple effects in any sensible fashion ... since nineteen ninety two! But that has not stopped them from pointing out with derision how everyone else is doing it wrong.
> It is imperative to understand that the need for composability in our software tools is an absolute requirement. If we as an industry have any hope of not repeating ourselves time and time again, we have to change our ways.
Yeah, right - and which decade can we expect the PFP solution to be delivered?
[1]: https://cse.sc.edu/~mgv/csce330f16/wadler_monadsForFP_95.pdf [2]: http://haskell.cs.yale.edu/wp-content/uploads/2011/02/POPL96... [3]: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101... [4]: http://okmij.org/ftp/Haskell/extensible/exteff.pdf
Re: The primary issues that make frameworks flawed
#40Earlier quoted context omitted.
Some insights inspired from theory help a lot with writing CRUD apps. (Also of course, inspired from outside and then explored further by `theoreticians'.) The most successful of these are now invisible . Either because they are available libraries or so ingrained in the background of what we are doing. See for example regular expressions, parsers, garbage collection, databases, file systems, CPUs. For CRUD apps, "Ou…
> See for example regular expressions, parsers, garbage collection, databases, file systems, CPUs. Of course we're all standing on the shoulders of giants. So does the milk-man, who goes door to door using a vehicle of which he doesn't know much about how it was built/what its underlying principles are (is it a Otto-based engine? or a Diesel one? does the milk-man need to know the laws of TD?), but that vehicle is pa…
It is precisely this attitude that has hampered the development of programming into a respected profession.
The world does not need lots and lots of code or programmers; the world needs less but better code and programmers, quality over quantity.
But this objective is thwarted when the idea keeps being thrown around that "everybody can, and should, code." There is already a glut of bad code developed by "programmers" unaware of what they do not know and unwilling to continue learning to improve.
Bad code, be it un-secure, un-performant, or un-usable code, is turning off consumers, and the earlier we sit up and seek way to improve code and product quality, the better.