I have been struggling with an idea for a few weeks and wanted to see if someone can help me out here.
Programming today is full of abstractions, and people who do not understand the abstractions, do not truly understand the reason or design than went into building that abstraction/layer/framework and will struggle as soon as they step outside the comfort zone.
I was wondering if there is a learning resource that goes about teaching programming in an incremental fashion. This will lead to understanding the full stack.
take a small problem
implement a simple solution
talk about the the solution and the designs used
convert the solution into a framework or utility of some sort
now extend the problem space and repeat from step 2.
This way when someone then picks up any framework/library, they can easily visualize the problems the framework is trying to solve, the design decisions taken and the reasons thereof.
[Added to clarify the intent]
Based on the answers and comments below, I want to clarify that I want to move further up the stack. Building your own ORM to understand ORM better, same goes for ActiveRecord, IOC container, data binding, templating engine, and the host of other magic/glue/plumbing we use day-to-day.
Thanks.
Here's what I recommend : Have a brush with assembly (just one book or one month is enough). Have a good strong review of C++ (hopefully it will teach you some of C as well). Now the world is yours. Python is made in C/C++ , Object C is pretty close to c++, .NET is in C++ and C#/VB.NET , The windows API is oriented for C.
I picked C# as my abstract language of choice after this by the way.
Read the source. It is a good idea to build something you want to understand, but you can enhance your understanding of concepts significantly by looking at how something is built. This is especially true for infrastructure pieces (ORM/DI/Templating) which you seem to be interested in.
Get the software to build on your machine, attach a debugger and trace through the code. This is pretty easy for C#/Java with a good IDE. For dynamic languages like Python and Ruby, it takes a good editor and a lot of grepping.
If it is a good software package, it will usually have tests. Tests are a great place to start digging into code. They usually make clear the intent of the code, and also provide you a logical starting point to peel off the layers and actually peek under the hood.
Build a fully functional compiler from scratch in a systems language like C or C++. Maybe it isn't the full stack, but it's a large part of it. This is something I want to do as well. If only I could find the time and space.
The best example of the sort of learning resources I am seeking is the MIX session by Rob Eisenberg on "BUILD YOUR OWN MVVM FRAMEWORK". It goes step by step on explaining the pattern and also implementing it at the same time, attacking one problem area at a time.
http://live.visitmix.com/MIX10/Sessions/EX15
Hope there are more out there.
I'm having a bit of an overload of information these past two days.
I'm planning to start my own website that will allow local businesses to list their items on sale, and then users can come in and search for "Abercrombie t-shirt" and the stores that sell them will be listed.
It's a neat little project I'm really excited for and I'm sure it'll take off, but I'm having problems from the get go.
Sure I could use ASP.Net for it, I'm a bit familiar with it and the IDE for ASP.Net pages is bar-none, but I feel this is a great chance for me to learn something new to branch out a bit and not regurgitate .NET like a robot.
I've been looking and asking around but it's all just noise and I can't make an educated decision.
Can you help me choose a framework/platform that will make me learn something that's a nice thing to know in the job market, but also nice for me to grow as a professional?
So far I've looked at:
Ruby on Rails
Kohana
CakePHP
CodeIgniter
Symfony
But they are all very esoteric to me, and I have trouble even finding out which IDE to use to that will let me use auto-complete for the proprietary keywords/methods.
Thank you for your time.
Have you considered ASP.NET MVC?
You will learn MVC architecture and client-side programming with javascript and jQuery, in a nimble platform that produces clean markup. If you are used to ASP.NET, you will be surprised at the clarity of design.
The NerdDinner tutorial is the go-to guide for getting started.
I suggest you try the whole Java eco-system.
Both similar and different to the .NET world, a lot of open-source frameworks.
Eclipse is a very good free IDE.
Also, why not go with GWT for the client side ?
In any case - enjoy !
Because nobody's mentioned it yet, I'm gonna have to suggest Rails.
I'm sure you're going to hear arguments for each framework you mentioned (and probably some you didn't), but I"ll be brief and explain why I got into Rails, having tried several of the others in your list:
It's beautiful. Coding in Ruby actually makes me happy. I find that I'm removed from a lot of tedium I've come to associate with large projects, and it's totally changed my coding career - I would literally hate to think how much less content of a programmer I'd be had I not taken the plunge. My only suggestion here would be to just try it.
Besides the succinctness of Ruby, Rails got me thinking in a more modular, logical and maintainable manner. As well as the great community, I really subscribe to the principles Rails stands for (especially the emphasis on DRY code), but all of the frameworks you mentioned have their recognized (and controversially disputed) pros and cons.
Each one is both similar and unique in varying degrees and aspects, and ultimately it's up to you to decide - Do some research; deliberate as to whether you're looking for huge libraries, a strong community, cutting-edge updates or assurances in tight documentation. Figuring out what you hope to gain from a framework is a great way of choosing the right one. But you should go for Rails anyway ;P
Good luck!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've noticed many questions on here from new programmers that can be solved using libraries. When a library is suggested, often times they respond "I don't want to use X library" Is it the learning curve? or ? Just curious!
A lot of new programmers are still working at a very low level of abstraction, learning the trade. That's something everyone has to go through. It takes a while to "move up the stack" so to speak.
Once programmers realise that they spend most of the time solving the same problems as someone else already did, and the goal is to realise "business value", then they can really appreciate the value a good library brings.
When you're still learning the ins and outs of a new language, also having to learn how to use a 3rd party library can look like too much work. Also, libraries tend to be badly documented - or at least have documentation that seems totally opaque to a new(er) programmer.
So, faced with trying to solve problem X, saying "use a library" can sound a lot like "solve problem Y THEN problem x".
(Also, their professors told them not to. I managed to get all the way though my undergrad in C++ without learning the STL existed. Boy, did THAT cook my noodle.)
Some people, when confronted with a
problem, think “I know, I'll use a
library.” Now they have two
problems.
Seriously - this is a reasonable way for a newbie, already overwhelmed by new language, programming environment, paradigms, keystrokes, etc. to react to the suggestion to use a library. If you've got a solution, but it's not working, there are many potential sources of error; sorting through them is a challenge. Adding to them can seem irrational.
"Use a library" means find the library, download it, install it in your project, and call the necessary function. Not hard, if you're used to it (and there aren't corporate policies against it, and you have reason to trust the vendor, and the library itself has minimal dependencies, etc.). But if it's all new to you, when you ask a programming question and get back a system configuration answer, it can seem unhelpful (even if it is not, in fact).
Almost always it's because their professor has told them that they can't.
Sometimes it's just because they want to learn it themselves, but I'd say that's rare.
It's the learning curve.
Using libraries is probably one of the worst things a learning programmer can do. Instead of learning how to code, they're learning how to use specific APIs that other people implemented. I'm not saying that every programmer has to understand every single thing that they use, but programmers who know the ins and outs of a computer (digital logic, assembling op-codes, etc) usually have an edge over people who've started with something like Java Swing and are just throwing together libraries.
In production, this is a different matter of course. But I think the best course of education is to 'make everything' once, at least. Writing my own web application framework from the ground up really improved my programming skills and abstract abilities. Doesn't mean I'll use that framework if someone hires me to build them an application, but I know the strengths, weaknesses, and reasons behind the things that the 'giant' frameworks use, and it can help me choose a particular framework for a particular situation.
I remember shying away from several libraries simply because I wanted to see if I could create my own algorithm. I didn't want to just give up and let someone do the work for me but rather I wanted to learn from my mistakes. Once I had come up with a solution I was happy with, I looked into the libraries.
So for me it was simply wanting to see if I could do it.
I always have this urge to do it myself, but sometimes I can see my own limitations.
Just recently downloaded a library to create PDF documents, but thats pretty much the only time I can remember.
At least for me, (trying to) do things myself, is my way of learning.
My impression is that many newbie programmers wouldn't consider it their own work if they were to use someone elses libraries.
I don't think that this is necessarily a bad thing. Using libraries is great; it saves time, effort, bugs, etc. However, you learn very little in the process, and for new programmers, learning is the goal. To answer the question, I think that they tend to shy way from libraries simply because they are not used to using them and perhaps they don't know that they exist.
For many poorly documented libraries that are either implemented loosely or in languages that don't allow you to control containment and visibility very well, it can be quite difficult to guess just how the library is supposed to be used.
After you've used it for a while, you've gotten used to the quirks or read other source code that taught you the right way; but until then it can be pretty irritating to use a poorly put-together/designed library. (or even a well designed one that isn't terribly well documented).
If you don't have the source code to the library, that's another problem--you have no control over the ability to keep your program working. This is much more rare these days, but still happens in the case of a purchased library.
Most of the points covered off (for me the main one is the learning curve) but one other I think plays a part:
Because learning about a library is less exciting than coding the same functionality yourself.
More libraries = less billable hours.
I think there's a lot of time that needs to be invested in understanding the library's purpose - yes, a learning curve, but it's more that newbie programmers probably don't know what they need until they have a lot more experience.
Because it's fun.
Because part of maturing as a developer is learning to quickly identify problems which can be solved by a library or existing solution and which need personal attention.
When you're trying to learn how to do things, anytime something is accomplished "magically" by calling AwesomeClass.doAwesomeStuff(), you end up giving away a portion of control. When you are "new" and don't know what you're giving away or why it can be unsettling. This was my primary knock against Rails when I was first learning it. So many things just "worked" and I didn't know why without digging through lots of Rails source (which I generally didn't have time to do).
At least, that's my take on it.
The same reason that more experienced developers do -
Because it can often be as difficult to learn how to use a library as to write the part of it you need yourself. And at least then you can understand how it works when it doesn't do what you expect.
An experienced developer just has experience at understanding how to use libraries so more likely to consider it. An inexperienced developer it's one more thing to learn...
I'm a programmer, not a psychologist! :)
It was a long, long time ago for me, but it was because I wanted to learn and experience. I didn't want to use something I did not understand, so if I didn't think I understood the library and could program it myself, I tried not to use it. There might have been a bit of fear too; programming gives you a feeling of control, and using a library is like giving away this control.
Answer from a noob -
"I am not sure how to use the libraries or even how to access them or how it works"
Libraries often come with the overhead of learning some API and it's paradigm. It can get complex fairly quickly, and I could easily understand that beginners would prefer something a bit more in their comfort zone. From my experience, I found most libraries & frameworks seem to do a great job abstracting some tedious routine, but when I need to either extend this functionality, or use it in a way that's not intended, it can be a handful.
I think it's one of those things where "practice makes perfect".
Well, the newbie's purpose might be more solving the problem than implementing a solution. Perhaps what they really want to do is figure out how to solve the problem. I mean, if they're still heavily in the learning phase, it's quite possible they don't want easy answers handed to them.
I think the professors want them to stick to the basics. When I graduated from under-grad school, I knew C++, Java and some other languages but had no clue about libraries and frameworks being used in companies. It was like do you know java..yes..can you write a servlet..no.
For speed demons they rarely use 3rd party libraries and new programmers are usually looking to squeeze every once of speed of of their code. I think if they don't have control over their code they can't get the performance that they are looking for. At least thats why i avoided libraries when I first started to program.
I remember programing my first DAL and avoided all the other free libraries out on the web because I wanted my code to perform at top speed. Later, I discovered that usually its not the code thats the bttleneck its actually the database.
Some open source libraries are buggy or not as efficient as others.
In my eyes another factor is that additional libraries add complexity. Programs tend to get harder to understand, harder to maintain and buggier when getting more complex. I think what makes especially new programmers shy away from libraries is that adding library code increases complexity more than adding your own code - simply because understanding how the library works is still out of their grasp. So it seems to be a problem of both skill and psychology.
I think more fundamental issues can be recognized as a deterrant to using existing libraries.
Part of this as "newbie programmers" is a lack of exposure to libraries. If you don't know they exist, how do you know to use them?
Number Of Options Available. Let's say I'm really interested in learning more about MVC, but if I have to choose between cakephp and smarty and zend and ... well you can quickly see the gears work to discover a way to achieve the goal without investing the time experimenting. Take a look at Freshmeat or SourceForge to get a better understanding at the daunting selection of libraries available.
Questionable support combined with sketchy/outdated documentation for the libraries. Do I want to use this tool that may no longer work or may be abandoned in the future? It is likely that a project will evolve, and so it will for the project of a library too. Will its usefulness last the lifetime of my project or will I be required to re-do this work again?
Using a library requires you to understand the relatively complex design of the library, something that new programmers might not have mastered because all they've ever written is simple/procedural/single-purpose code. For example, to an experienced programmer standard design patterns like template method, observer and command seem pretty obvious, but to a newbie it all just seems like magic and/or unnecessary complexity. For me the turning point was when I got good enough to grok design patterns and write some basic reusable code.
It's been a long time now, but when I came out of college, I knew nothing of libraries. This was in the days of mainframes and mini-computers. Our college had a VAX and the managers were paranoid about students hacking the system, so didn't allow us to even see the library manuals. So, when I first came out of college, I didn't even think of libraries being available.
I am sure there are a lot of reasons why the newbie doesn't want to use the new library. But wouldn't this be a good opportunity, if you have enough time, to show them what the advantage of using the library is? With the people I work with, I will usually provide an example of why something is better than their approach. It helps them learn and mature as a programmer.
Happens that noobs use Libs without knowing, but when they must import/add one that is fairly less documented, there is a fear of unknow. That happens mostly for compiled langs!
In the interpreted, (or compiled IRT), mainly when there is a console, such fear is almost non-existent; since you can require and see if it fails, call a method and see what it returns.
Consoles are tools of bravery !
I remember stumbling onto a list of basic algorithms to implement in a new language to get your head around how the language does thing, but I seem to have lost the link to it.
What simple tasks/code snippets would you recomend one undertakes to pick get a good feeling of a language?
I'm not talking developing large applications or anything the kind of things I'm thinking about are writing a linked list then extending it to a doubly linked list. Implementing various sort/search algorithms, etc.
Excercises that would help somone who knows how to program in one language get up to speed as quickly as possible in a new language.
I usually take a couple of random problems from Project Euler: http://projecteuler.net/
I like the exercises from CodeKata. They are not too easy and not too difficult. Strech your mind with them!
I really do like the problems at spoj.pl. Can be done in quite some lanuages. Yours may be one of those.
I read somewhere that creating a Blog is the HelloWorld 2.0, I saw you don't want big applications but I found worth to share this
You might try this list from JobSnake to familiarize yourself with a new programming language.
Attempting to write compiler/interpreter for it. This opens up many obscure corners of the language and also makes you understand the reasons behind features of the language.
Everytime I have/want to learn a new project, I force myself to find something to code.
But to be sure I did it well, I always want to be able to check my code and what it ouputs.
To do so, I just try to do the same kind of stuff with languages I know and to compare the outputs. For that, I created a little project (hosted on Github) with an exercise sheet and the correction for every language I learnt. It's a good way to learn in my opinion because it gives you a real little project.
I think I'm in somewhat of a unique situation: I have a decent amount of coding experience in C/C++ in a Linux environment. However, I don't really have "project experience." For example, I'm familiar with the concept of version control, but I've never used any. Or, i've never worked on a project with more than a half dozen source files.
So, where I am now is that I'm working on this project with a large amount of code already existing. I have to write all my code in a windows environment using Visual Studio 2008 (Visual C++ to be specific) So I have a few questions:
How do integrate the already existing code into VC++? I'm using tortoise SVN and I have all the code on my machine...
Does anyone have any general advice on moving from small projects to larger projects?
Any help/advice would be greatly appreciated
Some of the keys to coming to grips with a large codebase:
Learn the ins and outs of source control. For now, start with just learning how all the SVN commands work. SVNBook is a good resource for this. Use VisualSVN or a similar plugin to interact with your repository within your IDE (Tortoise is still useful when you want to interact from elsewhere). Down the road, you'll want to become intimately familiar with branching and merging (and the tools for doing so quickly and correctly), and perhaps learn a DVCS (distributed version control system) like Git or Mercurial. This will at the very least expand your mind a bit, and likely teach you some lessons that will be useful even in projects where you use more traditional (centralized) version control.
Learn how to quickly look for things, find the declarations of unfamiliar classes and variables, and trace the execution of the larger application. There are lots of approaches for this, and you'll likely use most of them at one point or another, but some of them are your IDE's built-in features (most of them are quite robust in this regard, you should be able to right-click on a class name and find its declaration easily), grep and the like (ack is a variant that is very suitable for code spelunking), and CTAGS if you swing that (C/C++) way.
Learn the basics of unit testing, maybe even try out a framework like NUnit. Personally I'm not big into unit tests, but I recognize their utility and many swear by them, so don't knock it 'til you've tried it, at least.
Even if you're a flawless programmer with a robust battery of unit tests, large codebases demand a higher level of debugging skill, due to the inherent complexity of the problems that crop up. Whether it's learning how to write concise, descriptive debug printf()-like statements, becoming more familiar with your debugger, or even learning the ins and outs of your language (e.g. the corner cases of the type system/object model) can be helpful in unwinding these complex issues.
Unfortunately, I haven't used Visual Studio, but I think getting to know your IDE's project import/migration flow will be instructive too. Maybe somebody else will chime in with more concrete advice on that front. The process can be onerous, especially if you had a non-standard custom build system before and you want everything to be done The One True Visual Studio Way henceforth, but the tools for automatic dependence extraction from code are getting better and better.
The ideas already given are very good. But you also might want to read Mike Gunderloy's Coder to Developer. From your description of your current experience, I think you'll find it useful. Also read The Pragmatic Programmer; I keep it in my office by my desk, and often find myself loaning it to younger developers.
Just dive in. Hopefully whoever has been working on this project so far organized the code into logical groups (namespaces, class hierarchies, folders).
I'll also second Matt J on learning how to use the IDE: I'm not familiar with Visual Studio specifically, but there should be contextual menu items when you click on a class or method to take you to the place where it was declared, and from there to the classes it was derived from.
Get version control set up first though: you'll feel more comfortable poking around once you learn how to "revert" ;)
I have been using VisualSVN for quite a while without problems. It integrates perfectly with vs2008. As for moving on to large projects, a great way to see how things are done is to download the source of a decent size existing project and see how it was put together. After you've got a good idea of how things are structured, the best thing you can do for yourself is to write code. Brainstorm a project and go at it. Depending on how you feel about your outcome after completion, you could use it as part of your portfolio as well.
Unit tests. Use them or you'll regret it.
Get to know Visual Studio well, if you live in it, you really have to know it well.
AnkSVN is a free plug-in for Visual Studio 2008, and it works very well.
Also, Refactor for C++ is another free plug-in and one of the only ways to get refactoring support in Visual C++.
Also, you will soon learn that on large projects, 80% of your time is going to be spent doing code maintenance, so do yourself a favour and make your code a place in which you want to live, not a place of terror that you shrink back from. Clean code, the occasional comment, and unit tests will go a long way to making you want to get up and go to work in the morning, rather than dreading that you have to work on that monstrosity where anytime you touch anything it breaks.