After working in JavaScript for a while, I feel that the class concept is redundant and no longer required

7    20 Jun 2016 03:09 by u/prahladyeri

Do you really need a class concept to derive your objects when a function can do the same thing? In modern programming languages like JavaScript, functions are a first-class citizen. They can contain other data elements and functions that can act as properties/methods and they can also be derived from specific prototypes. Then why do we need classes at all?

17 comments

20 u/Men13 20 Jun 2016 03:50

Javascript is a horrible, messy language. It shouldn't be an example for anything.

10 u/CirdanValen 20 Jun 2016 04:17

I used to be heavy into OOP, design patterns, inheritance, etc. for years. I recently switched to purely procedural/functional programming in a adhoc way and it is SO MUCH BETTER. Structs and functions, nothing more is needed. Screw OOP. Screw UML. Screw inheritance. Screw public/private members. It all leads to really crappy, slow and inflexible code.

https://mollyrocket.com/casey/stream_0019.html

Edit: I'm not the author of the blog post, but he describes the problem and solution well

1 u/LOLATU 20 Jun 2016 06:31

You make some good points but you are kind of throwing the baby out with the bath water. No one style of programming is suited to every project. Also the inheritance diamond problem you used in your opening paragraph is a solved problem in OOP that has been discussed ad nauseum. You must have heard the phrase "composition over inheritance". Wikipedia has a good explanation if you are unclear.

1 u/CirdanValen 20 Jun 2016 14:04

Just as a side note ... I'm not the author of the blog post

0 u/J_Darnley 20 Jun 2016 21:59

What a POS website that is. The body tag has a "visibility: hidden" attribute.

0 u/express-o 21 Jun 2016 03:07

Same here. I have been developing for about 35 years. Have written code in almost all popular languages and have followed MS in all their development iterations up to WPF. I loved OOP and I loved Design Patterns. It totally satisfied my coding OCD. The problem is that these development paradigms (OOP, etc) attempt to add increasing amounts of definition and structure to something which is essentially an art form (i.e. coding is an art form).

I am not saying that structure is bad. I am saying that there is a diminishing returns on this structure. On the one hand, you have something like assembler which has the least amount of structure. In assembler, anything is possible. Code is data, data is code, and you can jump execution to anywhere you want to. One the other end, you have something like WPF which has a high amount of structure. Yes, you can have a beautiful and highly interactive datagrid which bound to a SQL server in like 3 lines of code, but trying to do anything outside of what the WPF designers originally envisioned is nearly impossible.

Where structure comes in real handy is where technologies interact. An excellent example of this is the OSI Model which defines discrete areas of functionality within a networking system. These definitions/distinctions are pretty much self-evident if you think about it and they describe a very good (the best?) way to develop networking systems. In this case, structure enables development rather than retarding it. Another good example of structure is the concept of Interfaces. An Interface is all structure and no functionality. Interfaces allow you to define how two (or more) independent pieces of code will interact. Again, this enables development.

To come back to the article you linked to ... I like this guy's "compression-oriented programming" approach. I think it shows the proper way to introduce structure into the coding process. Design Patterns are a signpost for where you want to go rather than a blueprint of how to build it. Design Patterns are what happens after you go through the process that is described in the article. I think this is probably the message/intent behind Fowler's book Refactoring to Patterns. On the other end of the spectrum, WPF is what happens when you take Design Patterns too literally and start your coding from that point of view. Also, structure begets more structure. To code with WPF you have to use additional structure in the form of one or more toolkits and frameworks to really get anything done.

Coding is a creative process. It is fun. It is satisfying, rewarding, and empowering. Coding is about solving problems and there are a multitude of proper solutions for any single problem. Probably no solution is really better or worse than any other. As long as it solves the problem efficiently, who cares? Start with a bunch of code puke which solves your problem. Then go over it again and again, refining it, touching it up, perfecting it. It's never really finished. Like any other art form (e.g. painting, sculpting, writing, etc.), coding is an iterative process without any real ending. You just end up deciding its good enough and its done. Think like water and code like the wind.

Some code has soul and some doesn't. You can tell when you run across a truly fine crafted piece of software that has some soul in it. It is unique and is a joy to use. From the UI to more technical aspects, it solves its problems in its own special way. X-plore File Manager by Lonely Cat Games on Android is (I feel) an example of this. I don't know anything about it other than I use it every once in awhile, but I can almost feel the care and attention to detail that went into building it. It wasn't just pressed out of some framework's factory and slightly modified to adapt to a specific purpose. It stands on it's own and has integrity. It's got soul.

TL;DR: Coding is an art form. Structure limits freedom. Some structure can be helpful. Think like water and code like the wind. Code can have soul.

1 u/express-o 21 Jun 2016 03:30

Same here. I have been developing for about 35 years. Have written code in almost all popular languages and have followed MS in all their development iterations up to WPF. I loved OOP and I loved Design Patterns. It totally satisfied my coding OCD. The problem is that these development paradigms (OOP, etc) attempt to add increasing amounts of definition and structure to something which is essentially an art form (i.e. coding is an art form).

I am not saying that structure is bad. I am saying that there is a diminishing returns on this structure. On the one hand, you have something like assembler which has the least amount of structure. In assembler, anything is possible. Code is data, data is code, and you can jump execution to anywhere you want to. One the other end, you have something like WPF which has a high amount of structure. Yes, you can have a beautiful and highly interactive datagrid which bound to a SQL server in like 3 lines of code, but trying to do anything outside of what the WPF designers originally envisioned is nearly impossible.

