Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×

Comment Re:25 to 30 feet above the trees? (Score 1) 537

A three-story house would be about 45 feet tall. If you're peeping in to windows 25-30 feet above the trees, those would be some very short trees! Something on the order of a Dogwood or Cherry tree.

NBC Washington has a picture, looks like she has oak & maple, which grow to ~60 feet. The article also puts the drone at around 75 feet in the air.

Comment Re:Shying away from OOP(s) (Score 1) 674

Actually I believe OOP is perfectly well defined:

A lot of people believe that it is well-defined. The problem, of course, is that none of them agree with one another! Let's take a look at your definition.

You have objects, either class based or prototype based, that hold data and the code that works on that data as methods or messages.

You start off by defining objects, though your definition is unusually restrictive. You exclude objects that aren't instances of of class or which have no prototype, or similar structures built in languages which don't feature classes or prototypes. This might have been unintentional on your part. You also exclude objects with only methods and objects which have no methods.

But we're not talking about objects, we're talking about Object-oriented programming. Moving on...

Such a system should support dynamic dispatched messages/methods and one or more forms of inheritance.

"Such a system" indicates that you believe that OOP classifies languages or systems within languages. You'll find that many people disagree with that, and will insist that OOP is an approach to programming not an approach to language design. There are plenty of people who believe they're doing object oriented programming in C.

To my point: OOP is so poorly defined, people can't even agree on what the term is intended to classify! Never mind the details, does it refer to programming languages or to programs? I've seen arguments for more than the two obvious responses to that question.

Now we have dynamic dispatch and inheritance. Inheritance is an easy one, as there is no general agreement here. Some go as far as to say that inheritance should never be used. There are also OO languages that do not support inheritance. Go is a nice example as it's fairly new and reasonably well-known.

I'm not exactly sure why you brought up dynamic dispatch. I don't know that I've seen anyone list it as an essential feature. I've seen people argue for and against polymorphism as an essential feature, though you don't necessarily need dynamic dispatch to achieve that either. (In Rust, for example, dynamic dispatch is the exception, most polymorphism is handled by static dispatch.) I agree that it's useful for implementing common types of object systems, I'm just not sure how it fits in to your definition of OOP.

Comment Re:Shying away from OOP(s) (Score 1) 674

Likely you just made a bad example: but examples like that simply instantly trigger the "you have not understood OO" reaction.

That's fair. My entire point is that no one understands OOP as the concept is too poorly defined. A lot of people think they understand it, naturally, though you'll find little to no agreement between them.

As for defenders and detractors: If you're a believer, you can guard against any criticism by simply saying that this or that "isn't really oop" or "they're doing it wrong". If you're a critic, there's nothing you can offer that can't immediately be disregarded. All they can hope to do is tear-down one fad or trend after another, hoping that they won't return with the next generation of OO believers.

Now with Scala and Groovy having Mixins and Java having interfaces with default implementations the question about MI is finally settled: developers want "some kind of MI".

That's a fine example. Multiple Inheritance was once thought to be essential. Later, as Java gained popularity, it was regarded as a terrible evil. Now, it's making a comeback. At each step, a lot of developers thought the question was settled. See, what is and is not popularly considered OOP changes from moment to moment.

What "mess" are you talking about?

I can't offer any answer that can't immediately be deflected with "That's not really OO" or "That's because they/you don't understand OO". It's too poorly defined a concept. Can you offer a criticism of OOP that can't be deflected in such a way? Can you even find some aspect of OOP that has remained relatively consistent over the past 20 years? Of course not. That's the point.

Comment Re:Domain modelling [Re:Shying away from OOP(s)] (Score 1) 674

Sorry for the extra reply, but this is my earlier point entirely. You both think the other "doesn't understand OOP" or is "doing it wrong".

Tablizer has quite a reputation outside of Slashdot for his thoughtful criticisms of OOP. It's difficult to claim that he doesn't understand it, as far as anyone is capable of understanding such a poorly defined concept.

Comment Re:Shying away from OOP(s) (Score 1) 674

