Do Not Learn Frameworks – Learn the Architecture • Hacker News Board

Re: Do Not Learn Frameworks – Learn the Architecture

#71

Post by qyv » Fri, Apr 03, 2015, 3:25 PM UTC

ef4 wrote: post #30

The author is only partway through the learning process. There is a circular progression. The total newbie just "learns the framework" and is helpless to debug through leaking abstractions. I agree 100% that you don't want to be stuck there. So eventually she decides to just compose her own architecture. Now she understands all the pieces. But as she matures further as a programmer and architect, she starts to see al…

I don't this the author is advocating dropping all frameworks, and certainly not making your own custom framework for every project. The point is more moderate than that: There is just to much reliance on frameworks in general, especially in SPA/front-end development. Frameworks work great until they don't, and then what? Over-reliance on frameworks does create a dependency on the developers, they learn to implement their framework of choice instead of learning good software design. And worse, this can foster the belief that frameworks are a necessity on every project. When all you use is a hammer every problem looks like a nail. Frameworks can be a force-multiplier, but they are also constrictive in a lot of ways. I have run into this first hand, especially with longer-running projects.

Re: Do Not Learn Frameworks – Learn the Architecture

#72

Post by mbrock » Fri, Apr 03, 2015, 3:47 PM UTC

malisper wrote: post #65

mbrock wrote: post #43

Earlier quoted context omitted.

Richard P. Gabriel critiqued this notion of "patterns should be abstracted and instantiated" in his 1996 book Patterns of Software [1]. To summarize as briefly as possible: abstraction has costs, too. Sometimes it's better to spell out the pattern. As you probably know, the idea of patterns came from architecture, where "reusable abstraction" translates to "modular house" – which is not obviously better. [1]: https:/…

