3 ms·

I find languages are pretty easy to pick up after the first few. What seems to be the barrier nowadays is frameworks. How do people go about learning a new fram

I find languages are pretty easy to pick up after the first few. What seems to be the barrier nowadays is frameworks. How do people go about learning a new framework? Obviously most of them have an intro project to follow on with, but they tend to be pretty simplistic, and once that's done, getting to the complicated bits that you actually want to implement seem to be the barrier.

marginalia_nu 5y ago
I usually prefer working with mature stacks that don't require me to constantly work with flavor of the month frameworks. It's great to broaden your horizons and all, but that is something that needs to be done judiciously and deliberately if it is to actually be of any use.
- askvictor 5y ago
  Me too, but to get started on a non-trivial project in such a stack is, IMO, the tricky part. It would be nice if I could do everything in the stack(s) I already know, but that's not always possible (e.g. backend vs web vs mobile app vs desktop app).
trevyn 5y ago
Re-implement a toy version of the framework from scratch. :-) Or, try to add a non-trivial feature to the framework.
- cjaybo 5y ago
  How do you know what a "toy version of the framework" looks like when you're not experienced with the framework itself? It seems to me like you've already solved the issue of "learning the framework" if your mental model of the framework is that solid.
  - sodality2 5y ago
    Knowing what a framework does (its function) and knowing how to use it (its functions) are two different levels of knowledge. sometimes you can work backwards from knowing what it does to make a very quick-and-dirty implementation.
  - stepbeek 5y ago
    Perhaps by addressing the issues that led to you adopting the framework?
- theonething 5y ago
  Wouldn't building a small, toy application with the framework be a more efficient way to learn it?
SavantIdiot 5y ago
IMHO, if a framework isn't well documented, I avoid it. It means they probably didn't think it through very well and it will soon be unmaintained.
leshow 5y ago
If you stay strictly in the procedural/OO paradigm then sure: it's just a new std lib and syntax. When you jump to functional, logical, or more esoteric paradigms things start to get pretty different. Of course if you've already got one of each major paradigm under your belt things get progressively easier because you're exposed to more ideas...
baby 5y ago
/me trying to learn OCaml after learning a bunch of other languages. Disagrees.
- Zababa 5y ago
  In my experience, one of the hard part when learning OCaml is that you can write your own code without modules, but to use someone else's code, you have to know how they work.
- feffe 5y ago
  Same experience, I thought I had things figured out but after a few weeks struggling with OCaml I felt like a complete retard :-) But it was an eye opener in some way on how to write programs in a different way. I think OCaml also suffers a bit the same problem as C++ does. You need to learn quite a lot to be able to read others code. There are many advanced concepts with cryptic syntax that is hard to search for on the net.

marginalia_nu 5y ago

I usually prefer working with mature stacks that don't require me to constantly work with flavor of the month frameworks. It's great to broaden your horizons and all, but that is something that needs to be done judiciously and deliberately if it is to actually be of any use.

askvictor 5y ago
Me too, but to get started on a non-trivial project in such a stack is, IMO, the tricky part. It would be nice if I could do everything in the stack(s) I already know, but that's not always possible (e.g. backend vs web vs mobile app vs desktop app).

trevyn 5y ago

Re-implement a toy version of the framework from scratch. :-) Or, try to add a non-trivial feature to the framework.

cjaybo 5y ago
How do you know what a "toy version of the framework" looks like when you're not experienced with the framework itself? It seems to me like you've already solved the issue of "learning the framework" if your mental model of the framework is that solid.
- sodality2 5y ago
  Knowing what a framework does (its function) and knowing how to use it (its functions) are two different levels of knowledge. sometimes you can work backwards from knowing what it does to make a very quick-and-dirty implementation.
- stepbeek 5y ago
  Perhaps by addressing the issues that led to you adopting the framework?
theonething 5y ago
Wouldn't building a small, toy application with the framework be a more efficient way to learn it?

SavantIdiot 5y ago

IMHO, if a framework isn't well documented, I avoid it. It means they probably didn't think it through very well and it will soon be unmaintained.

leshow 5y ago

If you stay strictly in the procedural/OO paradigm then sure: it's just a new std lib and syntax. When you jump to functional, logical, or more esoteric paradigms things start to get pretty different. Of course if you've already got one of each major paradigm under your belt things get progressively easier because you're exposed to more ideas...

baby 5y ago

/me trying to learn OCaml after learning a bunch of other languages. Disagrees.

Zababa 5y ago
In my experience, one of the hard part when learning OCaml is that you can write your own code without modules, but to use someone else's code, you have to know how they work.
feffe 5y ago
Same experience, I thought I had things figured out but after a few weeks struggling with OCaml I felt like a complete retard :-) But it was an eye opener in some way on how to write programs in a different way. I think OCaml also suffers a bit the same problem as C++ does. You need to learn quite a lot to be able to read others code. There are many advanced concepts with cryptic syntax that is hard to search for on the net.