The Big Programming Thread - Page 927

On December 08 2017 06:49 TMG26 wrote:
All things considered: object oriented programming is cancer. Stick either to procedural (closer to hardware) or functional(math reliability).

On December 08 2017 08:01 Excludos wrote:


WAT... It literally revolutionised how we program, making things modular, readable, fixable and expandable. Either there's a joke I'm not getting or someone has fallen off the wagon this morning. I can only ever imagine anyone not liking OO programming have never done full stack or is just too used to their outdated ways (Yeah, I know. OO isn't exactly a new thing, so when I say outdated I really mean it)

Also, I'm not aware that you can represent data structures without OOP. At some point, even in C, you will have to refer to a struct and this is when it becomes object-oriented. Yes, C structs don't have access modifiers and stuff, but struct is still very close to OOP.

On December 08 2017 08:01 Excludos wrote:
making things modular, readable, fixable and expandable.

On December 08 2017 08:17 TMG26 wrote:

Nope.
Structs = Data representation
Objects = data + how to use that data. OOP is defining by having objects only and their only interaction is by passing 'messages'. Our so called methods. That is purest OOP.

Sure you can put mimic OOP in C by putting function pointers on structs, but that is forcing it.

How does dependency injection change whether an error is compile time vs runtime errors in the slightest?

Why does it inhibit your ability to reason about your program? I would argue the opposite, that it clarifies in the intent of your program because each dependency is explicitly laid out at a single point in your class.

//complexity = 0 (everything is contained in the function)
static T doSomething<T>(T t){
    
}

//complexity = 1 (because of I have to look at the scope of the object and my function is nested to figure something out)
class A<T>
   private T local_t;
   construct A(T t) { set local_t = t }
   T doSomething<T>(){
        val t = this.local_t
   }
}

You don't need to switch the implementation of an object to realize the benefits of dependency injection. But you can.

We use it every day, because, at the highest level, different build flavours use different implementations of the same classes. At a lower level, it allows us to switch between mock, staging and production endpoints at run-time.

This is an empty statement. Your code can always be misused. In fact, it's the other way around. Injecting allows you to establish an explicit contract that this feature will depend on this other feature. If you want to scope down a dependency, expose it as a separate interface, which can also be injected.

These two sentences contradict each other? I'm not sure what is the point being made.

There is absolutely object construction when using DI. Not sure where you get the idea that you shouldn't make objects when you have a DI framework.

In the opposite manner, people spend too much time thinking about their code and not about how it lives in the framework of the application they are writing. Once the framework is set up, DI is invisible. Annotate and put in the constructor and be done for the majority of cases, really until you want to swap implementations, which is a feature of DI, not the core.

If DI doesn't work, it's almost always that it was written with another intent in mind. Or maybe it's just wrong. Scoped DI allows you to clarify the intent of where the object lives.

On December 08 2017 15:04 Neshapotamus wrote:
I used to be an advocate of OOP, but have since lost that attitude after learning about different styles of programming. OOP is closely tied to imperative programming. Imperative programming is good for the reason that its the closest to hardware and makes code really fast. However, it comes at a disadvantage that the program is harder to reason about. My switch really came about after I learned functional programming in Scala. I am now an exponent of haskell, scala and basically any functional programming language. A lot of people who make arguments that OOP is great normally don't take the time to learn the new paradigm such as functional programming. It is fundamentally rooted in math. The way you apply math is fundamentally different than the way you write imperative code.

For ex:
Math:
x = 1
x = x + 1 ( this would be considered invalid in math)
You have been trained your whole life in math classes that the above statement is incorrect, but for some reason, in an imperative setting, this is ok? This is why I say that reasoning about imperative programs is hard.

I am sure you are all polyglot programmers. You should have all noticed how all imperative languages started adding functional concepts into their programming language.

Some examples:
C# - LINQ and lambda's, anonymous functions, anonymous classes.

Java - Java 8 introduced first class syntax for functional programming. Did you also notice that hamcrest is fully functional? Or notices that the new LocalDateTime and LocalDate classes are fully functional? Did you notice that your Mock libraries are also fully functional?

TMG26 - those quotes are great. I am going to start using them.

On December 08 2017 15:04 Neshapotamus wrote:
I used to be an advocate of OOP, but have since lost that attitude after learning about different styles of programming. OOP is closely tied to imperative programming. Imperative programming is good for the reason that its the closest to hardware and makes code really fast. However, it comes at a disadvantage that the program is harder to reason about. My switch really came about after I learned functional programming in Scala. I am now an exponent of haskell, scala and basically any functional programming language. A lot of people who make arguments that OOP is great normally don't take the time to learn the new paradigm such as functional programming. It is fundamentally rooted in math. The way you apply math is fundamentally different than the way you write imperative code.

For ex:
Math:
x = 1
x = x + 1 ( this would be considered invalid in math)
You have been trained your whole life in math classes that the above statement is incorrect, but for some reason, in an imperative setting, this is ok? This is why I say that reasoning about imperative programs is hard.

I am sure you are all polyglot programmers. You should have all noticed how all imperative languages started adding functional concepts into their programming language.

