241–250 of 355 posts
When I read such titles I feel sad. In 2016 we are still talking about Cobol, which is spread in a relatively niche market and considered as a pillar in fields like banking, how can the object oriented paradigm be considered " past or even bad? It is the present and will be the future for at least the next 20 years, considering the number of billions lines of code. From a management perspective, such statements are n…
Earlier quoted context omitted.
You're making a false equivalence. Functional programming has a strong basis in discrete mathematics that OOP simply does not. This makes it better suited to accurately describing computation at a high level than OOP. However, you probably arrived at this conclusion because you still see programming languages as having intrinsic paradigms and those paradigms meaning anything about computation. The fact of the matter…
You mean lambda calculus? That model has plenty of shortcomings. Someone recently pinpointed the problem for me. Complexity analysis is impossible in a system that is inherently unaware of time and computational cost of transition rules. Lambda calculus is inherently timeless (both in the theoretical sense because of turing equivalence and the practical sense of being unable to provide a proper framework for complexi…
Earlier quoted context omitted.
Totally agree. But don't forget that the real-world is pretty messy and a lot of people are not willing to think deeply about a problem. They want quick solutions. Out of the people I work with I would trust only a small percentage took the time to understand OOP. Only a few guys will take the time to understand FP. The other people pretty much just copy/paste boiler plate code.
Wow, that's depressing. I haven't had a lot of experience working with other programmers but if this is what the software industry looks like I can understand why you'd have these opinions.
OO is treated almost like a religion by some people. It's useful to be able to create instances of some things but the place OO fails is the "oriented" part. Code is much easier to maintain and understand written in a functional state. If something doesn't need to be an instance, it probably shouldn't be one. This article articulates a lot of problems I've noticed in OO code, I think it would be foolish to ignore it.…
> Code is much easier to maintain and understand written in a functional state. Why is it then that programs written in OO outnumber FP software by 100000:1 or more. For example most of the software written for iOS and macOS are written in C++, Objective C or Swift. All three are class-based object-oriented languages. What you say may not be true or may not be very important.
You are forgetting about all the spreadsheets.
Sure, the Copier has both Printer and Scanner, however, in practice, the "Start" function on a Copier differ from either -- it starts the scanner and forwards it to the printer. It might also print multiple copies.
Point being, the `start` functionality here differ from both Printer and Scanner hence, the `start` method shouldn't be inherited.
Earlier quoted context omitted.
I would argue this is inertia and a hype train that never slowed down -- up until the last 2 or so years that is. I do agree with you that thinking in FP takes a bit more experience however.
Actually, from what I've seen, pure FP forces people with less experience into design and structures of their code that they'd only do in imperative settings with considerably more experience. Eg when I asks students to do some simple exercise like "write a function that finds the shortest path through a given graph", in impure languages their solutions tend to return a path if they find one, but just give up with eg…
No doubt there ways to do it in a pure functional language -- but that requires a bit of thought. Compared to that difficulty, this business of return values seems trivial.
Worse, a language that forces people to Do The Right thing, might be acceptable for experienced programmers who want to work within that limitation. But when given to student, it just encourages closed minded rule-following.
Programming paradigms are a lot like political parties -- they tend to lump a lot of disparate things together with a weakly uniting theme. You don't need inheritance for encapsulation to be useful, for instance. The problem is, sometimes you agree with only a small part of the platform. None of these things individually are terrible ideas if tastefully applied, but it all gets clumped together into one big blob of "…
The reason why an OOP language doesn't let you have functions outside a class, may be the same with why you don't have blades on a nunchaku. You may hurt yourself.
One needs to understand the strenghts and weaknesess of each weapon, and when it's better to use it.
Earlier quoted context omitted.
There are things that are painful to express in a pure functional language. I'll give you an example: rasterize a triangle to a mutable buffer. (An inherently mutable and stateful algorithm). You can certainly do this in a purely functional language, but I doubt it will be any clearer or more performant than its procedural C counterpart. I think pure functional programming is super useful in other contexts, for insta…
While I agree, within the same context, I want to point out that right next to rasterization you have shaders, which are a poster child for functional programming. A vertex shader just transforms an input vertex (and some other inputs) into an output vertex, and a fragment shader just transforms an input fragment (and some other inputs) into an output fragment. This is done at a scale so massively parallel that we ha…
Just wanted to add that shaders lend themselves very well to the functional / dataflow paradigm. There are numerous visual node-based shader editing tools where you construct shaders from blocks, which essentially are pure functions.
Earlier quoted context omitted.
The real disadvantage of pure functional programming is that it is notoriously difficult to use and thus only very few programs outside specialized domains are written in them. For example I would guess that in a typical enterprise (say, a manufacturing company), 0.0001% of the software is written in a pure functional language. Things OO languages 'force' us seem to be relatively easy to use: sending a message to a c…
The majority of software written ever has been written in the world's most popular functional programming language: Excel.
On the other hand, if you want to make an interactive application in excel you use VBA which exposes a large and rich set of objects.