101–110 of 163 posts
Earlier quoted context omitted.
> OOP is not that useful for anything other than namespacing Namespacing, and modularization in general, are cornerstones of well structured code. OOP gives you nice tools to help with this.
OOP gives you tools. Having spent the last 15 years using them, I'm not convinced they are nice.
Earlier quoted context omitted.
All data types in those languages are objects.
First you said that these languages are 'OO'. Confronted with evidence that, in fact, they are multi-paradigm languages and that includes functional style you changed your argument. Now you're saying that those languages are not functional, because all the main datastructures in them are implemented as objects. Well, object models of JavaScript, Python and Ruby are vastly different and so I have to infer very wide de…
By having the data types exposed as objects, it doesn't matter what you do, because from the CS point of view you are still manipulating objects.
Even lambdas and functions are objects with some kind of invoke method.
So it is not possible to use those languages without OO, because OO is part of the language's type system.
Using CS language speak, you cannot do language semantic analysis without making use of the object semantics.
Earlier quoted context omitted.
That's not OOP, its the designers and coders. The "problem" with being the mainstream programming paradigm is that the bell curve of talent is fully stocked from high to low ends. The marketplace of managers looking for: a) cheap labor b) well-understood technology c) ability to fallback to expert knowledge grew up with object-oriented paradigms. Since OOP frameworks removed many low-level coding tasks, the cost of e…
The nice thing about a language like Haskell, then, is that you have to be really smart to use it, reducing the market for low end programmers. Actually, many companies put Haskell (or even Scala) down as a requirement just to filter out the low end programmers, they have no strong intention of actually using those languages. OO is accessible because it is much more naturalistic than FP, being based on natural metaph…
I'm living proof that you are mistaken.
>Actually, many companies put Haskell (or even Scala) down as a requirement just to filter out the low end programmers
If by "many" you mean "a couple", then it depends what you mean by "low end programmers". Asking for haskell is decent at weeding out people who have no interest in learning new things and improving themselves. It isn't particularly useful for filtering out people who aren't "really smart".
>OO is accessible because it is much more naturalistic than FP
It is interesting that you pre-suppose that is the case. My experience with teaching people programming with no prior experience is that OOP is not accessible at all, and FP comes quite naturally.
I agree with the author's conclusion "When blindly applied to problems below an arbitrary complexity threshold, OOP can be verbose and contrived" but I think he fails to recognize that the opposite is also true. Yes, it's much simpler to store RGB color in a three-element tuple when you're working on simple code that you've written all yourself. But what happens when get a tuple from somewhere containing {289, 345, -…
Earlier quoted context omitted.
> Being able to create something of a DSL and map your business rules onto basic operations on this DSL is a huge win. Hold on - how is this a concept specific to object-oriented programming? Creating a DSL for your problem domain and solving the problem in the new language is exactly what functional programmers have been doing for decades! E.g. here's a mini-DSL in Haskell for parsing CSVs, built on top of the Parse…
Of course, anything you can create abstractions with you can create a DSL of sorts. But I think most would agree that OOP is the more natural paradigm for this.
For the life of me though I can't understand why describing something accurately is deemed a waste.
Earlier quoted context omitted.
First you said that these languages are 'OO'. Confronted with evidence that, in fact, they are multi-paradigm languages and that includes functional style you changed your argument. Now you're saying that those languages are not functional, because all the main datastructures in them are implemented as objects. Well, object models of JavaScript, Python and Ruby are vastly different and so I have to infer very wide de…
My argument is still the same. By having the data types exposed as objects, it doesn't matter what you do, because from the CS point of view you are still manipulating objects. Even lambdas and functions are objects with some kind of invoke method. So it is not possible to use those languages without OO, because OO is part of the language's type system. Using CS language speak, you cannot do language semantic analysi…
Also, it seems that only languages you think worthy of being called "funtional" are various (typed or not) lambda calculi implementations?
What is Scala, then? Not functional at all, too?
Could you maybe provide a few examples of languages you'd call "functional" or "supporting functional programming paradigm"?
Earlier quoted context omitted.
The nice thing about a language like Haskell, then, is that you have to be really smart to use it, reducing the market for low end programmers. Actually, many companies put Haskell (or even Scala) down as a requirement just to filter out the low end programmers, they have no strong intention of actually using those languages. OO is accessible because it is much more naturalistic than FP, being based on natural metaph…
>The nice thing about a language like Haskell, then, is that you have to be really smart to use it I'm living proof that you are mistaken. >Actually, many companies put Haskell (or even Scala) down as a requirement just to filter out the low end programmers If by "many" you mean "a couple", then it depends what you mean by "low end programmers". Asking for haskell is decent at weeding out people who have no interest…
I'm using naturalistic here as a real term related to natural language and humanistic fuzzy thinking that we seem to be born with as opposed to the logical mathematical thinking that we must learn at school. The idea that we think (or at least most of us) in terms of objects rather than formulas biases us towards object thinking when designing systems.
Its sort of preverse, but I agree with you: its easier to teach FP to people with no programming experience, since you can focus on simple stateless computations. Without objects, you can't even broach the harder topics that teachers carelessly throw into 101 courses. But even if you are using the SICP, you'll see object thinking introduced in Chapter 3.
But now we seem to be arguing about languages, of course you can have objects in an FPL and you can have lambdas on an OOPL. The best programmers will be able to apply both of course when applicable, and won't be ideologically biased. The not so great programmers are probably better off with OOP since that's what they'll need for their jobs, though a dose of FP can help them become better programmers.
Earlier quoted context omitted.
The problem with the mutability debate is that most examples show two programs, one mutable and one immutable, on the scale of about 20 lines of code. At the small scale, it's a toss-up which is better. Often the mutable solution's more intuitive for most programmers, and sometimes just flat-out superior: more clear, easier to understand. Mutable state isn't evil. It's necessary in the real world. It's just that stat…
When you have state...I mean real state, it sure is nice to encapsulate that state in an object rather than in what is basically an unencapsulated monad. OO supports state encapsulation, pure FP basically does not, that is a big deal. Immutable programming sort of side steps the issue, that state is needed at all, that an interactive program can somehow be stateless is ridiculous, even many batch programs require som…
Earlier quoted context omitted.
The problem with the mutability debate is that most examples show two programs, one mutable and one immutable, on the scale of about 20 lines of code. At the small scale, it's a toss-up which is better. Often the mutable solution's more intuitive for most programmers, and sometimes just flat-out superior: more clear, easier to understand. Mutable state isn't evil. It's necessary in the real world. It's just that stat…
When you have state...I mean real state, it sure is nice to encapsulate that state in an object rather than in what is basically an unencapsulated monad. OO supports state encapsulation, pure FP basically does not, that is a big deal. Immutable programming sort of side steps the issue, that state is needed at all, that an interactive program can somehow be stateless is ridiculous, even many batch programs require som…
Further, since the actual state values are immutable, you can store references to them indefinitely. In most OOP languages, the whole concept of a "state at this point of execution" is completely unsupported, and that state is inaccessible to the programmer.
Edit: I wrote this assuming we're talking about a sufficiently advanced static type system here, such as Haskell's. I've implemented monads in Clojure and while they can be useful, of course in a dynamic language they provide less safety since it's trivial to escape the monad.