My mother has a doctorate in social work, they have an idea in her field of "Critical Reflexivity". The idea being that theory and frameworks are vitally important to learn, but at the end of the day every case and every practitioner is different. To be a great social worker, it is not enough to learn theory and apply it, that is just the starting point. What you need to do is apply theory, but reflect at every step of the way on how it is working. This lets you build your own theory of practice, tailored to the way you work with people, and to the sort of people you work with day to day.
That resonated with me quite a bit, I feel like what she described to me is something all great developers I know do instinctually. I think at the end of the day, that constant honest reflection is the single most important thing to do for us. Our profession loves to pull ideas from math and other hard sciences, but at least from my part of it (product/business development), I think we can learn just as much from social sciences, if not more.
So what does that mean to a developer? When you see a problem somewhere, don't just stop at identifying it, try to classify it. What other problems are like it? Why did it happen in the first place? Read a lot of books about how to build software, but when you implement things from those books, try to reflect on the idea behind the solution, not just the solution. When it is done, reflect on how it worked out, and how the code looks at the end, what you like and what you don't like. If you go back to it, try to remember your initial feelings, and see how it panned out.
For me personally (working at a ruby startup in Toronto), this is the breakdown of people currently working in dev
1 white female
3 chinese canadian males
1 japanese canadian male
1 korean male
1 russian male (guess he counts as white)
3 white males
1 cuban male
We have 5 founders, only one is white, all are male. 2 are on the dev team, one is chinese (CTO), the other white
We have interviewed many, many people in the time I have been at the company, to my knowledge only two have been female, one of whom we hired.
This is normal in my experience with good shops. If I walk in the door, and it is wall to wall white guys, you are going to have a much harder time selling me on your company. This is regional, anecdotal, etc. I am not saying there is no problem, obviously there is one if we have only ever had 2 women try to get jobs at our company. But here at least, it isn't backroom racism. My guess it has a lot more to do with the boys club feel at pretty much all engineering faculties in north american universities.
I know of a handful of non white male programmers who are vocal and prominent members of the community, they exist, but they are hugely in the minority. That is the problem, what you see at conferences is a manifestation of THAT problem.
I do not know the organizers at this conference, but I know people who have been put in a similar situation, even when as organizers they are non white males. For example, Rebecca Murphy getting accused of sexism when she organizes a conference. Even when she has done way more for the cause then the people calling for her head.
As a conference organizer, you ARE put in the position of either finding token minorities, or facing a backlash. Who talks at a conf is based on who submits talks. If you end up with a situation where you have no submissions from minorities, or going on merit, the few minority submissions don't really make the cut, what do you do? It sucks for the organizers, and it sucks for the people who are asked to speak, since they never know if it is based on merit, or based on the fact that they aren't white men.
vims extensibility is a commonly cited positive, but I totally do not understand it, since pretty much every editor imaginable is extensible in similar fashion, and pretty much all of the use better languages then vim.
By contrast, emacs is basically an application platform that ships with an editor implementation, and eclipse is a platform for building editors.
It's not that vim isn't extensible, it is, just not as much as other alternatives, and nowhere near as easily as most of its competition.
IMO the real advantage of vim is that it is a highly efficient and productive tool that works great without any customization, and is available everywhere without installation. Which is pretty much the opposite of the above opinion.
The "lisp way" is to convert the problem into something solvable by lists, then convert those lists into whatever they need to be. Lisp is _amazing_ at processing lists, so this style of programming plays to the languages strengths.
>Also, I was pointing out that you don't get to define REPL to comply with what you think it should mean. I didn't say anything about interactive development.
Granted. But there is a fairly old idea that when you are working on code, it should be against a running version. Smalltalk was the ultimate expression of that, (where there is no difference between editor and app), but the typical way that a lisper works is the next best thing. When you are used to working that way, it is hard to go back, since the feedback cycle is just so tight, and exploratory coding is so simple.
When was the last time you ran your web server through erb, and modified small chunks of code, then checked how they worked without leaving your editor? I'm a professional rails dev, and for me it's "never". That "interactive development" is how all lisp coder work, and is probably what the OP was referring to.
Text objects are the core of editing though, stuff like z or all the g commands are more situational. I replace the contents of a string (ci"), delete a word (daw), copy the contents of an array (yi]), etc WAY more often then things like folding
IMO once you get past knowing the core stuff on an editor, the next frontier is scripting. If you would consider yourself advanced in vim, I would suggest starting to learn VimL
Schemaless would let you add/remove a field easily. What is hard is if you need to restructure things, which is also probably a more common occurence in a document db then a relational one. If you hit a few million rows, you are in for a world of hurt changing things in any data store
Perl and Python are both in the "pending someone mentioning something they did that noone else has done before" part of the page, they aren't considered part of the list.
That resonated with me quite a bit, I feel like what she described to me is something all great developers I know do instinctually. I think at the end of the day, that constant honest reflection is the single most important thing to do for us. Our profession loves to pull ideas from math and other hard sciences, but at least from my part of it (product/business development), I think we can learn just as much from social sciences, if not more.
So what does that mean to a developer? When you see a problem somewhere, don't just stop at identifying it, try to classify it. What other problems are like it? Why did it happen in the first place? Read a lot of books about how to build software, but when you implement things from those books, try to reflect on the idea behind the solution, not just the solution. When it is done, reflect on how it worked out, and how the code looks at the end, what you like and what you don't like. If you go back to it, try to remember your initial feelings, and see how it panned out.