setrofim_

I am in a strange (though these days perhaps not that unusual) situation of speaking English as a second language but being more comfortable with it than with my native tongue. I was never in a primary school and was never officially taught any grammar rules. Yet to me, "red big coat" sounds as strange as it would to a native speaker.

A language is defined by its usage, and the rules/guidelines do shift with time. However, at any particular point there are definitely a "right" and a "wrong" way to construct a sentence. Therefore these rules (weak as they are) are definitely not just "opinion" that can be freely ignored. A rule defined by custom is still a rule.

[1] http://www.schneier.com/blog/archives/2013/04/sixth_movie-pl...

...I think a lot of business deals start to make more sense once you "de-gamificate" them: you show the other part that "gaming" tricks won't work in this negotiation because you're on the same level as they are on using them, so both parties can now concentrate on a compromise offer that provides the best "real value" for both!

Yes, and that's what I have a problem with. I believe (very naively, I realise) that negotiations should _start_ with trying to find the "compromise offer that provides the best "real value"". What you seem to be suggesting (if I understand you correctly) is that one should first try to con the opposing party unless they're in on the game, in which case you move on to a "proper" negotiation. Whenever I see someone trying to do that to me, my immediate impulse is to kill the negotiation and walk away right there (perhaps go try to find someone less slimy to deal with). And I do realise that this can result in me losing out and I probably wouldn't last long in business, but cheap manipulation is something I just can't stomach. I guess that's why I'm a developer and not a businessman...

Maybe the best way to "win" a negotiation is to "kill" it, i.e. turn it into something that's no longer a negotiation, where it's obvious that no one side can "win", no fucking way, so both parties can concentrate on the best possible compromise.

That pretty much has been my "tactic" in the past. I realise that this means I miss out on dealing with the "pro gamers", but, well, fuck'em.

Since the goal of a school-level course is to introduce student to programming, rather than give them knowledge immediately useful in the industry (which the student may or may not go on to work in), C# is probably not a good introductory language. Though, in this respect, it is no worse than either Java or C++ (and I suspect those end up being preferred because of tradition, and because VS licenses are expensive).

Personally, I think something like Python would make a better introductory language in schools -- it's small, clean and high level, while at the same time practical and widely used.

+1. I used to have a colleague with a pretty bad stammer. He attended speech therapy sessions during the time that we worked together and there was a huge improvement. While his speech never became 100% normal, the stammer was greatly reduced and by the end of it, he was even able to give presentations to a room full of engineers and managers. The confidence he gained form the exercises he learnt in therapy (such as taking a deep breath and exhaling into a difficult word) and from the support he received from other attendees have helped him immensely.

Speech therapy is definitely worth trying.

I see two possible scenarios:

1. They won't be. Instead, existing glyphs will become increasingly overloaded with new meanings.

2. New glyphs will start their life as icons. Once a certain icon becomes wide spread, it may be made into a code point with a glyph.

In practice, it would probably be some combination of the two.

check out http://www.readability.com/addons

Surely, that should be "good old chap", if P.G. Wodehouse taught us anything ;-)

python-forum.org and #python on irc.freenode.org for getting specific help.

Are you trying to imply that PyCon is a "boys club" and that women have no right to expect to feel comfortable being there?

Really? For me it was closer to 2 months rather than 2 years. 2 months is still a significant chunk of time to invest in learning a text editor, but given that it's one of the most used pieces of software, it's worth it.

> followed by knowing some cool tricks that you use in 1% of your daily workflow.

If that's the case, then you are not learning the right tricks. Vim has a tonne of different way of moving and editing text. Most people don't use the majority of those. Instead, they find the subset that is most useful to them and ignore the rest.

> The argument that Vim is more efficient is dubious and untestable.

It is most certainly testable. Whether or not it has been tested is another question. Is anyone aware of any serious usability studies for Vim?

> but developers are commonly on machines where the trackpad is a micro-hand movement away.

Maybe it's just me, but I find using a trackpad a lot slower than using a mouse.

> The point of a mouse is to make arbitrary on screen jumps efficient, and it’s very good at doing that. Don’t you ever think you can beat a mouse. Only in very few edge cases will it even matter.

I agree that mouse is the way to go when you want to move arbitrarily around the screen. But when programming that's rarely the case. Normally, you want to move to a specific place (a particular line, the definition of the class/function, a specific place in the document). Vim allows you to do these things efficiently.

> Consider that Vim has been around since 1991. Pathogen, the first widely used, known, and celebrated path manager making plugin management possible, was released in 2008!

This is irrelevant. The important thing that, right now, Vim has a decent way of managing plugins. Though I agree -- it's embarrassing how long it took to get there.

