Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> OOP encourages adding layers of abstraction, indirection, and generic stuff [...]

Generics/templates and indirection are not OOP. Procedural style encourages them as well. You can see that in C++ itself.



C++ is OOP, though.


C++ is multi-paradigm. While people can write OOP code in C++, they can also write header-only libraries, which is generic programming. In C++ generic programming, inheritance is merely a language feature to get what you want, not the main method of abstraction.


You can do that in C, though. C++ was originally "C, with Classes", so OOP was the whole point of C++ existing in the first place.


> C++ was originally "C, with Classes", so OOP was the whole point of C++ existing in the first place

This is like describing a middle aged man based on what he did in middle school. Things evolve. C++ has. Almost to a fault where one can legitimately call it a mutation.


I understand what you are saying, but really. Programmers don't change their ways when new features get added.

I always remark that programming practices change when programmers retire, not when features get added. Most people learn these things through existing code bases, and these habits last ages into the future.

This is why most of the times, you just start using a totally new language, that way you buy into a totally new set of programmers, practices and community.


> Programmers don't change their ways when new features get added.

The good ones do.

> This is why most of the times, you just start using a totally new language, that way you buy into a totally new set of programmers, practices and community.

What happens when that new language reaches a stage where it needs new features?

I think new languages are unnecessary unless they comprehensively solve the problems of the existing ones, and don't create new ones of their own. I have always felt that creating brand new languages is more of a personal taste driven rebellion against the language one uses. When they find that its too cumbersome for their taste, or the clique in committee refuses reforms etc, those who can will go ahead and create, some evangelize successfully (I feel this is the case because I have created a few half baked languages over the years to challenge C++ lol).


No. OOP is just one aspect, but the most popular one.


I wonder how much of this mess is because people get introduced to these concepts(Generics etc) through wrong languages.

Now, there is a very similar problem with concepts like recursion. Even Algorithm, DS and problem solving in general. You never get to learn this stuff well because you get drowned in syntax juggling, type headaches, absence of good features to do recursion, first class functions, mutability, closures, pattern matching, and data handling etc well.

I find learning these things in ML or Lisp languages simplifies the problem to a great extent. You basically learn to how to solve problems and then how to use the right tools to solve the problems. Instead people chose tools that send them solving infinite sub problems to arrive at solving the real problem. Most people tune out, and rightly so. Efficiency comes after correctness in any approach. And you should never optimize for speed to begin with.

Most people getting introduced to programming in Java/C++ are generally digging through layers and layers of code trying to do what should be done simply in a straight forward way. This is often made more complicated by addition of frameworks and opinionated way of forcing people doing things in a way that requires them to go and read and work through an entire history of software literature. All the while you could just write code to solve the problem.

Design Pattern abuse is very common in OO world. And people for some reason like to write a lot of code sometimes for something as simple as writing a few lines of code.


I am self taught in C++. I learnt it when I realized my BE FORTRAN wasn't going to enable creating GUI simulation. I did have a few hiccups like any beginner but soon it was alright, so have no idea what it is like to be formally taught in class.

As for Lisp and ML, being Indian, I had no access to these, even in CS section of the library, as you might understand. Many years ago I tried learning Scheme by/after watching the lecture series. I even have the book SICP. It is fun and elegant, refreshingly so, no doubt, but only till a point. I found once we venture into necessity for conditionals & data mutation, its unbearably cumbersome - I can deal with spaghetti C code but not this - may be I am conditioned by exclusive C++ usage. I tend to think those who stick to Scheme like languages and solve real world problems do it for bravado and cry when no one is looking lol.

As for design pattern, I don't see it being exclusive to OO. Its just a bunch of ideas to build software. One would have it for assembler as well if it was used for mass production (I wonder how it was in early days when it was exclusively assembler). Its certainly poorly used and abused, agreed.


>>As for Lisp and ML, being Indian, I had no access to these, even in CS section of the library, as you might understand.

I understand being in the same situation myself.

>>I tend to think those who stick to Scheme like languages and solve real world problems do it for bravado and cry when no one is looking lol.

That's mostly because of lack of libraries and the amount of reading one has to do to learn totally new way(ironically the original way) of doing things. Data structures are linked lists(lists), stacks(lists with utility functions), queues(lists with utility functions), trees(list of lists), heaps(list of lists), graph(interconnected lists). Basically dealing with data structures is List processing, hence the name Lisp. Now since building lists using Lisp with recursion gets easier because of amazing native facilities that come with Lisp. These things just get a whole lot easier. A lot of people will tell you they see that moment of enlightenment when they learn recursion in Lisp. It just feels like the concept was always there and you discovered it neatly while work through it.

SML and its descendants are the same, additionally you get the same enlightenment with Type systems.

When you read through Lisp, and then work with DS/Algo you begin to feel, the entirety of DS/Algo work was invented, grown and perfected in a totally different set of tools and thinking philosophies and then artificially shoe horned into C languages.

In the modern context Clojure and F# come across as nice replacements. Tons of libraries and good documentation/books are available for help.

OTOH a lot of great work is done in modern incarnations of Lisp and ML. Including mission critical large software stuff. This is because of strong typing in languages like F#, and code compression using macros in Lisp. Clojure is also designed to solve a lot of big problems that effect software development at large.

One of the things I realized while working with Python after using SML. When using Python I was running a kind of buggy type inference engine in my brain, then write unit tests cases to validate it. No human should do things that can automated with a computer. That includes programming itself.

Someday people will look at type systems, macros and recursion the same way as we look at garbage collection. If a computer can do it, and it can do it better than you. It is criminal to spend human effort doing it.

This is really the digging with shovels equivalent of writing code. Let the compiler work for you.


Sounds promising. Will have to check out some time.


> As for design pattern, I don't see it being exclusive to OO. Its just a bunch of ideas to build software.

One could in fact think of monads as a design pattern for FP.


Depending on who you ask, some would say that C++ is not OOP because its encapsulation model is broken unless you use idioms such as PIMPL.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: