3 ms·
I found this a very personal and honest explanation about the limitations of one approach to learning a programming language or framework. Without prejudice, le
by nvader 12y ago
I found this a very personal and honest explanation about the limitations of one approach to learning a programming language or framework. Without prejudice, lets call it the "agile approach" to learning-> you want to get started quickly and then iterate to a better place.
In my own experience, I've always been dissatisfied with this approach. It builds too slowly, and you either reinvent the wheels that already exist in the language, or fail to take full advantage of transformational abilities of the language. Assuming you already know how to program in language X, you end up "Writing X in Y" (as in, "writing Java in Ruby"). I do prefer the alternative, which is to spend some time reading the language manual and references, fully understand the language before going off to do some damage. Learning is process that is never completed; however the "RUP" approach to learning gives you a much more strongly connected belief network on which to hang concepts you'll be introduced to in the future. This is opposed to having to take new lessons as standalone facts to be memorised: see the article's confusion regarding pointers and references.
However, we often don't get to spend that time upfront learning things. Sometimes the project deadline requires you to pick up that new framework and get something working -right now-. Alternatively sometimes I need to work with something that I don't want to spend all that energy learning, and it's easier to just hack along, rather than actually commit to a deep learning of the framework.
There are two questions this raises for me.
1) As an engineer who claims to value craftsmanship, how do I reconcile with the fact that I don't really know at least a few of the tools I use? Is the right action to actually invest my own time in learning new frameworks, no matter how skeptical I might be of their value outside this one project? This risk-reward calculus is especially exacerbated in an ecosystem with a lot of churn in frameworks and libraries. In such a situation, what is the right approach for me?
2) As a producer of knowledge tools for other developers (libraries, APIs, maybe one day programming languages), how should I define my interfaces knowing that some of my users will not bother to learn them? Do I have a responsibility towards them?
Slightly more speculatively, I wonder how this would affect language design? One of pg's aphorisms is that tools designed for use by people the designers consider inferior will generally be poor quality. However, that doesn't stop such tools from being popular. I don't think we've truly plumbed the depths of a language "designed for lazy and/or sloppy people", and I'm willing to bet that executed well, such a language could be very popular.
- snmf 12y agoAgree with you. For me it's crucial to get results as fast as possible and I found this approach is the most satisfying and productive. The problem with C++ (unlike python, for example) that it is really hard to experiment with the language: you change one minor detail of the code, and you have to rewrite big chunk of the program eventually. That's why I first want to get results and then read how it works. By the way, could you briefly describe RP approach?
- techjuice 12y agoThis is not a problem with the language but the one programming in the language not having a more in depth understanding of the language. Rushing for results without working out a proper solution or really understanding how to get from point A to B to get those results may end up with a false result. How do you prove and verify your work if you are taking short cuts to get something you hope is the correct answer. How do you know what you just copied and pasted is the most efficient way of solving the problem. When moving to C or C++ there are normally faster ways to accomplish tasks then what is possible with higher level languages due to the built-in limits of the higher level language. It is similar to learning Calculus, Statistics, Number Theory, etc. you start at the beginning with basic math and move up the later, trying to skip these foundation and using what you find online without the capability to verify is a grave mistake. Those that skip the base foundation will be those that make grave errors in the future that can cost lives, time and or money. Once you take the required time to learn C and or C++ you will eventually understand the power you have at your fingertips and what you once thought was hard or cumbersome will no longer be that way. A benefit of learning C and or C++ is that you will understand the languages they are built in better. Especially if you want to optimize the higher level code for performance or if you unfortunately find a security hole you will be able to assist with submitting a more detailed security report. I see you are focused on seeing results as fast as possible, if you learn C and or C++ more in depth you will get the results faster when you run your professional grade code. On your note about having to rewrite a big chunk of the program eventually this is not true if you know what you want to do, design it properly up front and insure it is not heavily coupled with other parts of your code. C++ is a great language to get deep into object oriented programming and C for functional programming, learning both in depth will open your mind up to more battle-tested solutions that you can apply in higher level programming languages. Just give it time you will see the light and it will help you in both lower and higher level programming languages.