I've been working with each of those for ~6 years and I'd still only put myself at a 4 and if I was being generous. It's funny the longer you work with something the more you realize how little you understand it. I probably would have put myself at a 2/5 in those categories 5 years ago, but looking back, I'd rate myself at 1/5 instead.
My point was 2 months in JS != 40% knowledge of JS. If that came across as pedantic, I apologize.
Using a frequency-weighted metric, I would say that I'm 70-95% fluent (unknown unknowns make it hard to get confidence in a number) in my best languages, but I'm not an expert in any of them (and I'd only rate myself 3-3.5 on a 5-point scale, because percentage fluency on first-order concepts isn't the only important thing). I don't think it's hard to get to that point. Getting those last few percentage points is much harder.
I think most places are not like google where if you say 4 it means you invented the language.
After they answer I ask what they learned last to raise their knowledge along their scale, what they're learning now to try to grow further (if anything, sometimes you're just executing not learning,) and if the candidate is applying for Senior Software Engineer or higher what "gotchas" they typically look for in a junior coworker/employee that would be rated lower on their scale (during a code review, for example.)
I usually get really thoughtful answers and gather a lot of insight about the candidates mastery of the language, mentoring and overall thought process.
Indicators for that state of mind are actually fairly easy to spot, e.g. when you see someone quoting it without any further justification.
Particularly, if you're using a language like Haskell or Ocaml, it helps to have at least a vague idea of what a functor actually is and where the idea comes from. (I actually only realized that functors were actually similar ideas in both languages a couple days back.)
So, over all, I think understanding the background of a language really helps for complete mastery.
I could not agree more! Understanding the significance of particular keywords is quite important when failing to do so will affect your ability to successfully use the language. I distinguish that from my argument, which I premised on such knowledge not affecting one's ability to successfully use the language.
It would be great to have a standardized rating system based on a few different tiers wrt a language/framework/etc.:
1 - Wrote some really basic code in the language
5 - Wrote some really, really advanced code in the language
At one job I ended up having a lot of work writing language bindings from C to what is commonly considered a "scripting language" (TCL), so it's easy to have to deal with memory management and low level systems knowledge in relation to a scripting language (knowing the semantics of memory management within a language drastically changes how you have to write the bindings). However, the idea is to rate your skill with that particular language. No matter what the most advanced state is of a language, a 5/5 (or whatever the scale is) means that you can accomplish the most advanced task possible in the language. That doesn't mean that someone who is, say, 5/5 in Perl, will have the same skillset and capabilities as someone who is a 5/5 in AT&T syntax assembler. However, there are a list of base assumptions of skills they do have that may align with what we need as a developer when looking at resumes.
I appreciate your sympathy. I have no problem with people who are born into scripting languages. Personally I started with C, C++ and worked on few scripting languages. My question came from more of curiosity. There is more learning curve in low-level languages because the very structure of your code can affect the memory foot-print of your programs and that requires careful crafting of data-structures and algorithms. At a scripting language level you are in a virtual "world". It does allows you to SOLVE pretty advanced problems but it does not necessarily translate into your expertise in the scripting language itself. For example, I might use Ruby to create true AI system but in the end its the algorithm that mattered not my knowledge of the language.
While that can work, they miss out on all the cool and more advanced stuff these languages has to offer.
I will take your comment at face value and will answer accordingly.
First, here's a direct answer to your question: take a look at , and you will se an example use of metaprogramming.
In this file ModelBase is a metaclass, which is used to create new classes at runtime.
Also, you may have to reevaluate your definition of a scripting language. I will try to guess as to what it could mean to you currently:
A script language is interpreted, a non-script language is compiled
A script language has limited tools, a non-script language has a sizable standard library
Now you can compare the size of the C/C++ sdtlib and e.g Python, Ruby or Java. The latter ones are an order of magnitude bigger than standard C and C++.
A script language has no external library facilities, a non-script language has third party library facilities
A script language has no types, a non-script language has types
Now maybe that's because we're not declaring types and not having function/method signatures that makes it a scripting language. Really what's at play here is static vs dynamic typing. Python and Ruby are dynamically typed, while C is statically typed. But Objective-C is dynamically typed too.
A script language is used to write scripts
A script language is not written in itself, a non-script language is written in itself.
A script language has no memory management, a non-script language is low-level
So I think we have made quite a round-up of things, and hopefully enouch to demonstrate that well, while Python and Ruby are effectively able to be used (and quite efficiently so) to write scripts, they are clearly just not only "scripting languages", but full-blown, extremely advanced and potent programming languages.
The ability to modify the program at runtime (and elegantly) is a huge advantage over compiled ones and allows you to express new category of solutions.
Programs that change itself is in my opinion pretty advanced.
So it seems, Python and Ruby allows the programmer to free the mind from the low-level housekeeping and focus 100% on logical thinking and give incredible expressiveness. I would buy that.
I wonder how often an above average python/ruby programmer use its metaprogramming / reflection capabitlies?
(available as a free pdf now)
Here's the TOC:
1) Recursion and callbacks
2) Dispatch tables
3) Caching and memoization
5) From recursion to iterators
6) Infinite streams
7) Higher-order functions and currying
9) Declarative programming
There are thousands of other examples. Managing memory and low level system is not the difficult part, it's just tedious - algorithms and mapping a problem correctly is the difficult part.
at the first level, you know enough to be able to look at existing code and have some idea what's going on. (this is me with C++.)
at the second level, you know enough to write new code with real functionality and have some chance of its working. (this is me with C.)
at the third level, you have a fairly thorough understanding of most parts of the language and know idioms, common pitfalls, etc., and can fix other people's code. (this is me with q, and it was me with java seven years ago when i was working in java.)
if you want to extend this, an extra level up could be "hack", where you contribute to the language itself--modify gcc or the python interpreter or whatever. (i aspire to get to this level in q, and i think i'm close.)
not sure how to wedge a fifth level into the system....
From my own anecdote: I had an interviewer ask me about something I had listed in my resume (but not related to the job position). It made for good conversation and allowed them insight that they otherwise wouldn't have seen with a straight technical question.
Edit: Hopefully I didn't go off topic with my comment, but I also think the graphic indicator was a clever and very straightforward way of expressing experience level. It just doesn't seem very space efficient if on a paper resume.
For example, what actually quantifies 1/5 of Ruby? And does a 5/5 rating mean you know absolutely everything about it? Is 1/5 of Ruby the same as 1/5 of Python, or soldering, or speaking Icelandic?
There's also no improvement from 5/5, but even a master of their craft will know there is always room for improvement and greater mastery.
We know she's German, so she puts 5/5 in German language, as it's her native tongue. If that was the base, does that mean she's as fluent with Garageband and Logic as she is speaking?
I don't think skills are so easily quantifiable, and I'd much prefer to see a qualitative analysis of those skills. Otherwise, I'm just looking at a meaningless pattern of shaded boxes on a page.
If I were hiring this person it would take less then 10 questions about one language to figure out where her competency is according to my scale and now (assuming she didn't fudge too much) about her competencies with others (some of which I may not know).
I think the tricky bit would be making your intentions obvious.
I actually took a similar approach on my résumé: I broke my skills up into categories relative to each other rather than vying for some absolute quantification.
I'm sure many people are good (or could be good) at many unrelated activities. I had an idea of personal portfolio that would encompass all of my interests and work, too. But in the end I chose to market myself as “just” a programmer. Knowing about my proficiency in Logic or InDesign or playing piano won't help anyone looking for a programmer, and if by chance I rate my Python skill lower than InDesign or, say, OS X skill, I'm pretty sure it will turn away many paying clients.
I decided to go with discrete “brands” for various activities. Failing at that currently, though (hard to manage).
If this is true, we live in a truly depressing world. I don't understand the point of an interview any more. I sit down, lie to you for an hour, you Google the shit out of me, stalk me on Facebook. But if I tell you who I am honestly? Trash bin.
Why would you lie about yourself on an interview? An interested employer is unlikely to drop you because you are also proficient in, say, Final Cut.
The question is, how do you get to the interview?
It's simple: if a potential employer or client needs a Java programmer, they are likely to look for a “Java programmer”. Therefore, if you have a website that says “John Doe, Java programmer”, you seem more likely to get that job than if you only have a website about some John Doe that has Java listed somewhere among his multitude of skills.
Your website is probably made for other people. In that case, optimize it for other people. It seems easier for them when they can “classify” you. People who could appreciate your complex personality are your friends (and maybe family), but are they probably are outside the target audience of your website.
A few months ago I showed him a demo of my website (artJutsu.com WIP) and showed him the basics behind the code. I also showed him how to create a simple site. The dev site (on my laptop) has many different concepts that I'm still hammering out. To him it looks complex, so I told him that it doesn't have to be.
I gave him the following advice for why one does create a program. "Just think of a "simple" problem that you'd like to fix. It doesn't have to be super robust, or super smart, or super technical. Just try to solve this problem through an elegant interface."
For me, artJutsu (once I get the main part completed) will solve a variety of small problems. Yes, there are things in it that is very complicated, but that comes from research. We're in an amazing time as developers where we can access a rich array of resources just with a simple Google search. The great thing is, the simplest solution usually solves the problem just as well.
I always was the type of person that hated reading those coding books and doing lesson after lesson with very little getting done. For the most part, you don't really know WHY you need to know techniques and theory. Its just way too confusing. I find getting down and dirty building something teaches you a lot more. Theory is great, but what good is it if you don't know that you need to know it? I believe that getting your feet wet will enhance the traditional learning experience.
Anyway, after a month of coding, my friend has created a pretty good "list" site for his wife. He's at the point where its getting tough to maintain his code, but he loves it. The joy of creating a useful tool to solve a problem is what we thrive on.
Thus is the case here. http://news.ycombinator.com/item?id=4050952
However, it's impressive for a first project. I hope you stick with it.
I really doubt your classes were stupid and boring. Maybe you were the one who was stupid and boring :P
Edit: I should have included the URL for context: http://nukaco.la/maniac.html
edit: I'm having too much fun.
She's clearly very technically capable - why not introduce the site on it's own merits?
Only if you are not Icelandic. :)
The only thing that bothers me is that I can't select text... A little unnerving, actually.
Congrats to her
I remember doing "something similar" in MSX Basic about 20 years ago =)