Search Results

Search found 2 results on 1 pages for 'user1037729'.

Page 1/1 | 1 

• Do you think Scala will be the dominant JVM langauge, ie be the next Java? [on hold]

  - by user1037729

  From what I've read about Scala do far I think it has some nice features but I do not think it should be "the next Java". It might however end up being the next Java (due to fashion rather than fact) but lets not hope it does not... To me adds a lot of complexity over Java which is a simple and scalable language. Scala Pattern matching allows you to perform some type/value checking in a more concise way, this is possible in Java, Scala's pattern matching has a limit to it, you cannot continuously match deeper and deeper down the object graph, so why not just stick to Java and use decent invariants? Scala provides tuples, easy enough to make in Java, create a static factory method and it all reads nicely too. Scala provides mixins, why not just use composition? I believe Scala implicit's are bad, they can lead to code becoming complex and hard to maintain, explicitness is good. Scala provides closures, well they will be in Java 8 too. Scala has lazy keyword for lazy instantiation, this is easy enough to do in Java by calling a getter which creates the instance when needed, no hidden magic here. Scala can be used with AKKA, well so can Java, there is an Java AKKA implementation. Scala offers addition functional features but these can all be created in Java, there are many frameworks with have implemented functional features in Java. All in all Scala seems to offer is addition complexity and thats it...

  Read the article

• Pair Programming, for or against? [on hold]

  - by user1037729

  I believe it has many advantages over individual programming: Pros By pairing senior with relatively junior staff, the more junior can get up to speed with both project and computing experience, and the senior will re-think the problem in order to communicate with the junior, thus re-checking his own thinking (rubber duck principle!). At least 2 people will know about any single piece of work, if one person is away the other can cover, or if some one leaves a project knowledge transfer is easier. Two brains on a complex task is more effective, communication keeps the work free flowing and provides redundancy in decision making. Code is effectively reviewed as its being written, no need for a separate reviewing phase which requires a context switch as someone who has not been working on the piece in question would be required to understand and review the related code. Reviewing code on your own which you haven't written or architected is not fun, hence counter productive. Cons Less bandwith for performing tasks, lets say we have 4 devs, pair programming requires 2 devs per task, so we would be doing 2 tasks concurrently as a posed to 4. I believe this "Con" does not stand up as the pair programmed task would complete sooner and comes with a review built in for free! Ie the pair programming task would be more efficient and thus free up resources earlier. Less flexibility to chop and change tasks as two developers are tied into a task, when flexibility is required this could be a problem.

  Read the article

1