I have a Lenovo Thinkpad T61P. It would be a good machine except (1) the screen quality is consistent with that described in this article. Furthermore, it's developed hundreds of dead pixels. (2) The shift keys need to be hit exactly in the right place for them to work - the keyboard is a bit dodgy. (3) I had to replace the battery twice (under warranty) in a period of 6 months after buying it. I paid for quality (and was happy to based on reputation), but did not get it. It's been a very frustrating.
My day job laptop is a Dell D630. Very happy with this. My next laptop will be a Dell. The track ball on the Lenovos is much better.
I have a D630 and I agree; it is a laptop and does all the right laptop things. However: I got my wife a Dell E4300 and had many problems. Other colleagues have got other E series Dells have have had basic problems like not being able to suspend/resume under Windows and being forced to run a single core to get basic reliable operation.
I also have a D630 for work. When I am working at home and open up the downstairs HP to refer to something on a separate screen, I'm always struck by the massive difference in build quality. The HP Pavillion dv6100 feels like it's going to droop like a taffy bar when I hold it with one hand. The Dell has a good keyboard, a pointing stick, a power plug that doesn't make me worry about breaking it, and a marginally usable screen.
I'd love to see a blog post that focuses on the 'barriers exist' point. Maybe some case studies.
I guess there are a range of levels of barriers to entry, and any example of high barrier to entry I can think of implies you've already done a lot of work yourself. Very often, this might be because of a previous job / study gave you some specific valuable domain knowledge, and / or contacts (eg google).
Other times not. For example, the sydney harbour bridge climb - there high barriers to entry here, they have a monpoly! but to get that monopoly they had to put in a lot of hard work convincing the relevant authorities to let them do it.
I've been a contract software developer (in Australia) for a few years now and have been doing this via a company that I set up. Creating a company to contract through certainly creates work and (in Australia at least) there is no tax advantage in doing so - but a lot of the basics of running a company (particularly tax, insurance, accounting and director obligations) are now second nature to me. I've found this a great way to learn.
I'm getting surprising amounts of joy from Qt (via c++). It's well thought though, has proved to be fairly painless to use, and is getting very comprehensive in it's current version. Also, I love the performance.
Interestingly, I haven't got the same feeling for XAML, which I thought I would before starting to use it as there are conceptually nice things about this framework.
If it takes X characters to achieve something in language A, and X*4 to achieve the same thing in BLUB, I don't think this means BLUB is 4 times slower to develop in than A.
When I develop software, most of the big delays, and excuses for procrastination are in forcing my brain into action over the higher level concepts. I find a lot of the extra lines of code required when using BLUB can be written at high speed, with little "hurt" to the brain.
I'm not saying BLUB is just as fast to develop with, I'm just saying the benefit isn't as good as number of lines ratio good.
It's not in writing 40 lines that something like "blub" hurts, it's in reading it afterward. As long as you don't end up in Perl one liners, shorter code will tend to better highlight the relevant content (e.g., there are four keys that perform one of four things).
For me, I have found that a more concise language is easier to think in and write in. I recently worked on an application that was implemented both on the web using mostly javascript and as a desktop application in VB.Net.
One of the more complicated features I waited to implement in the web version, just because I found it rather difficult to think of the problem in VB. The javascript code was just easier to write and think in, and once implemented I could translate it to VB.
Although I do not know if there is a limit to the benefits of moving to a smaller language. Also, this is just my personal experience and I do not know how much it generalizes to other people.
I wonder. If it were only limited to the ratio of time required to type it, maybe.
But I think during the writing of the program, you type the code, review the code, look at some other code, come back to that code, so you are writing/editing/modifying a particular piece of code multiple times.
I have a superstition that there is an element of polynomial effect on the size of the resulting program on the time to get it working or to parse code written by another person.
I think change is certainly key as the catalyst for a turn around your state of mind.
That said, from my experience, I wouldn't expect to ever have an immediate, deep psychological turn around in response to any particular change, even a radical one - it always takes time. But change is key.
Some common wisdom: It's easy to be scared of change - often easier to deal with a bad situation - not even really realize it's that bad - than face the unknown. But the unknown is almost always not as bad as you think.
My day job laptop is a Dell D630. Very happy with this. My next laptop will be a Dell. The track ball on the Lenovos is much better.