> Richard P. Gabriel critiqued this notion of "patterns should be abstracted and instantiated" I think patterns should always be "abstracted and instantiated". I always found his example of actual code in support of his argument a bit weird. From the book: Does the following code fragment: (mismatch sequence list :from-end t :start1 20 :start2 40 :end1 120 :end2 140 :test #’baz) seem easier to understand than this pa…

I wouldn't claim conclusively that the second version is better, but I see Gabriel's point. Yes, the first version is elegant, and it is easier to spot the predicate—but I also can't tell you exactly how the predicate is used, because I don't know the definition of MISMATCH.

For example, should a positive result from BAZ mean that the items are the same? There's no way to tell. You could argue that this is because of poor keyword argument naming, but that's part of the point: in the second version, there's no need for such considerations, because the use is explicit.

(Consider yourself lucky that the function uses keyword arguments to begin with!)

Nor do I agree that the first example is obviously bug-free. How would I know? The definition of the actual logic is in some other file. Yes, that's true for the library functions used in the second example, but those are standardized.

Other examples of ambiguities: Are START1 etc counted from the end of the list or from the beginning? What happens if there are several mismatches? What's the time complexity? Etc. Of course these would be part of the documentation, in an ideal world.

I should point out that Gabriel isn't arguing that patterns should not be abstracted (or "compressed"), only that there are tradeoffs.

Re: Do Not Learn Frameworks – Learn the Architecture

#73

Post by jdlshore » Fri, Apr 03, 2015, 4:56 PM UTC

acjohnson55 wrote: post #25

pags wrote: post #13

Earlier quoted context omitted.

The difference is that the framework is built to be an open source framework - it has general abstractions. Your own patterns and practices are developed to apply directly to what you're building.

But a good framework has well chosen abstractions that took many person-hours to settle upon, a community of engineers working to perfect it, and probably uncountable hours of production battle-testedness.

> has well chosen abstractions

That's a rather large leap of faith.

It's more likely that it has a bunch of abstractions that were chosen early in the project when the maintainers were young, dumb, and eager; that have since shown their age and have been worked around repeatedly; but can't be removed due to being core to the framework and having a large body of applications depending on them.

Re: Do Not Learn Frameworks – Learn the Architecture

#74

Post by fsk » Fri, Apr 03, 2015, 4:57 PM UTC

benihana wrote: post #16

fsk wrote: post #4

The problem is that job ads always say "We want experience in X, Y, Z." They never say "We want someone who can code without a framework, and could learn whatever we're using quickly."

I hear what you're saying, but there were several posts and job ads in the who's hiring thread the other day saying "we don't care if you know $technology_in_our_domain, we want quick learners who understand concepts."

I replied to a couple of ads that said that. I didn't get a phone interview.

Re: Do Not Learn Frameworks – Learn the Architecture

#75

Post by jdlshore » Fri, Apr 03, 2015, 4:58 PM UTC

prank7 wrote: post #61

I have been doing web development for last 1 year. Can someone recommend a resource to learn Architecture?

Martin Fowler's _Patterns of Enterprise Application Architecture_ is excellent.

Remember, the best architecture is minimal architecture, because architecture is the fundamental, hard-to-change patterns in your code. So learn architecture, but also learn how and when to make it unnecessary.

Re: Do Not Learn Frameworks – Learn the Architecture

#76

Post by z3t4 » Fri, Apr 03, 2015, 5:06 PM UTC

aikah wrote: post #42

This is a false dichotomy but I'm not surprised, especially in the js world. JavaScript is so little opinionated that developers refuse to read each others code, because it's usually not written in the way they think js should be written. And soon it will be worse with classes,proxies and all the python like "ninja" features of ES6. It's not about "not using framework",it's about reading the source of anything you're…

One of the great things about JS is that you can (unless minified) look at the source code. That's how I have learned JS and are still learning! Most times when looking at other peoples code you learn how not to code though ... But once in a while you find a gem and a light bulb lights up in your head.

Personally I've never felt the need to use a framework, but I can see how it can be useful, like if your team has little experience. Then a well documented road map might be useful. But not so fun if you decide to go by foot.

Re: Do Not Learn Frameworks – Learn the Architecture

#77

Post by Digit-Al » Fri, Apr 03, 2015, 5:30 PM UTC

saiprashanth93 wrote: post #24

Scarbutt wrote: post #18

Earlier quoted context omitted.

Javascript does not have built-in support for modules, so he is using a library to have module support. An anti-architecture (in the article's sense I think) might be people who just know jquery but do not know javascript or how the DOM, the browser api, etc.. works, some just use jquery for something that can be done with 10-15 lines of JS, but they don't know better, they lack the principles/architecture knowledge…

This is still a little vague. What does it exactly mean to learn architecture?? Should I be reading the source of the framework and understand how all the design patterns fit in?? How well should one know the language to read the source of the framework?

Free online book discussing design patterns using Javascript: http://addyosmani.com/resources/essentialjsdesignpatterns/bo...

Re: Do Not Learn Frameworks – Learn the Architecture

#78

Post by known » Fri, Apr 03, 2015, 5:31 PM UTC

Best advice I've seen for a longtime;

Re: Do Not Learn Frameworks – Learn the Architecture

#79

Post by a_c_s » Fri, Apr 03, 2015, 5:37 PM UTC

fsk wrote: post #5

>Do I use frameworks? Only when it's not required to maintain a product in future. I've been on the flip side of this too many times. Some outsourcing company developed a product using a framework (usually on a fixed-price bid), which enabled them to ship something that sort of mostly worked so they could get paid. Then, I'm stuck supporting and maintaining it, and it takes 3x-5x longer than it should because of the…

I've been there a couple of times, dealing with abused frameworks can be rather painful!

However, I think the big problem is dealing with code that an outsourcing company "sort of mostly worked so they could get paid". The incentives are just not there for a quality product: framework or not, they are going to produce a slapdash hodgepodge of code.

If they didn't have a framework, is there a reason I'm not seeing to think that the resulting mess of code would be any easier to support?

Re: Do Not Learn Frameworks – Learn the Architecture

#80

Post by emodendroket » Fri, Apr 03, 2015, 6:01 PM UTC

jacquesm wrote: post #64

Joeri wrote: post #54

Earlier quoted context omitted.

In the case where an open source framework loses its maintainer, in the worst case you are the maintainer. In that case you are no worse off than with your own framework, except that for a number of years the maintenance work was done for you for free.

With one small difference: you'll likely have a much larger attack surface because the third party framework was created to do much more than to just service your applications. And all that code will need to be maintained now. That can get very costly.

If that's really the case you could easily just cut out features you don't intend to use.