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.
I'm pretty sure the core of it is to be written in Clojure, so yes, you'll need the JVM running. It is necessary if it is to be written in a JVM language. Eclipse and a number of other IDEs also require a JVM to be running.
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.
> That "interactive development" is how all lisp coder work, and is probably what the OP was referring to.
I write Clojure and Racket, and no, I don't work that way. How do you modify small chunks of templates and then check how it looks in the browser without leaving your editor, and how is that a property of lisp?
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. As far as I know, the interactive development in Common Lisp world refers to emacs-slime marriage, which apart from evaluation, enables the debugger when an error happens. I use Clojure with Vim(VimClojure). Though VimClojure can evaluate code, I don't do it using VimClojure but use tmux to send text to a clojure repl. Same goes for racket(the sending buffer to repl part). Not being dropped into a debugger automagically is a convenience, but not so much that I switch to emacs-slime.
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.
hiccup is just another approach to do html generation. This style of html generation is common in lisps - Racket uses it as well. hiccup(or this genre of templating) can be conveniently implemented in Ruby, or any language for that matter. I prefer explicit templates(particularly slim). Additionally, I don't see what I gain by the fact that I can potentially change my hiccup input, run it in the repl and see what html it produces. If the library is well tested, I won't have a need to check if it is producing html corresponding to the input list.
> Lisp is _amazing_ at processing lists, so this style of programming plays to the languages strengths.
I don't think Lisp is amazing at processing list is the reason behind this style of programming - Ruby has excellent seq abstractions(from the top of my head, I can't think of a list abstraction/method that lisp supports that Ruby doesn't). The fact that this style of programming is common is due to Lisp's s-expr syntax.
> 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.
I still see only one thing(emacs-slime drops to the debugger if evaluation fails) that lisp has extra of. Ruby, Python et al have the same feedback cycle. The things that can be interactively tested in Lisp can most probably be tested Ruby. You wrote a function which takes a sentence and qualifies it as happy/sad - irrespective of whether it's lisp or Ruby, you drop in the repl and feed it your input, or you write tests and run them. You changed your app to allow facebook login, you either interactively run it in the browser or write a test.
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.