hahaha yes

My comment wasn't a shot at you - I understand the exercise you were doing (which is obviously different than what you do for an interview).

Do you at least see how those two functions add no value (and a lot of harm) to the clarity of your code?

If you see:

It's very obvious what is happening.

If I see:
I have to look at the compare function to see that 'compare' actually means lessThan. I also now have an extra 5 lines in my code that don't make anything clearer. At best you'll replace "a < b" with "lessThan(a,b)" which still isn't actually clearer.

This is kind of an obvious example, but I think there's actually a lot of skill involved in figuring out when to pull out some code to a separate method. Pulling out too much can be just as bad as not pulling out enough* - and of course everybody has a different definition of 'enough'






*That's what she said.

I would laugh my ass off if the people who think mice are for suckers end up typing with two fingers

Also re: paypal, have you ever tried moneybookers? Getting anything setup in paypal is a wet dream compared to mb

I got excited when I saw this:

http://bostinnovation.com/2011/08/02...ozen-programs/

But then it turns out it isn't a solution (how to detect infinite loops) more of a clever fix

It might actually be impossible to use Emacs with only two fingers

Hmm.

That was my original question. Is it just something no one really agrees on or is it something that there is a firm standard?

This was something I wanted to ask about in the Python thread a while ago, and I forgot to ask about.

When you are creating classes, in python, you have the option to either do:

but this works:

I was messing around with them and realized they did the exact same thing. Is this nothing more than semantics?

And to segue backwards: is this something that you want to use anyways? It seems like you are stating the same general argument, and if you are, why did they add this into Python, even creating them as a special form for classes? Do you consider this a mistake in implementation?

And what about using closures instead? You're effectively doing the same thing, so why not just create objects to the functions instead of objects to the classes, then do the comparisons in the main function, or some sensible function, instead?

God, I'm not making myself too clear, am I?

"That was my original question. Is it just something no one really agrees on or is it something that there is a firm standard? "

In your lisp example, any competent programmer would agree it was bad and should be changed.

you could come up with other examples that would be a gray area though.

if you want an analogy, think of experts analyzing poker hands. though i'd say the degree of agreement is typically stronger in the case of programming.

Dave:

Instead of:

a reasonable (but still overkill) refactoring is:

Now at least you're adding some actual explanation of what the function is doing (and if you actually write the function in a reasonable way its generic enough that it could be used elsewhere).

Edit:

Off the top of my head, here are reasons for refactoring:
* To reduce the overall amount of code (usually be reusing the same set of code in multiple places).
* To add clarity to the code
* To better enable unit testing of a specific set of logic

Your refactorings of compare and andCompare fail all of those reasons.

I'm sure there's a book or blog posts that give more thorough (and well thought out) reasons for refactoring. Probably worth taking a look.

You forgot the #1 reason: to remove code duplication.

http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

The large majority of more specific design principles boil down to this.

This one is pretty huge too:

http://en.wikipedia.org/wiki/Open_Closed_Principle

That's what I meant by:

Yeah maybe I'm nitpicking but I think it's an important conceptual difference. It's not fundamentally about the amount of code (although DRY usually leads to less); it's about each part of the code doing exactly one thing, and no two parts of it doing the same thing.

Isn't the standard simply pull it out into it's own method if it's likely you are going to use it again?

Interesting listen on This American Life about patents, which deals with the computer industry. The last patent they talk about is quite frightening. Actually, the whole thing is frightening to anyone who would want to create an app or any tech business.

http://www.thisamericanlife.org/radi...patents-attack

And I also watched this video of Steve Jobs and Bill Gates together.

http://www.youtube.com/watch?v=_5Z7eal4uXI

Anyone on Microsoft BizSpark? It's amazing! If you are a startup who is involved in making some sort of Microsoft based software you can get Windows 7, SQL Server, Visual Studio 2010, Office Professional etc etc all with licenses for 3 years! It's amazing and so useful, we were worried about how we were going to afford all that stuff!

The question doesn't get easier the bigger you get...

Are infinite loops even a very common cause of crashes? I always assumed it was dereferencing null pointers.

I think during development infinite loops can be a royal PITA but software is getting better at handling them now. I don't know if they are a common cause of crashes (it's not really even a crash it's still running), I suspect not. Infinite loops are most damaging on web servers I would imagine, but again these are getting a lot better at handling stuff like that.

The puzzle of how to programatically work out if a loop is infinite or not is a fascinating one but afaik totally impossible.

First of, the method is __cmp__() not __cmpr__().

As for the existence of this method allows you write one sort implementation and use it for any object you can think of. The sort method does not need to know anything about your class for this to work, it allows you to decide what the natural ordering is. (This is also not a Python only thing, Java uses the Comparable interface to do the same thing.)

Don't think of it like a less than method that you pass in the number 1 and 2. Instead think of it as passing in to Person instances. If you wanted to sort by name, the implementation could be this:
Most of the time the implementation is not that complicated, but it is the language providing a framework to give you the freedom to do things if you want.

The documentation explains the existence __eq__() and the other operator overloads. link

I'm sick of doing decent websites for people then they come in with 'suggestions' which are laborious and bastardise the entire look and feel as well as ignore my advice for other aspects (SEO etc!) Does my head in! ARGH! Can't even use them as examples of work now because they display such huge beacons of incompetence that it's just embarrassing.

Good thing you can switch to a different field of programming and no longer have to deal with people making suggestions without understanding the consequences.

This is probably the single most common refactoring, yeah, and an important one, but not sure what you mean by standard. Sometimes you have to create a new class, sometimes turn an if/then or switch into a strategy pattern, sometimes completely restructure something and make 1 class into 3, etc, etc. I would def not say that refactoring can be boiled down to "pull out repeated and put it in its own method."

"this job would be great if it weren't for the ****ing customers."

/troll

The radio show talks about this sort of stuff. Problem is that once you deliver your product over the internet, you are breaking a patent. Once you decide to use it to make toast, you are breaking a patent. Once you.....

The software isn't the issue. Take any fully openSource company that creates all of it's own products, and they are still under the knife of patent attorneys.