radiac

It's not a direct and honest way of asking people to pay for Sublime Text - it's an indirect way of asking people to continue to pay for something they thought they'd already bought.

I paid for Sublime Text 2 with the expectation of continued support of the quality we had during beta, but instead we have waited months for bug fixes which have never arrived. ST2 was essentially abandoned after it left beta, and now we find our money hasn't gone into supporting the product we paid for, it's gone into funding the next one.

As a developer I know this makes excellent business sense, but as a user it feels like I've been tricked. The changelist looks more like a point release, but one we have to pay another 50% for in the hope our bug reports will eventually be acknowledged. Given the past 6 months I have no confidence that'll happen.

Perhaps I'm being unfair - after all, I use ST2 all the time, and I've certainly got my money's worth out of it, even with the bugs - but something about this just doesn't feel right.

People who release undocumented code have no sense of social responsibility, and they are wasting everyone else's time.

The only way you can figure out if these releases do what you want is to spend half an hour trawling through the source code. Over the years I must have wasted weeks of productive time doing just that, and I can't believe I'm the only person who has.

I don't expect full API documentation and set of unit tests for every open source project - I'd be happy if most projects came with a short overview of how the code works, how it is implemented, maybe a couple of examples, and a list of its limitations. I do that for most projects I write for myself, to make it easier to come back to in a year or two when I next need to work on it.

If your project isn't worth spending an hour writing some basic documentation, then it isn't worth releasing.

Like I said, your implementation would depend on context, but to adapt my example, I'd probably put a function on the Property class to determine which Contract class to use - something like:

  contract = property.create_contract(seller, buyer, agent)
  contract.sign()

However, I think from what you're saying that your sell_property() function would need awareness of all property types, so adding a property type not only requires changes to the part of the code which contains the property data structure, but also to the sell_property() function - and any other function throughout your code base which uses properties. That is of course possible, but OO does make it easier to find where to implement logic specific to different property types.

To a certain extent it may depend on context (eg code for a conveyancing firm would have a different focus to that of a landlord or mortgage company), but a lot of those instances would already be properties of other instances. In particular, since the contract is the object which ties them all together, I would imagine the best syntax would be closer to:

  contract = new Contract(property, seller, buyer, agent)
  contract.sign()

You would then have contract.sign() call property.change_owner(), agent.register_sale() etc. Different classes of properties, buyers, sellers and agents can then implement those methods however they want.

The Contract never needs to know anything about those other classes, so you create the different types of property etc by subclassing the appropriate base class, and customising the functions that the contract calls.

Sure, OO may not be the right choice for every occasion, but it is just another way of doing things - it does not suck, it makes some things easier and some things harder. Granted, in certain languages it makes some things a lot harder - but just avoid those languages. I think a good programmer would be able to see the benefits of OO and decide whether it was the most appropriate choice for their current project, rather than dismissing the entire concept outright based on a poor understanding or bad experience in some languages.

When I was watching the demo, I couldn't help thinking how annoying GTA would get if I wrote off my car like that every time I hit something.

Realism is interesting, but like you say - it's not always going to be as much fun.

The rather unique problem that PHP has is that it is almost as if it was designed with the primary goal of encouraging the programmer to shoot themselves in the foot.

Most PHP good practices revolve around defending yourself from language features, whereas Python good practices (for example) are mostly about making sure your code is readable and easy for someone else to follow.

Ultimately people will pick the language they have most experience with, but that's not always going to be the language best suited for the task.

According to Valve: http://uk.gamespot.com/news/half-life-2-episode-one-gold-two...

Well, it's fair to say that programmers specialise, but presumably you're only working on the website, and the game developers are only working on the game. TillE was right - if you are going to implement this stuff, you should know what you're doing, or at least seek advice from people who do.

Regardless, the super meat boy developer made a pretty basic mistake, which you could perhaps defend with your argument, but he then refused to engage with someone who was reporting a vulnerability and trying to help. To me, that's pretty astounding.