Some examples:
C# - LINQ and lambda's, anonymous functions, anonymous classes.

Java - Java 8 introduced first class syntax for functional programming. Did you also notice that hamcrest is fully functional? Or notices that the new LocalDateTime and LocalDate classes are fully functional? Did you notice that your Mock libraries are also fully functional?

TMG26 - those quotes are great. I am going to start using them.

On December 08 2017 16:09 Neshapotamus wrote:
I guess ignorance is Blisse. (sorry too ez! :p)

So, I wanted to clarify that I specifically said Dependency Injection with Inversion of Control.

Dependency Injection by itself is just another name for composition. You learn this Object-oriented programming 101. Why not just call it that instead of this fancy name?

Dependency Injection doesn't, but Inversion of Control does. Normally, when you are using IoC, you will normally have a container that will create and manage lifetimes of objects for you. This is when you will start having runtime errors. This can be a compile time error if object construction is made explicit at compile time.

Now, when you state that you have all your dependencies explicitly in one point is where I have a problem. It is much better to have your arguments at a function level, rather than at the scope of the class. When you give arguments to a function, you are basically scoping what you can use and cant use at that function. Hence it should be easier to reason about.

Mathematically, the distance I have to travel to find the scope of variables would be a good metric of complexity.

In a pure function setting, the complexity can be measured

//complexity = 0 (everything is contained in the function)
static T doSomething<T>(T t){
    
}

In an object-oriented setting

//complexity = 1 (because of I have to look at the scope of the object and my function is nested to figure something out)
class A<T>
   private T local_t;
   construct A(T t) { set local_t = t }
   T doSomething<T>(){
        val t = this.local_t
   }
}

I have arbitrarily chosen 0 and 1, but really,
object level scope = function scope + 1 (because of the 1 level of nesting)

I get this all the time, that you can pass in different implementations for testing and etc.
Yes, this is true but this is what an interface is supposed to provide. The idea is not a specific to dependency injection. The whole point of an interface is to provide a set of constraints to a type.

The idea of passing in the correct implementation at runtime is what people use IoC for. This is when things go bad. It is very accessible to pass in objects and not think about the design.

This is not a baseless statement. So to give some context, I am a tech lead for large organization, with over 4000 developers. I have both inherited code and created new code. I have lead teams as large at 30 developers to as small as 2 developers. I get to see a lot of bad code. This is the biggest problem that I see; People will misuse the DI framework and inject a dependency because its easy for them to get access to something. This usually creates a bad API design. I have seen 5 layers of nested dependencies instead of thinking about the problem differently. (Usually at the domain level)

Someone made the statement that the "new" keyword should disappear when you use DI w/ IoC

I guess we have different styles of thinking. You should think about the code and how you should compose functions and build a domain specific language.

What I would suggest is learning functional programming paradigm. It has been an eye opener for me and might do the same for you.

On December 08 2017 07:54 TMG26 wrote:
Everything. Trying to hide both hardware and math under the desguise of 'domain'. Hiding file globals under the desguise of instace variables. Promises of reusabile that were never kept. Idiot ways of handling state.
It's pros are 'easyness to understand' and 'mapping to domain' which are both full of crap. Easyness to understand is a falacy, peopele start to apply real world logic to computers which never cared about it, and don't get the realiabilty of good old math. This meme of easyness makes sure that OOP code is full of bad practices from programmers that didn't understood neither CS math concepts or the underlying hardware. And abstracting to domain is crap, you should abstract math concepts, xenturies old categories used by everyone which makes the code actually reusable, rather than looking reusable.
Old full OOP languages are full of bad legacy stuff given by the necessary OOP things of the time and ignorance of math concepts. Then there is the whole 'adding OOP stuff' to languages that never needed it.
I'm a bit drunk so I not gonna expand more. I dobhave more complains about it, and OOP is what I do for a living! I mainly devolep in Java and ruby, with some bash scripting for the whole CI/CD thing to work. All my hobby work is eiher in Haskell, C, Erlang and shell scripting though...

Here's a nice list of quotes from relevant people:
http://harmful.cat-v.org/software/OO_programming/

A warning the site is full of very extremist opinions in more than just software, something that is interesting because!it makes you think.

On December 09 2017 05:36 Manit0u wrote:


What you forgot to mention is that most software is created to be used by people and that's where OOP really shines. Procedural programming is mostly used for system level programming (people hardly interact with kernel drivers directly) and functional programming is used for highly theoretical academic stuff (math proofs) and multi-threaded/asynchronous systems (telecoms come to mind).

The vast majority of software that is being built though are applications that require user interaction (games, websites, ERP systems etc.) and those benefit greatly from this "dreadful domain approach". Sure, you probably could do it "the proper way" (like people who are trying to build website frameworks in Haskell, LOL), but you must realize that the demand for such software is so high that there's constantly a shortage of developers. If you were to raise the barrier of entry to people who have at least PhD in maths and are fluent in functional programming then nothing would get done.

It's a compromise, you get less reliable systems but can build them much easier and faster (and worry about making them reliable later down the line) because what's the most important in programming is actually getting shit done, not making sure that it's "pure" or "proper".