4 ms·
I'm worried by the focus on OOP in the examples. I hope that OOP is not a focus in the language. This nice and simple enough of a language that I could see JS p
by woah 12y ago
I'm worried by the focus on OOP in the examples. I hope that OOP is not a focus in the language. This nice and simple enough of a language that I could see JS people getting on board, and using this for real JS stuff.
I'm afraid that an inordinate focus on OOP will alienate JS devs, who are already good at writing in a functional style and don't need it.
The people who will appreciate the trappings of OOP are more than likely the typical classically trained programmers, who will write 300 lines of Spider on the frontend of their Python hobby project, and not touch it again.
- alongub 12y agoDefinitely not the focus! The extends/super keywords are just "shortcuts" to normal prototypal inheritance. I just thought that the time machine example was pretty cool :)
- nilliams 12y agoYep, same as CoffeeScript. All CoffeeScript's `class` stuff does is set up the prototype chain for the exact way that every JS dev under the sun does their manual prototype stuff. AFAICT you're doing the same thing you're just making it look more function-y. Not that I hate that I just think it's an incredibly minor semantic difference, and I probably slightly prefer the outright 'call it a class' approach of CoffeeScript as it feels more like calling a spade a spade.
- nilliams 12y agoCan't agree with your implication that 'real JS stuff' won't get done and 'JS people' won't get on board due to its 'focus on OOP'. I've yet to see a large JS app written in a 'functional style'. Most large client-side apps I've come across are written in Backbone, Angular, Ember etc. which are all frameworks/libraries that embrace OOP. You shouldn't mistake JavaScript's 'prototypal' nature for it being a non-OOP language. JavaScript and OOP are a very good fit. > The people who will appreciate the trappings of OOP are more than likely the typical classically trained programmers, who will write 300 lines of Spider on the frontend of their Python hobby project, and not touch it again. If you're really dismissing __all of OOP__ to that extent I feel like you are seriously misunderstanding OOP and I highly recommend you read/watch at least: - POODR by Sandi Metz [1] - Explores OOP, SOLID principles, testing, more. The best book on OOP I've ever read. Ignore the fact the code examples are in Ruby (by that I mean, they're easy to understand). - Refactoring by Martin Fowler [2] - The definitive refactoring book... which goes hand in hand with OOP. - Boundaries (Talk) by Gary Bernhardt [4]. He talks about the 'functional core, imperative shell' pattern of software architecture that acknowledges the fact that some form of OOP/procedural/imperative programming is unavoidable. It's a great talk. Outright dismissal of OOP really has no place in modern programming. Even if you get into functional languages like Clojure you'll find they're actually embracing a lot of OOP ideas [3], even though they pretend they're not into it :) [1] http://www.poodr.com http://www.poodr.com [2] http://martinfowler.com/books/refactoring.html http://martinfowler.com/books/refactoring.html [3] http://www.youtube.com/watch?v=13cmHf_kt-Q http://www.youtube.com/watch?v=13cmHf_kt-Q [4] https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries
- woah 12y agoThanks!