Where structure comes in real handy is where technologies interact. An excellent example of this is the OSI Model which defines discrete areas of functionality within a networking system. These definitions/distinctions are pretty much self-evident if you think about it and they describe a very good (the best?) way to develop networking systems. In this case, structure enables development rather than retarding it. Another good example of structure is the concept of Interfaces. An Interface is all structure and no functionality. Interfaces allow you to define how two (or more) independent pieces of code will interact. Again, this enables development.

To come back to the article you linked to ... I like this guy's "compression-oriented programming" approach. I think it shows the proper way to introduce structure into the coding process. Design Patterns are a signpost for where you want to go rather than a blueprint of how to build it. Design Patterns are what happens after you go through the process that is described in the article. I think this is probably the message/intent behind Fowler's book Refactoring to Patterns. On the other end of the spectrum, WPF is what happens when you take Design Patterns too literally and start your coding from that point of view. Also, structure begets more structure. To code with WPF you have to use additional structure in the form of one or more toolkits and frameworks to really get anything done.

0 u/express-o 21 Jun 2016 03:31

... continued ...

Coding is a creative process. It is fun. It is satisfying, rewarding, and empowering. Coding is about solving problems and there are a multitude of proper solutions for any single problem. Probably no solution is really better or worse than any other. As long as it solves the problem efficiently, who cares? Start with a bunch of code puke which solves your problem. Then go over it again and again, refining it, touching it up, perfecting it. It's never really finished. Like any other art form (e.g. painting, sculpting, writing, etc.), coding is an iterative process without any real ending. You just end up deciding its good enough and its done. Think like water and code like the wind.

Some code has soul and some doesn't. You can tell when you run across a truly fine crafted piece of software that has some soul in it. It is unique and is a joy to use. From the UI to more technical aspects, it solves its problems in its own special way. X-plore File Manager by Lonely Cat Games on Android is (I feel) an example of this. I don't know anything about it other than I use it every once in awhile, but I can almost feel the care and attention to detail that went into building it. It wasn't just pressed out of some framework's factory and slightly modified to adapt to a specific purpose. It stands on it's own and has integrity. It's got soul.

TL;DR: Coding is an art form. Structure limits freedom. Some structure can be helpful. Think like water and code like the wind. Code can have soul.

7 u/LOLATU 20 Jun 2016 04:23

You've been doing JavaScript so long that it has rotted your brain. What you describe is merely a less organized way of doing something resembling classes.

The bigger your application gets and the bigger the team that works on it, the more important organization becomes. There are great frameworks written in js that can help you stay organized, but js is not really superior to other languages.

It's really easy to make a big mess with it because it doesn't enforce much of anything. That's great for writing quick and dirty scripts, but when you work on a large app you need to be more careful than in other languages.

6 u/GainsGoblinGoebbels 20 Jun 2016 06:51

If you mean JS classes, you don't as they are syntactic sugar.

In JS, you generally "initialize" objects with a constructor call:

function Class(){
   this.privateProperty = 'foo';
}
var object = new Class();
console.log(object.privateProperty); // 'foo'

You generally define "methods" by augmenting the constructor prototype, as each instance of the returned object inherits from aforementioned prototype:

function Class(){
   this.privateProperty = 'foo';
}
Class.prototype = {
   fooMethod: function(append) {
      return this.privateProperty + append;
   }
}
var object = new Class();
console.log(object.fooMethod('Bar')); // 'fooBar'

You can also emulate some semblance of private/public by how you make use of arguments and function calls:

function Class(options){
   this.privateProperty = 'foo';
   this.publicProperty = options ? options.publicProperty : 'derp';
}
Class.prototype = {
   fooMethod: function(append) {
      return this.privateProperty + append;
   },
   barMethod: function(append) {
      return this.publicProperty + append;
   }
}
var foo = new Class();
var bar = new Class({publicProperty: 'Bizz'});
console.log(foo.barMethod('Buzz')); // 'derpBuzz'
console.log(bar.barMethod('Buzz')); // 'BizzBuzz';

The aforementioned examples are specific to JS though.

While they show that you essentially already have everything you need in Ecmascript-land without introducing classical inheritance or introducing syntax to encourage thinking in OOP paradigms (I'm looking at you, ES6/7 sugar), that doesn't mean that classical inheritance/OOP aren't necessary/useful/helpful in other languages.

1 u/1HepCat 20 Jun 2016 18:51

Not mine but a relevant koan:

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

0 u/Vailx 20 Jun 2016 18:23

This certainly sounds like something a javascript programmer would say...

0 u/monetus 22 Jun 2016 01:03

Just learn tcl, everything is a string.

edit: I prefer functional javascript, but oop in c++.

1 u/GainsGoblinGoebbels 22 Jun 2016 02:44

Hell yeah functional js. TLA+ semantics ftw.

0 u/dizzydog 22 Jun 2016 14:50

It's interesting you regard classes as old-fashioned. C is the first language that comes to mind when I think of imperative programming without classes and inheritance. Classes were considered the new and modern way of doing things when they were introduced with SmallTalk (I think that was the first) in 1980.

Classes are meant to be a way of providing packaging and structure, and allowing for greater code re-usability in larger code bases, but if you ask me, object-oriented over-design is a bit of cargo-cult among some Java programmers, or others who literally do not seem aware there is another way of doing things.

-3 u/TheDude2 20 Jun 2016 05:22

Because nerds