Contexts - a barrier too high for newbies?

Books are expensive for all programming languages, so where is the actual argument in saying that if you can’t afford an Elixir book you should learn something else?

Furthermore there are enough jobs for Elixir/Phoenix, if you use it as your programming language and framework of choice, e.g. as a freelancer, like I do. Entry level or not, the actual issue here are contexts in Phoenix, which have been declared by several users here as being a basic (entry level) thing to know, before you start – so why should I have to learn it from a book in the first place?

And that you’re either learning Elixir/Phoenix as a hobby or are a pro user is a false dichotomy par excellence. So people who learn Phoenix/Elixir have a right to learn it only if they have enough money? I thought we were talking about Open Source here? And what about people who switch languages to consolidate their knowledge and make it more future proof?

Sorry, your whole comment doesn’t make any sense.

1 Like

I do think it makes some sense :slight_smile: I’ll try to expand on some of the point you’ve raised.

What I meant to say is that if an Elixir book is too expensive for you, maybe you should try something else with more available jobs.

The argument is that if you need a paying job, Elixir is probably not your best choice right now, just that :slight_smile:. If you’re already working as a developer you can probably (not always, I’m generalizing here) afford the book. If you can’t, there are probably better options to start a career as a developer. However, if you say that there are enough freelancer jobs where you can use Phoenix as a freelancer, then I take that back. Maybe Elixir is a good choice absolute beginners after all. I shouldn’t have suggested the opposite without having looked into the freelance landscape.

As I remarked in a comment above, contexts are a feature of a release candidate. A release candidate is not supposed to be as well documented as an actual release. Part of the problem is that people with little experience seem to be jumping to the latest and greatest in fear of being left behind, and are naturally surprised to find a new feature that is scarce on documentation. I expect contexts to be documented in the official phoenix online docs before an actual release. I agree with you and think the basics of contexts are not the kind of things you should learn from a book.

Well, yes… I don’t think the Elixir developers should be forced to write and edit documentation for free :wink:
The available docs are already great and way above average compared to most programming languages I’ve tried.
I have a prototype phoenix app which I’ve built without touching and Elixir book and which is way better than the original Python app that came before according to my users (this is not an argument against python, its just that Phoenix fits my use case much better).

People who get paid for using a programming language should not be too shy about spending money to learn another one… This is not to be taken as an absolute moral argument, just my personal opinion. The Elixir/Phoenix core developers already share much of their hard won experience in the form of online docs, blog posts, forum comments and even one-on-one mentoring for some open source projects. It’s not too outlandish to pay for a book to get a little more.

Whether you agree or disagree with me, this is a defensible position.

These points are all independent on whether personally one thinks contexts are a good idea. I respect your opinion, and you might well be right. I’ve built a grand total of 1 Phoenix application, while you seem to have written several.

To me, contexts are an interesting abstraction but I don’t know how useful they are in practice, as everything I’ve done that uses contexts could have been done without them :smile: I feel like the concept of contexts could be tweaked somehow to allow or better tooling around them (a visual context editor, as I’ve described above), but I’m nowhere experienced enough to work on that right now.

1 Like

I like Phoenix 1.3 and to me Contexts are akin to Java packages and are a way to organize code. As far as documentation goes it’s an RC, I’m sure the documentation will be there for the actual release.

2 Likes

I think there’s a big problem with expecting people to learn from a book, but it’s not about cost so much as that it’s a poor way of learning for a lot of people. There need to be quality learning materials in all sorts of learning styles.

1 Like

I think this is a fine point. However, this is a 150 post threadnaught that will never end if it diverges to much from the original question.

1 Like

There are - the Elixir and Phoenix guides and docs are renowned for being some of the best in the industry.

The only reason there isn’t more on Contexts is because it is part of an RC and possibly because the core team are still ironing out details. In the meantime we have lots of community efforts to help fill in the gap - whether that’s blog posts, confs talks, forum resources or even answers to questions on the forum (and elsewhere).

It’s not about expecting anything - it’s just that I am personally a proponent of using professional material to learn because I feel it is the best way to learn :slight_smile: your preference or milage may vary - that’s cool. As said, the Elixir and Phoenix guides are some of the best around :023:

(If you think the guides or docs are lacking in anyway feel free to start a thread about it.)

No more posts about contexts for me as I said but I’m sorry this is just a pretty standard early adopter fannish kind of thing thats really just utter denial and shoots a young framework in the foot. It just illicits an eye roll and looking for the exit to anyone also active in Javascript/node Python/Django Ruby/Rails or even C#/.net with a multiplicity of books, videos and tutorials on the web with all kinds of styles that dwarf anything Phoenix has or even could have yet as relatively new. Maybe you misunderstood the point. I dunno

I will also comment on the book thing only because I was the one that first brought it up and its been miscontrued at least twice.

A) I don’t care how much money I make. As long as there is a charity and a hungry kid in the world I am not going to buy a book on a subject just to spend money because I can so theres a learning process involved in making that decision to even buy the book

B) Nothing to do with wanting the developers as has been now alleged to do everything for free including in depth training. My point was to the COMMUNITY that points to the book as the end all and be all of understanding the framework as I have read and watched a multitude of places. In my mind developers with that code work and the docs to back it up have already gone above and beyond in any language or framework. Its a community thing to then explain and and inform further not just tell everyone to buy the exact same book as a fall back to answer all/most understanding issues, Claiming or even implying someone should pay for a book to ascertain whether one of its core concepts is for them is NOT the spirit of open source.

C) TBH Many times its the guy that learned it six months ago that is FAAAR better teaching newbies because he can still relate to the potential questions and pain points of learning that are still fresh enough in his/her mind. Developers of the framework often suck at that.

P.S The fact that a framework or language has few jobs doesn’t make it a hobby language or framework. It can be robust professionally because developers are working on their own projects and/or within existing companies/contracts they are already hired in.

2 Likes

That is why the Ueberauth style is nice, it is just an interface for pluggable authentication. It has no templates, no authentication, nothing by default, just gives a unified interface to plug in any form of authentication.

But yeah, doubt it should be in Phoenix.

1 Like

I feel like one thing this conversation is lacking is that folks assume the core-team didn’t based their decisions around these points. No one here was present for the hours of back and forth discussions on what would be too much for newcomers and where the perfect balance might be for our learning tools. Likewise, I spent many weeks writing different generators and then we would debate the balance of ideas. For example, earlier passes of the generators used Ecto.Multi and Repo.transaction because I wanted folks to learn about transactions early on as it’s something that is overlooked. In the end, we decided it was too much for those just getting started, but no-one in this discussion sees this back-and-forth and instead the discussions have regressed to either 1) contexts are good and not a barrier, or 2) contexts are a barrier, period. There’s a middle ground conversation that really isn’t happening where we can identify what aspects might be a barrier and how to fix them. For example, it’s clear that some folks are getting stuck on coming up with a name, which we’ll add docs and examples to address in the next release.

I don’t agree with this point. I don’t agree that capturing newcomers requires saying or teaching that their code lives inside the controller. I’ve been at this for a while now, and marketing the framework as such has never been part of my plan or something I position for newcomers to latch onto.

To your points about what phoenix needs to help newbies, I agree a wealth of official and community sourced learning materials is the best combination. As with anything, it will take us time to build up the comprehensive resources like the Django community – after all they’ve had a dozen years to get there. We’ll get there, but we won’t do it alone :slight_smile:

I’m convinced that guiding newcomers to design their applications with intent is the right choice. I’m also convinced that the generators isolating functionality behind modules and functions is a path that we can successfully navigate for newcomers.

Rather than appealing to the fear of losing newcomers, I’d rather have discussions on how to make this learning process the most successful. Folks need to understand these questions of balance have been part of our decision process from the beginning.

11 Likes

Instead of making derogative sweeping statements it would be more helpful if you can point out where they are lacking. I know that Contexts are not yet covered but as explained this is because the feature itself is still in RC and it’s likely the core team are still finalising the details. (But there is plenty of help/community resources in the meantime.)

If you’re speaking in broader terms, we are incredibly lucky to have some of the best tech publishers involved with Elixir… and some fantastic authors. For the age of the language I’d say its on route to match that of Ruby (which was IMO easily the best for learning material - from my experience anyway).

I don’t get your point. Buying a book isn’t spending money for the sake of it - it’s gaining knowledge from a more experienced person who is taking the time and trouble to write material that is considered and digestible to help you learn as fast and as easily as possible. Writing a (good) book is hard work.


With all that said, I appreciate that currently Contexts is proving difficult to grok for some - that’s why we’ve put up resources and threads on the forum to try and fill the gap until the docs (and books) are ready.

1 Like

Personally, I just don’t see the upside of contexts. In my opinion, people who understand the benefits of modularizing their code are going to do it anyway, and those who don’t are just going to put everything into some “main” context, which they will then have to reference constantly. There might be some people in the middle, but I think that group will be very small.

1 Like

It seems to me from this thread that what may be missing is a sort of Phoenix fundamental guiding principles/what it is and what is it not, that clearly draw a line and lay the ground for future development options so that everyone clearly understands the tradeoffs involved.
Everyone knows that as the more an ecosystem grows the more different views and opinions we’ll have. We’ll never have everyone agreeing on all the decisions that are made.
So, my view about Contexts may be different than some other views but as long as IT STAYS ALIGNED with the fundamental principles I know I’ll be aligned with the majority of the Phoenix users because they must be aligned, otherwise they’ll flee.
Honestly, when it comes to open source, I don’t think that appealing to the vast majority of developers must be the number one criteria of making framework or languages. Creators don’t profit directly from that as a company would profit. The driver must be do things as the creator thinks they should be and if that vision proves to be correct then growth and users will come latter.
Usually when creators start to make a lot of concessions the result is not good enough any more.
Again, there’s no right or wrong it the arguments I see here. I’m more inclined to some but I recognise that even myself was once more inclined towards other arguments before. So, we also change and right now Contexts make me more happy than without contexts.
Also, again, and because I think this thread is generically about newbies barrier (not only Contexts) my opinion regarding authentication diverges from Chris McCord’s opinions. If, in the case of Contexts I can see that the more complex the project will become the more benefits I can have from Contexts, with Authentication is the opposite: the more complex the project becomes the more difficulty I’ll have in using Phoenix without a proper authentication system in place and I may be forced to go away because a robust, end-to end authentication system is not something I think I should do. It must be part of a good web framework.
I know that would bring an overhead to Chris McCord, but there are some libraries that they needed to create once and that are not needed any more because we have good alternatives and the effort could shift from them to authentication (I’m thinking about internationalisation, SMTP, HTML helpers,…).
My view regarding authentication doesn’t mean we don’t have libraries that allow us to start a project. It means I think none is robust enough or offers guarantees of being future proof. And that’s only because authentication is a very complex tasks that must be integrated with the framework (I believe in this but off course, others don’t, which again, just means that we need to know how aligned we are with Chris McCord’s own view :slight_smile: )
Nevertheless, I must confess that THIS IS THE BEST COMMUNITY I’ve ever been involved with and that’s a HUUUUGGE advantage that allow us to overcome lots of road blocks.
Thank you all.

I think this philosophy of finding better ways of doing things is one of Elixir’s and Phoenix’s biggest appeals :slight_smile:

I also have no doubt in my mind that you and the core team properly consider concepts before introducing them - in fact everything I’ve seen so far shows that you care deeply about this :purple_heart:

3 Likes

From my anecdotal experience, single file Flask apps with thread locals, no namespaces, non deterministic route matching, no centralized router, morbidly obese controllers and dat sweet, sweet fat ORM with N+1 queries scattered around capture newbies like quicksand. I know because I’ve been there. Actually forget it, most flask apps don’t even call them controlers :stuck_out_tongue:. You can design well structured Flask apps, but that’s not what’s going to get newbies to try the framework. And that’s ok, because they’ll learn about HTTP headers, authentication, DB management, templates, and might even do something useful. Then they’ll get frustrated trying to get websockets to work and try phoenix.

Regarding all your other points: I agree with all of them, and have even outlined some of what I perceive to be the real barriers. As soon as I have the time to blog about it, I’ll try very hard to sell contexts without any of the evil lies you don’t want me to spread about Phoenix :stuck_out_tongue:

1 Like

I already have and so has the person you were responding to and I’ve already made it perfectly clear that some of that is to be expected for a new framework. Thats something every new framework community has to live with not be in denial about. Every new framework should be very conscious of the pain point of limited learning material, examples and libraries/packages. that conscious honesty helps it break through that stage. Denial not so much

well I’ll make one last attempt and then just accept you will never get it and let the book thing die as well (it was not tangential in regard to contexts when it was brought up but it is now). Have you bought books about every framework and language you read about that has a published (print or PDF) book? Why not? After all Its “gaining knowledge from a more experienced person” isn’t it? Maybe you have unlimited time. Most developers and would be developers don’t. commit to learning a language and framework until we get a good sense of what it is and the utilty and philosophy of it. We pass on it if we don’t because the programming world is far larger than any one language or framework and fantastic apps are being built with almost all of them. I don’t get whats so hard to get in that point and this thread is in part about barriers to newbies which IS an adoption concern.

1 Like

But nobody’s in denial. The team have acknowledged they are working on the guides for Contexts.

Well that’s not what you said, you said something completely different:

As long as there is a charity and a hungry kid in the world I am not going to buy a book on a subject just to spend money because I can…

But back to your newer point of assessing a framework - I suppose we all approach new tech in different ways. I generally watch videos and talks first and foremost as well as read a broader overview; I don’t need to get my hands dirty or know the minor details to know enough about something to make an assessment as to whether it is something I night like or something I want to investigate further (/learn).

But this is a moot point - it’s been said over and over now, the guides are going to be updated for Contexts soon, and if there is still a perceived barrier after that, it can be discussed in a more informed way.

I’m beginning to think this thread needs to be closed until then…

1 Like

the point of diversity of styles has absolutely nothing to do with the team (I have seen none of them in denial claiming ELixir or Phoenix is reknown for their diversity in training materials). Diversity of styles of training material is NOT a team issue its a community issue. guides are not going to provide diversity of styles by themselves. Thats not the meaning of diversity/variety. My points are not new (as any one honest enough can see from reading my post #126 onward) you just failed to get the same point all along. Like I said if you didn’t get it yet you are not going to so my discussion with you ends for me right here in my last post in response to you on that . “We are world reknown rah rah” fandom types conversations in the absence of reality are a waste of time but unfortunately people fall so deeply in love with some tech it hurts their cause. Thats precisely when similar communities have begun to suck and suck badly.

Renowned by whom? I doubt most developers even know Elixir exists.

1 Like

By those whose comments I’ve seen.

But it doesn’t matter what I (or they) think - if you think the guides are lacking, please tell us where and how you think they can be improved. That is the only constructive way forward.

I’m struggling to see your point. There are huge resources for Elixir, much more than for other similarly aged languages. Just look at our Learning Resources sections.

There are

  • books published by top tech publishers
  • self-published books
  • community made online courses
  • online courses by Pluralsight, Udemy, PragDave, Pragmatic Studio etc
  • learn by doing with CodeSchool
  • screencasts both paid and free
  • hundreds of conference talks
  • even more blog posts

…and much much more. I don’t think I’ve seen any language get as much learning material in as much time. If you know of any please let me know!

The amount of published books itself is quite staggering (and a great indication on where top tech companies are placing their bets). It took Erlang 7 years before it got its first book.

I’m not one to rest on laurels, but I think that if you are expecting more than this at this stage, well, then you are just being a little unfair. Personally I think the community is doing an amazing job on learning material (but again, you are welcome to leave constructive and actionable feedback on how things can be ‘improved’.)

1 Like

This thread in particular become toxic a long time ago.

I’ve seen people with no programming background use GOTO successfully in crazy scripts that do very complex things very well. I can’t imagine something like Contexts really stopping someone who wants to get something done.

The Context generators themselves are just learning tools. People who really want to get stuff done will ignore the lessons Contexts are trying to convey and just get things done. This happens in every language or framework. People who are more interested in how to be more build maintainable software would pay more attention to the lessons in the Context generators.

However, If you really just don’t think it’s the right choice, then prove it. The Phoenix generators are just another project inside the repo. Write your own generator project, publish it, advertise it, and get the mindshare of the community.

Then your point will be made in a sufficient way without being toxic towards other people.

1 Like