July 10th, 2013, 04:59 AM
Which language to pursue?
First off, since this is my first post, I would like to greet everyone! ^___^
Now, I've been wondering which programming language should I pursue. I have a little experience and below basic knowledge in Python and C (took EdX's course regarding it).
I just recently figured out that I want to try a career in programming, but having problems on where to start, or how to start. Btw, this is my first programming related forum that I've joined .
So anyway, here are some details about me that might help you guys, help me find my way in the programming world.
1. I am a former professional gamer, still playing casually.
2. I love using Photoshop when I have some design ideas. My weakness, and perhaps the reason I can't pursue graphics designing is that I can't draw. I mostly just edit things out, create a background for things, layouts and such, everything aside from drawing the actual 'character'.
3. I'm a blogger at heart. I really like technology, started my own blog but haven't really been active. I like reviewing games and tech related stuffs (I don't get bored doing this).
I'm thinking about web development, but honestly, I don't know how and where to start. Thanks for reading and have a nice day!
July 10th, 2013, 05:43 AM
If you know a little Python and C then they are probably your best place to start filling in the blanks for yourself. C is universal and still the lingua franca of hackers -- from the light mages to the scary bit-twiddling black wizards. A lack of C foundation is one thing that tends to segregate those capable of systems and server platform development from those who can make things move around within a web page using this weeks Hot New Web Framework. Python is the de-facto successor to Perl in many system scripting tasks -- nearly every system utility born by Fedora/RedHat not written in C is written in Python, so its hard to go wrong there.
As for web programming Python is the language of several web frameworks and a bajillion angle-bracket markup rendering libraries (so anything that does HTML, XML, XHTML, etc.) and has bindings to every DB system I've ever encountered. Not a bad choice. As an added bonus if you know C you can write Python modules directly in C so whenever you hit a performance problem you can just profile what the problem is and if its your code and not some I/O issue you can just re-write that one part in C -- this is not an advantage to be underestimated.
Ruby is the other option in the same category as Python, but it is not as broadly useful as Python -- not that you can't do exactly the same things in it as you can in Python, but Ruby is not the choice language of system utilities on *nix systems the way Python and Perl are, so that means that if you learn Ruby you'll pretty much just be using it for web dev whereas you'll be seeing Python all over the place whether in web framework code, system-level package management systems, application/authentication servers, etc. So that's a feather in the cap of the Python.
I'd also learn something about RDBMSes. Lots of stuff on the web runs on MySQL/Maria, but nothing "serious" does. If you learn how Postgres DBAs do things and how real relational systems work then you'll be competent to manage MySQL, Oracle, DB2, or whatever. But you'll never see a MySQL admin get hired to work on a non-trivial data project involving Postgres or Oracle.
So how to do that? Get involved in, or start, a project which involves one or more of the things I mentioned above that you actually care about enough to spend the time grokking how it works inside and out.
This may sound weird, but probably one of the single most important things you can do is to read (and think about!) the following:
- The Python docs (skim over them entirely once -- that way you'll know where to reference stuff instead of asking n00b questions)
- The Postgres docs (best DB docs anywhere)
- The C Programming Language, 2nd Ed. or greater (AKA "K&R" -- actually read it and do the exercises, its not trivial but will change the way you think about programs and help you forever)
- You get a gold star if you read SICP and actually work through it -- its another foundation-forming experience.
I expect you'll do exactly zero of the things I wrote above. That's normal. So is failure in software.
After your first or second project experience you'll start seeing things in a very different way and you won't worry about what language you're using (having read through the docs for a good DB and a decent language like Python, you'll realize that most languages/platforms have utilities to handle most things you need if you just know where to find them). You'll start caring more about what community a particular type of project puts you in contact with (the communities surrounding some languages/platforms/frameworks suck). You'll also stop being afraid of refactoring/rewriting code, dealing with source control systems, etc. and mostly think of coding as a form of conceptual translation instead of coding as a part of conception itself (in most cases).
But to get there you have to learn at least one language inside and out (hence the recommendation to stick with Python and C) and usually you can't escape grown-up databases forever if you want to be a pro with any aspirations beyond the web (hence the recommendation to learn at least a little about how Postgres works).
July 10th, 2013, 07:50 AM
That was a good read!
Thank you zxq9 for those insights! I'll try to do what you suggested one by one. Starting with reading the documentation is the best to do in my case (why didn't I thought of that? LOL) so I'll have an idea on what's in my arsenal (hard to search for something that you don't know exist).
July 10th, 2013, 09:22 AM
Remember too that Python 2 and 3 are both out. Python 2 is extremely popular, but Python 3 is gaining more and more traction in the market place.
As to DBs...the open source/free ones are MySQL/MariaDB and PostGreSQL, down load them and install them and learn SQL and those dbs and you will be able to do a lot.
Perl is more of a Sys Admins language to move data.
You might also learn both Korn and Bash Shell to do things as well too.
July 10th, 2013, 10:33 PM
Except for companies like Wikipedia, Facebook, Twitter, Yahoo, PayPal, LinkedIn, etc.
Last edited by E-Oreo; July 10th, 2013 at 10:38 PM.
July 11th, 2013, 02:35 AM
Business models that could get away with trivial data models no longer can. Nothing you listed uses MySQL exclusively -- not even close. Even the services that do include a legacy MySQL core aren't running vanilla MySQL -- they've extended the bejeezus out of it to make it do things it can't out of the box. There's not a single service up there that isn't running nearly all of its internal business data on Oracle, Postgres or a network of function-passing services that are written in-house (Facebook is a prime example of that with all its Erlang stuff running the core of its messaging system).
Originally Posted by E-Oreo
Wikipedia comes the closest to being run on "real" MySQL -- and its primarily a document linker. That makes perfect sense, since that's what MySQL is optimized for (text indexing and non-ACID performance) -- not actual relational data.
The handicaps initially built into one-trivial systems (LinkedIn comes to mind) have made their backends impossible to migrate, so instead of extending their data model they have to stand up entirely new service backends that run independent of the original core, despite similarity in service. This obliterates any hope for trivial integrity checking and instead data integrity has to be checked by servlets against a variety of different DB instances instead of just being able to know the cluster has it right by default. Its a major pain to deal with stuff like that -- but I suppose it improves unemployment figures and has given rise to an entire cottage industry in how to write baroque data verification middleware...
So all that said... he's asking what to learn. I'm saying to not get comfortable with a system that can only sorta handle relational data when he could instead learn how real relational works, and then opt for MySQL in those cases where its the right tool for the job later on. I've observed that Postgres guys have very little trouble adapting to MySQL whereas MySQL folks tend to have a lot of trouble wrapping their heads around normalized data models, rewrite rule systems, data materialization, the idea that JOINs don't have to be scary, geometric indexing, range types, etc.
July 26th, 2013, 08:23 AM