If you hate it, you have not grasped it, plain and simple.

Yeah, here's the problem. You and everyone else already things they understand OOP and that everyone else just has it wrong. The believers will insist that any OOP failure is a failure to truly understand OOP.

The truth, of course, is that no one understands OOP because no one can agree on what constitutes OOP. The Smalltalk folks will complain about how Java and C++ got it all wrong and ruined a good thing. The Java gurus will say that they've got the one true OO language. The Self guys will say that everyone else got it wrong from the start and that classes are unnecessary and add needless complexity. Converts still using C will argue that it's not the language, but how you use it that makes something OO.

You use a simple example to sell us on OOP. Others claim that simple examples are what lead to the masses misunderstanding the true power of OOP and that you don't really see the benefits until you're working on a very large application.

The design patterns zealots will tell you that it's the first step toward true software engineering. The rest will counter that design patterns are just complicated ways to work around the flaws in C++ and Java or that patterns are just missing language features. Others will claim that they can be helpful, but that their overuse has caused nothing but harm.

Favor inheritance or composition over the other? Always use accessor methods or are they unnecessary redundancy/overhead sometimes? Was multiple inheritance a mistake, and Java got it right with single inheritance? Is inheritance a mistake entirely as it can break encapsulation, or is that an unfounded criticism?

If you can not work with OOP and/functional concepts, your mind is stuck in simple thinking, you only get around that by actually using the stuff you hate.

A lot of people hate OOP because they've used it for decades, seen the OOD fads come and go, best practices turn in to dangerous pitfalls, and other ridiculous industry trends. Now, rather than selling us on the solution that will allow us to finally reap the benefits we were promised by OOP salesman, they're selling us solutions to help us clean up the mess OOP left on the rug.

Just one more example: You've not see spaghetti until you've seen a dependency diagram on any moderately large OO project. Enter dependency injection, the solution to the problem caused by various OO fads. If you're sold on DI, or one specific framework, you'll say that it's not only necessary, but we should have been doing this all along. If you're sold on OOP and skeptical of DI, you say that DI is only necessary for those that don't understand OOP.

I can't say that I blame the anti-OOP crew. I just might be one myself. I say "might" as it really depends on what variant of OOP you've got in mind. Not that that's easy, as I don't think any one developer has a single coherent vision in mind. I suspect that if I asked 10 developers, I'd get 12+ answers.

Comment Re:Goto (Score 1) 674

Exceptions can be expensive. Far more expensive than other approaches.

There are other problems and criticisms that apply to exceptions, but that's the easiest to understand. As for elegance, you'll find exceptions in Java are very often criticized for cluttering code. You'll find countless criticisms online with a bit of searching.

Like most things, there isn't a clear "best way". Exceptions are fine sometimes, a horrible nightmare other times. Sometimes, a goto is a really good thing.

Comment Re:Waaah! (Score 2) 51

Like all skills, you get better with practice.

Any idiot can build a cabinet. The second will bet better than the first, and so on.

Any idiot can paint a house. Again, you get better as you go along.

Any idiot can cook a steak. The first few might be a bit rough, but it won't be long before their preparation is near expert.

Any idiot can code, this is true. Programming is ridiculously simple. Children can, and often do, teach themselves. You probably taught yourself when you were a preteen, like millions of other kids. If you kept at it, you got better. Like all skills, you improve with practice.

Now, ask yourself, do you really want any asshole to code for you?

Well, I wouldn't hire you, for reasons completely unrelated to your skill as a developer.

Comment Re:Here's the FCC announcement, Ethernet is broadb (Score 1) 108

Ummm... Nowhere in your link will you find anyone "defining ethernet as broadband".

Obviously at 100 Mbps, that includes ethernet.

LOL, Wut? You may want to do a bit of reading. What you've written is completely incoherent.

I'm still waiting on this: What "scientific truth" are they "redefining", exactly? Or have you finally figured out that that particular claim was absurd nonsense?

Slashdot Top Deals

NOWPRINT. NOWPRINT. Clemclone, back to the shadows again. - The Firesign Theater

Working...