|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On March 15 2012 20:35 Manit0u wrote:
From what I read about design in Java, you should avoid getters and setters at all costs. Just like you should avoid extends.
Why? Java doesn't have properties, so what is the alternative? Never allow state? Java is not a functional language...
Avoiding extends.... Again, why? "implements" is not equivalent. Inheritance is very useful.
|
On March 15 2012 20:34 MisterD wrote:funny thing, but clustering functionality is (was when i looked at it last about a year ago) horribly to control through client applications because of lacking support through the various language drivers (at least java). If you want to manage a mongodb instance as an in-application database you'll have to pipe it a ton, not fun. But well, that's not really what it was designed for. Haven't used it in it's primary use case as manually set up database for some clustered web application. Oh and also, when using from java, the lack of a proper object<->document mapping (like hibernate for o/r mapping) is a bit ugly, next time i take a shot at it i'd definitely try to see if i can marshall my objects through gson and just write them in string form to the driver, rather than trying to build a marshaller of my own that uses the java drivers DBObject api directly :X such a stupid idea
Yeah mongo is definitely made for a server -> client scenario. Pretty sexy from what I've used of it - main concern is what logic it uses to allocate space for new objects as apparently it has some sort of intelligent allocation algorithm that increases the space reserved for each new object based on the space that the largest object of its collection has used. Scary o_o Love the concept though, and it's beautiful even as just a development-only standin for the final SQL database.
Coolest thing about mongo, node and angular is that your entire application is written in JS, which is a lot more consistent and solid in my opinion (in strict mode) than most of its competition.
|
On March 15 2012 20:35 Manit0u wrote:
From what I read about design in Java, you should avoid getters and setters at all costs. Just like you should avoid extends.
The thing is, if you do a little bit more advanced design where you hide your implementations behind interfaces (cf. eclipse api for instance), you can not use anything but getters because you can't declare fields in interfaces. Also, when using field access directly, you can not compose one data object from two others because you can't defer field accesses. Using getters and setters is actually an extremly good practice if you ask me. What you should definitely try to avoid is writing the getters and setters manually, as it's just a big bunch of boilerplate code that slows down your productiveness and requires you to change 5 names instead of 1 when renaming a property. But that's what source generators like projectlomboks @Getter and @Setter annotations are made for. Using them makes life so much easier.
And extends .. you should avoid extends unless it actually extends. It's easy to write a subclass of something just because "oh well my new class needs the same four fields as my old class, so i'll just make it a subclass even though it actually isn't". That's what you need to avoid. But avoiding extends generally is a really bad idea, because it requires you to write tons of delegation boilerplate code (assuming you want to stick to "do not repeat yourself" and copy/paste every code piece 10 times, which obviously is bad) if you happen to want to reuse something. and without using extends, it simply becomes impossible to use things like the template method pattern and other patterns where you super-class is required to be an actual class and not just an interface. This stuff is often enough a lot more useful and helpful than making your classes slightly easier to understand by not having few parent classes in it's hierarchy.
|
On March 15 2012 20:47 mgj wrote:Show nested quote +On March 15 2012 20:35 Manit0u wrote:
From what I read about design in Java, you should avoid getters and setters at all costs. Just like you should avoid extends.
Why? Java doesn't have properties, so what is the alternative? Never allow state? Java is not a functional language... Avoiding extends.... Again, why? "implements" is not equivalent. Inheritance is very useful.
The alternative is public variables, which would save time if all you're doing is returning static values that you've already explicitly set through the setter. Ultimately if you have a class that consists entirely of data, straight getters and straight setters then you should re-write it as a completely public "struct equivalent" just so you can see that it was a poor choice to make it in the first place.
Basically, if your class has no invariants, what's the point of having it as a class in the first place?
|
On March 15 2012 13:11 Gogleion wrote:Show nested quote +On March 15 2012 12:53 ScruffyJanitor wrote:This may or may not have already been asked but Im at work and need to make this quick before Im found out!!  Do you have to be really amazing at maths? Math was never my strong point but Ive been interested in programming. Programming isn't heavy on math computation, but it uses a lot of problem solving skills that are very important to math.
On March 15 2012 13:06 heroyi wrote:Show nested quote +On March 15 2012 12:53 ScruffyJanitor wrote:This may or may not have already been asked but Im at work and need to make this quick before Im found out!! Do you have to be really amazing at maths? Math was never my strong point but Ive been interested in programming. no not really just simple arithmetic and maybe some statistics. You just need to be logical and have some form of critical thinking (innovative helps too).
On March 15 2012 13:46 CecilSunkure wrote:Show nested quote +On March 15 2012 12:53 ScruffyJanitor wrote:This may or may not have already been asked but Im at work and need to make this quick before Im found out!! Do you have to be really amazing at maths? Math was never my strong point but Ive been interested in programming. Nah, but game programming certainly requires a whole lot of math.
On March 15 2012 19:42 Tobberoth wrote:Show nested quote +On March 15 2012 18:55 Herper wrote:On March 15 2012 12:53 ScruffyJanitor wrote:This may or may not have already been asked but Im at work and need to make this quick before Im found out!! Do you have to be really amazing at maths? Math was never my strong point but Ive been interested in programming. Most you would need on enterprise level would be High School maths. Game programming and physics simulation would require more advance level of maths tho This. I'm terrible at math and I work fulltime as a programmer. When making games etc, you need to be able to work with vectors etc and math helps out a ton, but for making standard applications used by companies, apps for mobile phones etc, you basically need zero math... Most libraries already have all the algoritms etc you need built in, you don't need to worry about that stuff.
Here's a list of some titles of books I needed for university:
Calculus (there were two calculus courses)
Linear Algebra (there were two linear algebra courses)
Discrete Mathematics and its Applications
Abstract Algebra
Concepts in Probability and Stochastic Modeling
Introduction to Algorithms
Financial Accounting
Managerial Accounting
Those were all required courses and it is not an exhaustive list of all the courses that taught me math. Becoming a "programmer" is easy because you don't really need to understand anything except a language. If you want to pursue a degree and then a career in software engineering then you will need to learn a lot of math before you actually get a job. Depending on what job you get you might be able to forget all of that math, but the idea that you'll never "need" it is a little absurd because it's like saying "I'll just take all the easy jobs and never work in real-time systems". Your interests might lie exclusively in designing user interfaces or something, and that's fine, but without the mathematical foundation you won't have a choice.
That being said, I've never liked math either and I've done very little of it in my career so far.
|
On March 15 2012 20:47 fonger wrote:Show nested quote +On March 15 2012 20:34 MisterD wrote:On March 15 2012 20:27 fonger wrote:
MONGOOOOOOOOOODB - thoughts? funny thing, but clustering functionality is (was when i looked at it last about a year ago) horribly to control through client applications because of lacking support through the various language drivers (at least java). If you want to manage a mongodb instance as an in-application database you'll have to pipe it a ton, not fun. But well, that's not really what it was designed for. Haven't used it in it's primary use case as manually set up database for some clustered web application. Oh and also, when using from java, the lack of a proper object<->document mapping (like hibernate for o/r mapping) is a bit ugly, next time i take a shot at it i'd definitely try to see if i can marshall my objects through gson and just write them in string form to the driver, rather than trying to build a marshaller of my own that uses the java drivers DBObject api directly :X such a stupid idea Yeah mongo is definitely made for a server -> client scenario. Pretty sexy from what I've used of it - main concern is what logic it uses to allocate space for new objects as apparently it has some sort of intelligent allocation algorithm that increases the space reserved for each new object based on the space that the largest object of its collection has used. Scary o_o Love the concept though, and it's beautiful even as just a development-only standin for the final SQL database. Coolest thing about mongo, node and angular is that your entire application is written in JS, which is a lot more consistent and solid in my opinion (in strict mode) than most of its competition.
the "increases in space" thing is actually a good idea. I don't know if it does really increase to the size of the biggest document in a collection, though. The thought behind it is, that if you have like a post and it's comments stored in one document, these documents grow by a small amount every time a new comment is added. If you write a bunch of documents directly behind each other in a file and one of them grows, you'll have to take it out and write it at the end of your file because otherwise you'd have to move all the data behind it. This makes your file have huge holes and the inserted documents will be completely out of order and what not. That's why you regularly have to run OPTIMIZE TABLE on your sql databases when there's a bunch of varchars in it that get updated every now and again, because the data entries just get mixed out of order.
So mongodb, where every document is basically just a big varchar, so the effect becomes really bad, analyzes your document behavior and will notice "oh, documents here usually get bigger after a while". Then it just allocates more space than the objects actual size, so that you can add a few comments before it become to big for the slot where it was created in, which in the end should save your machine a lot of work. But as stated, i can't tell you how big it makes them or whatever, i don't know the concrete implementation. Just the basic idea.
|
On March 15 2012 20:35 Manit0u wrote:
From what I read about design in Java, you should avoid getters and setters at all costs. Just like you should avoid extends.
If you plan to avoid get and set methods then you'll be avoiding a standard so far-reaching that it is done automatically by many IDEs. People avoid it when the length of their class makes them upset. I can't think of another good reason.
As for extends there are some languages in which inheritance of that kind no longer exists, but that does not mean it should be avoided.
On March 15 2012 20:51 fonger wrote:Show nested quote +On March 15 2012 20:47 mgj wrote:On March 15 2012 20:35 Manit0u wrote:
From what I read about design in Java, you should avoid getters and setters at all costs. Just like you should avoid extends.
Why? Java doesn't have properties, so what is the alternative? Never allow state? Java is not a functional language... Avoiding extends.... Again, why? "implements" is not equivalent. Inheritance is very useful. The alternative is public variables, which would save time if all you're doing is returning static values that you've already explicitly set through the setter. Ultimately if you have a class that consists entirely of data, straight getters and straight setters then you should re-write it as a completely public "struct equivalent" just so you can see that it was a poor choice to make it in the first place. Basically, if your class has no invariants, what's the point of having it as a class in the first place?
By doing that you're violating any number of abstraction principles and will probably wind up with UI code dependent on implementation.
|
On March 15 2012 20:54 MisterD wrote:Show nested quote +On March 15 2012 20:47 fonger wrote:On March 15 2012 20:34 MisterD wrote:On March 15 2012 20:27 fonger wrote:
MONGOOOOOOOOOODB - thoughts? funny thing, but clustering functionality is (was when i looked at it last about a year ago) horribly to control through client applications because of lacking support through the various language drivers (at least java). If you want to manage a mongodb instance as an in-application database you'll have to pipe it a ton, not fun. But well, that's not really what it was designed for. Haven't used it in it's primary use case as manually set up database for some clustered web application. Oh and also, when using from java, the lack of a proper object<->document mapping (like hibernate for o/r mapping) is a bit ugly, next time i take a shot at it i'd definitely try to see if i can marshall my objects through gson and just write them in string form to the driver, rather than trying to build a marshaller of my own that uses the java drivers DBObject api directly :X such a stupid idea Yeah mongo is definitely made for a server -> client scenario. Pretty sexy from what I've used of it - main concern is what logic it uses to allocate space for new objects as apparently it has some sort of intelligent allocation algorithm that increases the space reserved for each new object based on the space that the largest object of its collection has used. Scary o_o Love the concept though, and it's beautiful even as just a development-only standin for the final SQL database. Coolest thing about mongo, node and angular is that your entire application is written in JS, which is a lot more consistent and solid in my opinion (in strict mode) than most of its competition. the "increases in space" thing is actually a good idea. I don't know if it does really increase to the size of the biggest document in a collection, though. The thought behind it is, that if you have like a post and it's comments stored in one document, these documents grow by a small amount every time a new comment is added. If you write a bunch of documents directly behind each other in a file and one of them grows, you'll have to take it out and write it at the end of your file because otherwise you'd have to move all the data behind it. This makes your file have huge holes and the inserted documents will be completely out of order and what not. That's why you regularly have to run OPTIMIZE TABLE on your sql databases when there's a bunch of varchars in it that get updated every now and again, because the data entries just get mixed out of order. So mongodb, where every document is basically just a big varchar, so the effect becomes really bad, analyzes your document behavior and will notice "oh, documents here usually get bigger after a while". Then it just allocates more space than the objects actual size, so that you can add a few comments before it become to big for the slot where it was created in, which in the end should save your machine a lot of work. But as stated, i can't tell you how big it makes them or whatever, i don't know the concrete implementation. Just the basic idea.
I agree on the importance of expanding to meet the projected needs of the next object, but it's not transparent enough. If I have a million 20-byte records and one 1000-byte record in the same collection then (depending on the inner workings) this could create a serious problem.
SQL databases are much more easily controlled as you can't arbitrarily add extra fields to a given object and in most cases each field has a pre-defined limit.
That said Mongo is very cool; I just think it's easy to shoot yourself in the foot with xD
|
On March 15 2012 20:59 lolmlg wrote:Show nested quote +On March 15 2012 20:51 fonger wrote:On March 15 2012 20:47 mgj wrote:On March 15 2012 20:35 Manit0u wrote:
From what I read about design in Java, you should avoid getters and setters at all costs. Just like you should avoid extends.
Why? Java doesn't have properties, so what is the alternative? Never allow state? Java is not a functional language... Avoiding extends.... Again, why? "implements" is not equivalent. Inheritance is very useful. The alternative is public variables, which would save time if all you're doing is returning static values that you've already explicitly set through the setter. Ultimately if you have a class that consists entirely of data, straight getters and straight setters then you should re-write it as a completely public "struct equivalent" just so you can see that it was a poor choice to make it in the first place. Basically, if your class has no invariants, what's the point of having it as a class in the first place? By doing that you're violating any number of abstraction principles and will probably wind up with UI code dependent on implementation.
Yeah mate but you're missing my point. I'm not suggesting that anything should be a POD public object; I'm pointing out that adding private variables and dumb set/get routines to any given class does not make it correct and "object-oriented." If you end up with one of those, you're doing it wrong.
A vector is a prime example. A decreasing number of purists insist on getX() and getY() where .x and .y are obviously far superior as there are NO invariants (exception being a normalised vector class which is very iffy in any case as vector operations are generally in performance-intensive blocks).
Simply put, there is no advantage to .getA()/.setA() over .a unless "a" has some state that should be monitored and controlled.
EDIT: except in case of possible extensibility in which case (my opinion) you should be using an interface anyway and be prepared for all the relevant performance costs.
|
What are people's thoughts on building HTML server side vs building HTML using javascript?
option 1) Return an JSON object containing data from your server and then use javascript to build up the HTML tags.
option 2) Build up the view on the server and return HTML back to the client.
This is mainly for ajax requests. (Using ASP.net MVC, not that it would matter).
|
Increased client-side performance, increased bandwidth used, decreased maintainability of any AJAX-type code for the server-side-generated-HTML approach. Vice-versa for the other one 
EDIT: look up AngularJS!
|
On March 15 2012 21:11 Highways wrote:
What are people's thoughts on building HTML server side vs building HTML using javascript?
option 1) Return an JSON object containing data from your server and then use javascript to build up the HTML tags.
option 2) Build up the view on the server and return HTML back to the client.
This is mainly for ajax requests. (Using ASP.net MVC, not that it would matter).
you could argue that your main site should be generated server side to be compatible with users who have javascript disabled. onclick-AJAX updates or things like that are probably better generated client side, as these can only be executed if javascript is enabled anyways, and you can lessen performance requirements of your server and traffic requirements of server and client, while at the same time keeping the server output easier machine-readable should you decide to use it for something else at some point in the future.
(disclaimer: haven't done web programming in ages, just some guesswork from the top of my head. Might be wrong since not backed by any specific experiences on the matter, just feels sound to me.)
|
On March 15 2012 20:59 lolmlg wrote:Show nested quote +On March 15 2012 20:35 Manit0u wrote:
From what I read about design in Java, you should avoid getters and setters at all costs. Just like you should avoid extends.
If you plan to avoid get and set methods then you'll be avoiding a standard so far-reaching that it is done automatically by many IDEs. People avoid it when the length of their class makes them upset. I can't think of another good reason. As for extends there are some languages in which inheritance of that kind no longer exists, but that does not mean it should be avoided. Show nested quote +On March 15 2012 20:51 fonger wrote:On March 15 2012 20:47 mgj wrote:On March 15 2012 20:35 Manit0u wrote:
From what I read about design in Java, you should avoid getters and setters at all costs. Just like you should avoid extends.
Why? Java doesn't have properties, so what is the alternative? Never allow state? Java is not a functional language... Avoiding extends.... Again, why? "implements" is not equivalent. Inheritance is very useful. The alternative is public variables, which would save time if all you're doing is returning static values that you've already explicitly set through the setter. Ultimately if you have a class that consists entirely of data, straight getters and straight setters then you should re-write it as a completely public "struct equivalent" just so you can see that it was a poor choice to make it in the first place. Basically, if your class has no invariants, what's the point of having it as a class in the first place? By doing that you're violating any number of abstraction principles and will probably wind up with UI code dependent on implementation.
Why getters, setters and extends are evil.
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
According to this even Java creator is upset with extends and if he were to re-write Java he'd get rid of classes entirely.
|
On March 15 2012 20:47 fonger wrote:Show nested quote +On March 15 2012 20:34 MisterD wrote:On March 15 2012 20:27 fonger wrote:
MONGOOOOOOOOOODB - thoughts? funny thing, but clustering functionality is (was when i looked at it last about a year ago) horribly to control through client applications because of lacking support through the various language drivers (at least java). If you want to manage a mongodb instance as an in-application database you'll have to pipe it a ton, not fun. But well, that's not really what it was designed for. Haven't used it in it's primary use case as manually set up database for some clustered web application. Oh and also, when using from java, the lack of a proper object<->document mapping (like hibernate for o/r mapping) is a bit ugly, next time i take a shot at it i'd definitely try to see if i can marshall my objects through gson and just write them in string form to the driver, rather than trying to build a marshaller of my own that uses the java drivers DBObject api directly :X such a stupid idea Yeah mongo is definitely made for a server -> client scenario. Pretty sexy from what I've used of it - main concern is what logic it uses to allocate space for new objects as apparently it has some sort of intelligent allocation algorithm that increases the space reserved for each new object based on the space that the largest object of its collection has used. Scary o_o Love the concept though, and it's beautiful even as just a development-only standin for the final SQL database. Coolest thing about mongo, node and angular is that your entire application is written in JS, which is a lot more consistent and solid in my opinion (in strict mode) than most of its competition.
MongoDB is just a document oriented database, its not really made for anything. Given the way we use database these days it is much more efficient to do it this way. However a great side effect is that we are no longer stuck into schema's.
NodeJS requires the use of concurrency driven design, I've tried making real apps with it and its an architecture that is only really suitable for a very specific type (web/servers). Be prepared to write things at less than half the rate you are used to. If you are writing stuff imperatively then you are not doing it right and not only will your app not work properly with more than a few users, you will not reap the benefits that NodeJS provides.
IMO its going to be a major setback to its ability to grow as most people who build websites use languages that allow you to create things in the shortest time possible. We don't care about performance as much because its so easy and cheap to add extra hardware to a webserver. So why the sudden backflip with NodeJS?
I probably would be pretty content with using Node for game servers though.
On March 15 2012 21:22 Manit0u wrote:Show nested quote +On March 15 2012 20:59 lolmlg wrote:On March 15 2012 20:35 Manit0u wrote:
From what I read about design in Java, you should avoid getters and setters at all costs. Just like you should avoid extends.
If you plan to avoid get and set methods then you'll be avoiding a standard so far-reaching that it is done automatically by many IDEs. People avoid it when the length of their class makes them upset. I can't think of another good reason. As for extends there are some languages in which inheritance of that kind no longer exists, but that does not mean it should be avoided. On March 15 2012 20:51 fonger wrote:On March 15 2012 20:47 mgj wrote:On March 15 2012 20:35 Manit0u wrote:
From what I read about design in Java, you should avoid getters and setters at all costs. Just like you should avoid extends.
Why? Java doesn't have properties, so what is the alternative? Never allow state? Java is not a functional language... Avoiding extends.... Again, why? "implements" is not equivalent. Inheritance is very useful. The alternative is public variables, which would save time if all you're doing is returning static values that you've already explicitly set through the setter. Ultimately if you have a class that consists entirely of data, straight getters and straight setters then you should re-write it as a completely public "struct equivalent" just so you can see that it was a poor choice to make it in the first place. Basically, if your class has no invariants, what's the point of having it as a class in the first place? By doing that you're violating any number of abstraction principles and will probably wind up with UI code dependent on implementation. Why getters, setters and extends are evil. http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.htmlhttp://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
Or you could just combine all of these articles and put it under "Why Java is evil".
I've been seriously rofling at all these silly design patterns that java developers have created to get around the limitations of Java. "interfaces over implementation", "why extends is evil", etc, etc. Everyone trying to follow Dijkstra's style of 'goto statement considered harmful' yet failing because instead of coming up with a solution (Pascal) they just side-step the real issue.
I mean yes, I do implement Java in this way (no extends, lots of interfaces for flexibility), but not because its good, its because Java is bad. Trust me, I bought into this shit when I was in my teens, how naive I was.
Hence I pretty much wouldn't touch Java with a 10 foot pole. The only time I do is with JRuby, except its just Ruby translated to Java bytecode so I can use Java libraries.
The whole getter and setter issue can be much better explained with Responsibility Driven Design. Getters and setters aren't evil, don't be ridiculous, its just that writing getters and setter methods is a nonsensical abstraction and causes code bloat. Nothing does my head in more than seeing a class with attributes and then get() set() methods for everything, causing the class to be about 100x bigger than it needs to be. However there are some times where you will need to write a getter and setter.
Responsibility Driven Design teaches you how to name classes (or classifications) and methods, what methods mean, and how to properly abstract real business models into object oriented code, when to use extends, etc. It takes a long time to learn, but after a while it should click and a lot of the mysteries of OOP will start to make complete sense. Until then you are simply throwing darts with a blindfold on and listening to morons telling you why things are evil.
|
On March 15 2012 21:22 Manit0u wrote:Show nested quote +On March 15 2012 20:59 lolmlg wrote:On March 15 2012 20:35 Manit0u wrote:
From what I read about design in Java, you should avoid getters and setters at all costs. Just like you should avoid extends.
If you plan to avoid get and set methods then you'll be avoiding a standard so far-reaching that it is done automatically by many IDEs. People avoid it when the length of their class makes them upset. I can't think of another good reason. As for extends there are some languages in which inheritance of that kind no longer exists, but that does not mean it should be avoided. On March 15 2012 20:51 fonger wrote:On March 15 2012 20:47 mgj wrote:On March 15 2012 20:35 Manit0u wrote:
From what I read about design in Java, you should avoid getters and setters at all costs. Just like you should avoid extends.
Why? Java doesn't have properties, so what is the alternative? Never allow state? Java is not a functional language... Avoiding extends.... Again, why? "implements" is not equivalent. Inheritance is very useful. The alternative is public variables, which would save time if all you're doing is returning static values that you've already explicitly set through the setter. Ultimately if you have a class that consists entirely of data, straight getters and straight setters then you should re-write it as a completely public "struct equivalent" just so you can see that it was a poor choice to make it in the first place. Basically, if your class has no invariants, what's the point of having it as a class in the first place? By doing that you're violating any number of abstraction principles and will probably wind up with UI code dependent on implementation. Why getters, setters and extends are evil. http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.htmlhttp://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.htmlAccording to this even Java creator is upset with extends and if he were to re-write Java he'd get rid of classes entirely.
i read over the extends article. The guy is partly right, all the examples he lists are absolutely stupid ways of using extends. But that doesn't make extends "evil", that just makes people using it this way evil. Of course you shouldn't write your own stack class as a subclass of arraylist, because you offer a ton of methods that you don't want your clients to have access to. And of course you shouldn't write "i need a linked list" if all you need is an iterable. But that doesn't make extends bad.
For instance: In our software, we have an abstract superclass of all UI-Accessible actions, that basically employs the template pattern and makes sure that no exceptions, runtime or otherwise, slip out into the UI event thread unnoticed. Basically it just does run(){try{runUnsafe();}catch(Exception e) {log(e);}. Using something like this without extends is simply impossible, because you'd then have to put runUnsafe() not as an abstract method but as a delegated interface method. When doing this, it increases the amount of boilerplate code that you have to write in the class itself and everywhere you use it (new ExceptionSafeAction(new ConcreteDelegateAction())) tenfold, that's just not a responsible thing to do.
So the right thing to do is not to conclude "extends is evil", but only to use extends when a) it's actually a valid relationship between classes (e.g. a stack is not an arraylist, but a "delete this object action" is an exception-safe action), and b) only use extends on classes, that are supposed to be extended. Again, cf. eclipse API: Every class in there has @NoExtend annotations if you are not supposed to extend it.
Sure, it would be nice if everyone would just had the experience to know where to extend and where not to extend, but that's not realistic. So, you have to give them guidelines. For instance, @NoExtend is a good way to say "you usually should not subclass this!". Saying "never use extends" works too, to keep people from using extends, but it's not a good guideline, because extends does have it's justifications and proper places to be used.
|
On March 15 2012 21:34 sluggaslamoo wrote:Show nested quote +On March 15 2012 20:47 fonger wrote:On March 15 2012 20:34 MisterD wrote:On March 15 2012 20:27 fonger wrote:
MONGOOOOOOOOOODB - thoughts? funny thing, but clustering functionality is (was when i looked at it last about a year ago) horribly to control through client applications because of lacking support through the various language drivers (at least java). If you want to manage a mongodb instance as an in-application database you'll have to pipe it a ton, not fun. But well, that's not really what it was designed for. Haven't used it in it's primary use case as manually set up database for some clustered web application. Oh and also, when using from java, the lack of a proper object<->document mapping (like hibernate for o/r mapping) is a bit ugly, next time i take a shot at it i'd definitely try to see if i can marshall my objects through gson and just write them in string form to the driver, rather than trying to build a marshaller of my own that uses the java drivers DBObject api directly :X such a stupid idea Yeah mongo is definitely made for a server -> client scenario. Pretty sexy from what I've used of it - main concern is what logic it uses to allocate space for new objects as apparently it has some sort of intelligent allocation algorithm that increases the space reserved for each new object based on the space that the largest object of its collection has used. Scary o_o Love the concept though, and it's beautiful even as just a development-only standin for the final SQL database. Coolest thing about mongo, node and angular is that your entire application is written in JS, which is a lot more consistent and solid in my opinion (in strict mode) than most of its competition. MongoDB is just a document oriented database, its not really made for anything. Given the way we use database these days it is much more efficient to do it this way. However a great side effect is that we are no longer stuck into schema's. NodeJS uses concurrency driven design, I've tried making real apps with it and its an architecture that is only really suitable for a very specific type (web/servers). Be prepared to write things at less than half the rate you are used to. IMO its going to be a major setback to its ability to grow as most people who build websites use languages that allow you to create things in the shortest time possible. We don't care about performance as much because its so easy and cheap to add extra hardware to a webserver.
Web apps are concurrent by nature. Expressing this concurrency by interaction in a well-defined fashion is what Node excels at. There is to my knowledge no other server software that allows this as naturally as Node.
I disagree with your point about writing things at half the rate you're used to. If you have any experience with multi-threading in another language, Node will make perfect sense and in fact be a pleasant surprise.
|
On March 15 2012 21:34 sluggaslamoo wrote:
If you are writing stuff imperatively then you are not doing it right and not only will your app not work properly with more than a few users, you will not reap the benefits that NodeJS provides.
Where the fuck did that come from?
IMO its going to be a major setback to its ability to grow as most people who build websites use languages that allow you to create things in the shortest time possible. We don't care about performance as much because its so easy and cheap to add extra hardware to a webserver. So why the sudden backflip with NodeJS?
What backflip? Node's built to be easily scalable horizontally, which very obviously captitalises on cheap hardware.
I probably would be pretty content with using Node for game servers though.
Performance, the same reason you'd use Node for any web app. Have you ever written a game server before?
|
On March 15 2012 21:47 fonger wrote:Show nested quote +On March 15 2012 21:34 sluggaslamoo wrote:On March 15 2012 20:47 fonger wrote:On March 15 2012 20:34 MisterD wrote:On March 15 2012 20:27 fonger wrote:
MONGOOOOOOOOOODB - thoughts? funny thing, but clustering functionality is (was when i looked at it last about a year ago) horribly to control through client applications because of lacking support through the various language drivers (at least java). If you want to manage a mongodb instance as an in-application database you'll have to pipe it a ton, not fun. But well, that's not really what it was designed for. Haven't used it in it's primary use case as manually set up database for some clustered web application. Oh and also, when using from java, the lack of a proper object<->document mapping (like hibernate for o/r mapping) is a bit ugly, next time i take a shot at it i'd definitely try to see if i can marshall my objects through gson and just write them in string form to the driver, rather than trying to build a marshaller of my own that uses the java drivers DBObject api directly :X such a stupid idea Yeah mongo is definitely made for a server -> client scenario. Pretty sexy from what I've used of it - main concern is what logic it uses to allocate space for new objects as apparently it has some sort of intelligent allocation algorithm that increases the space reserved for each new object based on the space that the largest object of its collection has used. Scary o_o Love the concept though, and it's beautiful even as just a development-only standin for the final SQL database. Coolest thing about mongo, node and angular is that your entire application is written in JS, which is a lot more consistent and solid in my opinion (in strict mode) than most of its competition. MongoDB is just a document oriented database, its not really made for anything. Given the way we use database these days it is much more efficient to do it this way. However a great side effect is that we are no longer stuck into schema's. NodeJS uses concurrency driven design, I've tried making real apps with it and its an architecture that is only really suitable for a very specific type (web/servers). Be prepared to write things at less than half the rate you are used to. IMO its going to be a major setback to its ability to grow as most people who build websites use languages that allow you to create things in the shortest time possible. We don't care about performance as much because its so easy and cheap to add extra hardware to a webserver. Web apps are concurrent by nature. Expressing this concurrency by interaction in a well-defined fashion is what Node excels at. There is to my knowledge no other server software that allows this as naturally as Node. I disagree with your point about writing things at half the rate you're used to. If you have any experience with multi-threading in another language, Node will make perfect sense and in fact be a pleasant surprise.
I have experience with multi-threading in another language and its nothing like Node because you don't use concurrency driven design in other languages. Instead you have have to deal with things like locking and merging threads. In a purely concurrent app you shouldn't have to deal with those sorts of things with concurrency driven design. If you are, you are doing it wrong.
You simply can't write a web app using concurrency design patterns faster than you can write a normal web app. Its physically impossible. You will end up writing twice as many lines of code to achieve the same thing.
Web apps are only concurrent on the basis that there are multiple users connecting. Per user there is not much concurrency, and if there is, there will be libraries available for you to harness that specialised form of concurrency. Hence the point of NodeJS being cool because it allows you to write concurrently is hardly a selling point, performance can be gained at the click of a button for not much cost at all using elastic cloud instances.
|
On March 15 2012 21:55 sluggaslamoo wrote:Show nested quote +On March 15 2012 21:47 fonger wrote:On March 15 2012 21:34 sluggaslamoo wrote:On March 15 2012 20:47 fonger wrote:On March 15 2012 20:34 MisterD wrote:On March 15 2012 20:27 fonger wrote:
MONGOOOOOOOOOODB - thoughts? funny thing, but clustering functionality is (was when i looked at it last about a year ago) horribly to control through client applications because of lacking support through the various language drivers (at least java). If you want to manage a mongodb instance as an in-application database you'll have to pipe it a ton, not fun. But well, that's not really what it was designed for. Haven't used it in it's primary use case as manually set up database for some clustered web application. Oh and also, when using from java, the lack of a proper object<->document mapping (like hibernate for o/r mapping) is a bit ugly, next time i take a shot at it i'd definitely try to see if i can marshall my objects through gson and just write them in string form to the driver, rather than trying to build a marshaller of my own that uses the java drivers DBObject api directly :X such a stupid idea Yeah mongo is definitely made for a server -> client scenario. Pretty sexy from what I've used of it - main concern is what logic it uses to allocate space for new objects as apparently it has some sort of intelligent allocation algorithm that increases the space reserved for each new object based on the space that the largest object of its collection has used. Scary o_o Love the concept though, and it's beautiful even as just a development-only standin for the final SQL database. Coolest thing about mongo, node and angular is that your entire application is written in JS, which is a lot more consistent and solid in my opinion (in strict mode) than most of its competition. MongoDB is just a document oriented database, its not really made for anything. Given the way we use database these days it is much more efficient to do it this way. However a great side effect is that we are no longer stuck into schema's. NodeJS uses concurrency driven design, I've tried making real apps with it and its an architecture that is only really suitable for a very specific type (web/servers). Be prepared to write things at less than half the rate you are used to. IMO its going to be a major setback to its ability to grow as most people who build websites use languages that allow you to create things in the shortest time possible. We don't care about performance as much because its so easy and cheap to add extra hardware to a webserver. Web apps are concurrent by nature. Expressing this concurrency by interaction in a well-defined fashion is what Node excels at. There is to my knowledge no other server software that allows this as naturally as Node. I disagree with your point about writing things at half the rate you're used to. If you have any experience with multi-threading in another language, Node will make perfect sense and in fact be a pleasant surprise. I have experience with multi-threading in another language and its nothing like Node because you don't use concurrency driven design in other languages. Instead you have have to deal with things like locking and merging threads. In a purely concurrent app you shouldn't have to deal with those sorts of things with concurrency driven design. If you are, you are doing it wrong. You simply can't write a web app using concurrency design patterns faster than you can write a normal web app. Its physically impossible. You will end up writing twice as many lines of code to achieve the same thing. Web apps are only concurrent on the basis that there are multiple users connecting. Per user there is not much concurrency, and if there is, there will be libraries available for you to harness that specialised form of concurrency. Hence the point of NodeJS being cool because it allows you to write concurrently is hardly a selling point, performance can be gained at the click of a button for not much cost at all using elastic cloud instances.
Don't let me spoil it for you, but concurrency-driven design is the design of applications that are designed with concurrency at the core of their architecture. How that doesn't relate to multi-threading in other languages is beyond me.
You've offered no definition of a "normal web app" - are you talking about PHP? If you're comparing "hello world" in PHP to "hello world" in Node then I must congratulate you on a most valuable insight. If you're talking about anything else then you are wrong <3
Your generic term "web app" is concurrent on FAR more levels than merely multiple users connecting. Your comment on this suggests poor familiarity with Node, application design and multi-threading. Heard of timers?
NNNNEEEEEEERRRRRDD RAGE ENGAGE!!
|
On March 15 2012 22:04 fonger wrote:Show nested quote +On March 15 2012 21:55 sluggaslamoo wrote:On March 15 2012 21:47 fonger wrote:On March 15 2012 21:34 sluggaslamoo wrote:On March 15 2012 20:47 fonger wrote:On March 15 2012 20:34 MisterD wrote:On March 15 2012 20:27 fonger wrote:
MONGOOOOOOOOOODB - thoughts? funny thing, but clustering functionality is (was when i looked at it last about a year ago) horribly to control through client applications because of lacking support through the various language drivers (at least java). If you want to manage a mongodb instance as an in-application database you'll have to pipe it a ton, not fun. But well, that's not really what it was designed for. Haven't used it in it's primary use case as manually set up database for some clustered web application. Oh and also, when using from java, the lack of a proper object<->document mapping (like hibernate for o/r mapping) is a bit ugly, next time i take a shot at it i'd definitely try to see if i can marshall my objects through gson and just write them in string form to the driver, rather than trying to build a marshaller of my own that uses the java drivers DBObject api directly :X such a stupid idea Yeah mongo is definitely made for a server -> client scenario. Pretty sexy from what I've used of it - main concern is what logic it uses to allocate space for new objects as apparently it has some sort of intelligent allocation algorithm that increases the space reserved for each new object based on the space that the largest object of its collection has used. Scary o_o Love the concept though, and it's beautiful even as just a development-only standin for the final SQL database. Coolest thing about mongo, node and angular is that your entire application is written in JS, which is a lot more consistent and solid in my opinion (in strict mode) than most of its competition. MongoDB is just a document oriented database, its not really made for anything. Given the way we use database these days it is much more efficient to do it this way. However a great side effect is that we are no longer stuck into schema's. NodeJS uses concurrency driven design, I've tried making real apps with it and its an architecture that is only really suitable for a very specific type (web/servers). Be prepared to write things at less than half the rate you are used to. IMO its going to be a major setback to its ability to grow as most people who build websites use languages that allow you to create things in the shortest time possible. We don't care about performance as much because its so easy and cheap to add extra hardware to a webserver. Web apps are concurrent by nature. Expressing this concurrency by interaction in a well-defined fashion is what Node excels at. There is to my knowledge no other server software that allows this as naturally as Node. I disagree with your point about writing things at half the rate you're used to. If you have any experience with multi-threading in another language, Node will make perfect sense and in fact be a pleasant surprise. I have experience with multi-threading in another language and its nothing like Node because you don't use concurrency driven design in other languages. Instead you have have to deal with things like locking and merging threads. In a purely concurrent app you shouldn't have to deal with those sorts of things with concurrency driven design. If you are, you are doing it wrong. You simply can't write a web app using concurrency design patterns faster than you can write a normal web app. Its physically impossible. You will end up writing twice as many lines of code to achieve the same thing. Web apps are only concurrent on the basis that there are multiple users connecting. Per user there is not much concurrency, and if there is, there will be libraries available for you to harness that specialised form of concurrency. Hence the point of NodeJS being cool because it allows you to write concurrently is hardly a selling point, performance can be gained at the click of a button for not much cost at all using elastic cloud instances. Don't let me spoil it for you, but concurrency-driven design is the design of applications that are designed with concurrency at the core of their architecture. How that doesn't relate to multi-threading in other languages is beyond me. You've offered no definition of a "normal web app" - are you talking about PHP? If you're comparing "hello world" in PHP to "hello world" in Node then I must congratulate you on a most valuable insight. If you're talking about anything else then you are wrong <3 Your generic term "web app" is concurrent on FAR more levels than merely multiple users connecting. Your comment on this suggests poor familiarity with Node, application design and multi-threading. Heard of timers? NNNNEEEEEEERRRRRDD RAGE ENGAGE!!
Lol what a terrible post.
You keep angling me with questions like "have you ever written a gameserver?", "do you use PHP?", "heard of timers?". (seriously why are you using timers in Node? you are completely defeating the purpose).
How about, do you know anything?
If you really want to know
I use Node with CoffeeScript, Express, Jade, Async and Stylus.
And I do my TDD/BDD using Jasmine, Cucumber, Zombie. I used to use Expresso but these days code coverage doesn't bother me as much.
I probably used more than that but I dunno its been a while. I am really a Ruby developer at heart, something you should realise is that nearly every NPM module is a direct port or an adaptation of a Ruby gem. Hell even NPM is just like RubyGems. Which is why NodeJS attracted me in the first place, but I also like the fact that I can write apps quickly and have them be easy to maintain, something that NodeJS doesn't provide as well.
Let me ask you, do you use concurrent design patterns in NodeJS? Please don't use Wikipedia as you will just give me the wrong answers, the patterns are much more specific to Node itself. Although I should apologize that I was lazy and wasn't more specific by referring you to the subset known as asynchronous design patterns. The most important ones involve asynchronous control flow so you can write a completely concurrent program, and not have to worry about managing locks or merging threads.
This is because the design patterns you will use will have nearly every operation involve the use of callbacks with short unmanaged parallel runs, rather than longer managed runs. Something very suited to a language that runs on a functional imperative paradigm like Javascript. This makes it much cleaner overall than doing the same thing in lets say C#.
I will give you a trivial example. Lets say you want to run a simple for loop. Most people would just do that. But nooo, because we are running on a single threaded event loop this is bad, as soon as one person runs through, the second person has to wait for the first person to finish.
So instead of
for(var i= 0, l = entries.length; i < l; i++) {
doSomething(entries[i]);
}
We have to use a non-blocking loop (and we will use an un-ordered loop because most of the time order doesn't matter)
var leftToProcess = entries.length;
for(var i = 0, l = entries.length; i < l; i++){
(function(foo){
process.nextTick(function(){
doSomething(foo);
if(--leftToProcess === 0){
done();
}
}
);})(entries[i]);
}
Look mum no timers.
Note how this still takes a lot of time to write, and probably some time to think as well. Not to mention, imagine trying to maintain this. Development time is always more costly than CPU time, especially with the wide array of elastic cloud servers to choose from.
That's why NodeJS is making such a silly trade off with this maneuver. Perhaps it would be better if you could write in normal threaded mode, and then when your website suddenly became ebay, you could use the current Node engine and change the code then.
Oh I remember you mentioning
On March 15 2012 21:52 fonger wrote:Show nested quote +On March 15 2012 21:34 sluggaslamoo wrote:
If you are writing stuff imperatively then you are not doing it right and not only will your app not work properly with more than a few users, you will not reap the benefits that NodeJS provides. Where the fuck did that come from?
The fact that this surprises you is a bit of a worry. Anyway you should check out the async library as that has a really useful bunch of async design patterns that you can use to help you write NodeJS properly.
https://github.com/caolan/async
Hopefully you know how to use git or npm at least.
The fact that it is unlikely that even a Node fan like yourself knows how to use Node properly, is one of the problems I was going to mention with Node. In fact its hard to even get any information on how to code in Node properly at all. Probably only a small number of Node users actually do things concurrently. Screening developers, let alone finding a good one, will be difficult and expensive to say the least.
Anyway lol I'm done with this thread (again), and might come back in a few weeks when I might (falsely) believe I will actually be able have an intellectual conversation.
|
|
|
|
|
|
EPT