> Vim out of the box is awful. I can’t stress how bad of an editor vanilla Vim is. Plugins are essential to make Vim usable.

This is partly true. You definitely want to customize Vim before you use it for any serious development work. But it's not like vanilla Vim is completely unusable. I ssh into servers and edit config files and write short scripts all the time. I find that vanilla Vim is more than adequate for that. Besides it's not like setting up Vim on a new system needs to be a lot of effort -- once you have your perfect setup, just stick it on GitHub. Then configuring Vim on a new system is just a 'git clone'.

> Most Vim plugins haven’t been converted to Github projects yet. Vim Scripts acts as a featureless host, which is fine, except that it doesn’t offer any benefits. It has a nasty interface, and encourages the use of the Vim Wiki for project management

No argument here...

> Ah, Vimscript. It’s bad. And yet we’re stuck with it.

Yes, I agree. But most Vim users don't really need to deal with it, as you yourself point out:

> Most experienced Vimmers I know don’t know any Vimscript

> Finding the right Vim plugins is like being in an exclusive club. It gets better around year 2 of your journey, then worse around year 3, then…

Yup, I have to agree with this one. Though there are number of resources that recommend good plugin sets; and there things like python-mode that integrate several plugins for a specific purpose.

> Everyone remaps Leader from backslash to comma.

I don't.

> Do you know what the suggested way to work well with multiple files in Vim is? It’s the arglist.

Never used it. Fuf works pretty well for me.

> Vim Is Bad By Design™ 2: GUI

I really don't get this entire section. Vim uses a fixed width font because it is a programmer's editor, and not using fixed with fonts when writing code or editing configs is madness. If you want fancy typesetting, you're using Vim for something it wasn't designed for.

RE Vim being ugly. It kind of is out of the box. But powerline (which the post mentions) + a custom theme + a custom font solve that.

RE Vim lacking GUI. Yes that's true and that is by design. If you want a rich GUI and would prefer to use the mouse to navigate between files, select menu options etc, Vim isn't for you.

> Vim is Oddly Bad at Indenting

Indentation preferences vary wildly, even within the same language; Vim provides the tools to set up the indentation you need. I agree that out-of-the-box support for some common languages could be improved.

Vim is definitely not for every one, but for those willing to invest the effort (and it really isn't as much as this post makes it out to be), it can be a very powerful, flexible, and efficient editor. I have never used SubilmeText (though heard a lot of good things about it) so can't really comment to what it would be a better/worse alternative to Vim. This post doesn't seem to address to what extent SublimeText solves the issues outlined for Vim, and it specifically should be used instead of Vim (as opposed to Emacs, PSpad, UltraEdit, etc..)

That, in turn, gets (eventually) impacted by innovation debt.

> And do you believe this is seriously something that is killing companies left and right?

No, not at all; and I don't believe the author of the post does either. There is a whole bunch of things that can kill a company (especially a startup), and a lot of them are going to be bigger and more urgent then innovation dept. You should definitely focus on dealing with those. However, innovation dept should not be dismissed entirely, especially since it doesn't take much to offset it.

> If there is a new piece of functionality required then smart developers will simply find the tools, frameworks, libraries, they need to solve that problem. They don't need this dictated to them.

What smart developers? They have all left to work for your competitor. Besides finding the right tools, frameworks, etc takes time, which is precisely what this article is arguing for.

> Are your customers still paying? Good, get over this aspect then

Your customers will stop paying when something better comes along. And it will come along because, unlike your company, others are innovating.

> You also are inherently decreasing their productivity by teasing them with new technologies that may never be used.

Maybe, but not by as much as you'd think. Looking into new technologies may often improve productivity with the technology currently being used (by bringing in ideas from the new tech).

> What about the increased costs (real actual currency HR costs) that are included in constantly taking your resources off the software maintenance

You don't have to constantly take resources off. Just occasionally. A day-long hackathon a year, and a couple of lunchtime sessions a moth is really not that much.

> I think this idea of innovation debt is a clear non-problem for me and most web based startups in my situation.

The thing about innovation dept, like architectural debt, is that it doesn't become a problem until it is too late to do something about it.

http://xkcd.com/488/

or, less cynically, to try them out and see what interest they would generate; shutting them down when the interest was not sufficiently great.

or just use tmux

Global weather patterns come to mind. E.g. how hurricanes, tornadoes, etc. form and change. As I understand it (and I'm no expert) there is some funky math involved in modelling those, and we're not really there yet. I'm not sure if those fall under "generative processes" though.

This is contrived, admittedly, but not implausible. There are other scenarios as well. While they may all seem very unlikely, eventually contamination will occur, given how often people fly back and forth nowadays. If you keep rolling a thousand dice, eventually they will all come up sixes.