I can say with all honesty that I have never worked with cobol. I did a little pascal once, but quickly distanced myself from it at the first given opportunity. :) As a Java developer for over 12 years, it only took me about one year of *properly* using Scala for Java to feel like a foreign language
I was also a very early adopter and proud advocate of Spring, but still feel that, at the time, it was the right solution for the problem (i.e. a dynamic config framework without the boilerplate of EJB). Thankfully the state of the art has progressed since then... So one question for you: If you decided to stop using Spring, but change isn't good, then was it a bad decision? On 17 September 2010 17:31, Steel City Phantom <[email protected]> wrote: > i am so bored with this subject that i wish people would just drop it. > java is not developer friendly? are you serious? on this subject, its not > java that isn't developer friendly, its the supporting libraries that suck. > my god even with auto code generators hibernate blows as far as friendly. > the way it should be is you have an annotation at the top of the container > class with saying what table its mapping and your ant or maven script has > the connection information to the database and at compile time that script > logs into the db, pulls a create script from the table and uses that > information to write the appropriate byte code. if you want to override the > default, fine, annotate a field with an enumeration or something but 99% of > the time defaults are fine. THATS developer friendly and it has nothing to > do with java. the argument would be the same wether is java, scala, groovy, > php, c#, vb, c, c++, or assembly. > > right tools for the right job. im a java developer. i have been doing it > for 9 years. i think in java. you give me a problem, i think of the > solution in java. does java have its limits, absolutely, so does every > other language. but i know what those limitations are and coding around > them is simply second nature. > > is scala impressive? absolutely. but my biggest problem with scala is one > of the things most people cheer. its rapid release cycle. ive been working > on the same project for 8 years now. we finally finished an integration > project to get us out of jvm 1.4 and on to jvm 5. it took a year and a half > to implement all the upgrades on our code and the only reason we did it was > we had to start running jboss seam and it just straight up doesn't work on > 1.4. if that requirement didn't come up, id still be coding on 1.4. trust > me, 8 years and well over a million lines of code in my project, change is > not good and if you were to ask me to do something this big again and choose > a platform, i would choose java over scala simply because java changes very > slow. i know every straight out of school code monkey believes that latest > really is the greatest, but us guys that have been doing it forever > can appreciate that sometimes ol reliable is the best approach. if you want > a practical example, how many of you still work with cobal from time to > time? > > now as far as developer friendly, all you have to do is look at spring. i > quit using it years ago because its just to damn ridiculously complicated. > i started realizing i could just code the problem by hand on my own faster > than i could figure out some poorly documented over featured, overly complex > library in spring. is that java's fault? absolutely not, its the libraries > fault. and you will have the same problem no matter what language you use. > > and don't get me started on configuration xml's. you want developer > unfriendly you can stop right there. especially if you work with an app > server. do they have to be that complicated? absolutely not. you could do > exactly the same thing with simple annotations and reduce your entire J2EE > app config files down to one file that simply has your DB connection info. > > > On Fri, Sep 17, 2010 at 11:18 AM, Reinier Zwitserloot > <[email protected]>wrote: > >> Correction: In java, as in scala, all expressions "return" a value >> (not really the right term, that. Expressions *have* a value is closer >> to the mark). It's just that in scala more things are expressions. >> Like "if": Expression in scala, statement in java. Not ALL things in >> scala are expressions. Variable declarations aren't, for example. >> >> In any java library that isn't completely worthless, the code is >> "getField()". If you get annoyed at writing out the accessor, use >> lombok. Claiming that as a benefit to scala seems like you're grasping >> for reasons. >> >> A useful definition for "higher level" is that it makes invisible / >> automated whatever's trivial detail. This is a double-edged knife, >> though: Whether or not a detail is trivial depends on the problem. For >> example, C conveniently abstracts away the concept of stack, but in >> the process of doing so, removes the ability to store stacks. The JVM >> abstracts away memory management, but in the process of doing so >> introduces non-determinism due to gc runs. >> >> However, with that definition scala isn't much higher than java. There >> aren't many things that you can no longer do in scala but which you >> can do in java, and on the flipside, there aren't many things that are >> orders of magnitude simpler in scala than java because something has >> been abstracted away. Scala is more a sideways step: It's operating at >> the same general level of abstraction as java, but with a different >> syntax, which includes more emphasis on function objects (something >> java CAN do, but not with particularly nice syntax), as well as a less >> rigid syntax structure, and a general more functional outlook. >> >> >> >> On Sep 17, 3:28 pm, Kevin Wright <[email protected]> wrote: >> > I'm recently taking the position that it's impossible to state which of >> two >> > languages is "simpler", the term is just too heavily overloaded. >> > >> > Just pick your definition and it's trivial to show that assembly is >> simpler >> > than LISP, or vice-versa, but you've still achieved nothing. If we use >> the >> > term "higher-level" instead of "simpler", then this difficulty >> evaporates. >> > >> > Personally I feel that Scala is simpler than Java, but that statement >> means >> > nothing without also explaining the particular definition of the term >> that >> > matters to me. In this case, it's two features of that language that >> really >> > stand out, and show Scala to be the higher-level language.. >> > >> > 1. It has constructs that closely match the way I think about problems. >> > When I have to mangle the design in my head so that it matches the >> features >> > of the target language, I perceive that as an unneccessary complication >> in >> > the design+implementation process. >> > 2. Scala has a smaller general-purpose syntax that I can use accross a >> wide >> > range of problems, instead of a larger number special-case constructs. >> For >> > example: >> > >> > - Java has the ?: operator, but Scala has the much more general idea >> that >> > all expressions return a value. >> > >> > - Java has a switch statement over numbers, enums and (soon) Strings, >> wheras >> > Scala has pattern matching that isn't limited to any type. >> > >> > - Java has primitives, and operators are limited to only working with >> > primitives. Everything in Scala is an object, and operators are just >> > methods. >> > >> > - Java has special behaviour for concatenating an object or primitive to >> a >> > string, Scala can do this with implicit conversions - a feature that's >> > useful in many more situations. >> > >> > - To fetch a value from an object in Java, I must first know if it's a >> fixed >> > value or if it'll be calculated, and so use field or getField() as >> > appropriate, Scala doesn't force this distinction and so it's enough to >> know >> > I'm fetching a value, the underlying logic could even be changed in the >> > future without breaking my code. >> > >> > The ability to work with general concepts and not have to chose exactly >> > which special feature I need in a given situation... I see that as >> > simplifying the task of programming. >> > I could say more, but it's probably just "simpler" to point here: >> http://stackoverflow.com/questions/727078/whats-so-great-about-scala/... >> > >> > On 17 September 2010 11:30, Reinier Zwitserloot <[email protected]> >> wrote: >> > >> > >> > >> > > That just sounds like equating "simple" to "less verbose". >> > >> > > For example, with optional () for args-less method calls, you get a >> > > number of things which one might deem "simpler": >> > >> > > - Less characters to type and read >> > > - The ability to not have to care about whether the doClick member is >> > > a method or a field >> > >> > > On the other hand, you also get a few things which are decidedly more >> > > complicated: >> > >> > > - A stylistic choice about whether or not you add the (). Having to >> > > make an irrelevant choice of any sort clearly seems like a lack of >> > > simplicity to me. >> > > - The INability to tell if doClick is a field or a method. In certain >> > > circumstances it matters, and having to look it up is more complicated >> > > than being able to tell at a casual glance. >> > >> > > These are clearly conflicting requirements. Forcing you to care >> > > whether doClick is a field or a method is needless complexity.... >> > > unless it isn't, in which case not being able to tell is needless >> > > complexity. Offering the programmer the choice doesn't help, because >> > > the choice in it self is needless complexity, and by existing we still >> > > can't tell, given "foo.doClick", if doClick is a field or a method. >> > > We'd have to rely on a programmer following the local style guidelines >> > > (if, say, these state that non-fields ought to be called with parens), >> > > which you can' even unit test. Now we're introducing needless >> > > complexity there. >> > >> > > Oh, how complicated. >> > >> > > There's also the issue of moving complexity around to the problem >> > > domain. My usual retort to those complaining about the complexity of >> > > generics is simply this: Co- and Contravariance is _inherently_ >> > > complicated. When you have a problem where generics is required or >> > > seems quite useful, then the problem has this complexity, inherently. >> > > You can choose not to use generics, but then the complexity is just >> > > hidden away in javadocs and a bunch of casts. You can tweak generics a >> > > bit, declaration-site generics probably being the most drastic, but a >> > > truly "simple" generics will never be, because co/contravariance isn't >> > > simple. >> > >> > > So, did java become more complex when 1.5 was introduced? Yes. Does >> > > this mean java 1.5 is worse than 1.4? No - in fact, it's better. >> > >> > > So, in certain ways, a more complex language is actually a good thing. >> > >> > > Hence my conclusion that all this talk about "complexity" is not going >> > > to convince anybody one way or another, because its very very easy for >> > > anyone reading the word "complexity" and imagine whatever situation is >> > > least likely to convince them. >> > >> > > So, to try and mitigate this, here's where I believe scala has added >> > > needless complexity: >> > >> > > Stylistic choice is EVERYWHERE. This is what, as I said, *I* mean by >> > > DSLish features (yet another vague term that can mean just about >> > > anything). Should I put () after an args-less method call? There's a >> > > stylistic choice there. dots to dereference? Another stylistic choice. >> > > Use operator overloading, or not, and if I do, left-associative or >> > > right-associative? There's also boatloads of semantic choice in scala. >> > > If I need to iterate over a map and, say, produce a list containing >> > > the concatenation of each key and associated value, in java there's >> > > really only two obvious ways to do it. Both involve looping, and the >> > > only difference is whether I iterator over entrySet() or keySet(). In >> > > scala, there's _way_ more choices. I can do a java-style loop, or I >> > > can use an each construct that fills the list, or I can turn the keys >> > > and the values into two sets, and then zip them up, functional style, >> > > or I could use a comprehension of some sort. >> > >> > > Why is this bad: >> > >> > > Well, obviously a language can't eliminate _all_ stylistic choice. At >> > > the very least you have to pick a name for your methods, and naming is >> > > clearly up to you, the API author. But, scala goes _way_ too far in my >> > > opinion. While it seems like a nice idea, give an API designer, and an >> > > API user, the ability to write in whatever feels most natural (i.e. >> > > readable, easy to maintain), that's great! Except when it isn't: By >> > > introducing all these stylistic choices, you're forcing the API user >> > > to pick at every stage. Sometimes, this choice is good, because the >> > > benefits of picking the best option available outweigh the burden of >> > > having the choice. In all other situations, though, this choice is not >> > > useful at all. It makes sharing code harder (because Joe likes 'each', >> > > but Jack likes 'for'). This is like spaces v. tabs: The flexibility of >> > > using either really isn't helping. We'd have been better off if back >> > > in the day someone put their foot down and declared some indent style >> > > to be the only one compilers will accept from here on out. Deviation >> > > from this one rule results in compiler warnings. I can't claim to be >> > > very scientific about it, but to me it feels like Scala has gone >> > > waaaay too far down the "give the programmers the flexibility" path. >> > > Where the flexibility helps me make code do different things, that's >> > > fantastic. Where this flexibility boils down to the exact same end >> > > result, and I just have many different ways of expressing the same >> > > concept, usually, it's just a bother. It's needless complication. >> > >> > > The python folks differentiated themselves from the Perl folks early >> > > by turning Larry Wall's "There Are Many Ways To Do It" around into >> > > "There Is Only One Way To Do It" and I subscribe to the theory. >> > > Introducing stylistic choice needlessly is always bad. But yet again >> > > there's a dichotomy here: Where stylistic choice turns from pointless >> > > to useful is a moving target, there isn't a single answer to the >> > > question. >> > >> > > Perhaps I was unclear about my comment in regards to using java >> > > libraries in scala code: If you're going to write scala, then... write >> > > scala. Which means you use THEIR collection APIs. If you stick with >> > > java.util.List, then interopping with other scala code is going to be >> > > a nightmare, and even if most scala programmers are familiar with the >> > > java APIs (which is clearly an argument that can't scale: If scala >> > > outgrows java in popularity, or gets even remotely close to it, how >> > > can that possibly be true?), its like not following the camelcasing >> > > conventions in java code. It throws people off, makes your code >> > > ridiculously hard to understand. Just don't do it. There's no going >> > > halfway, and there's not much point (as you said too) in trying to >> > > stay up to date with both java and scala. Pick one. That's your go-to >> > > language for larger projects where static typing is nice, and/or speed >> > > is not unimportant. If you want to learn more languages, fantastic. >> > > But don't pick java and scala. That's a silly combination, the problem >> > > domains where these 2 languages shine overlap far too much. >> > >> > > On Sep 17, 10:42 am, Ricky Clarkson <[email protected]> wrote: >> > > > Reinier, >> > >> > > > You want a definition of simple? Ok, some code is more simple than >> some >> > > > other code if it contains fewer tokens that are outside the domain. >> > > E.g., >> > > > Cobol's ADD 1 TO AGE GIVING AGE is not as simple as C's age++. >> Java's >> > > > SwingUtilities.invokeLater(new Runnable() { public void run() { >> > > > button.doClick(); } }) is not as simple as Scala's: >> > > doLater(button.doClick). >> > >> > > > Staying cutting edge on Scala is easier as it does not require a >> cutting >> > > > edge runtime. >> > >> > > > In my opinion, for tasks for which Java is a reasonable option, so >> is >> > > Scala, >> > > > as it is typed and runs in the same environment. I wouldn't look at >> > > Groovy, >> > > > JRuby or Jython for those, because they are untyped. >> > >> > > > Regarding writing in DSLs, pretty much all code unless >> > >> > ... >> > >> > read more » >> >> -- >> You received this message because you are subscribed to the Google Groups >> "The Java Posse" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<javaposse%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> >> > > > -- > You want it fast, cheap, or right. Pick two!! > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Kevin Wright mail / gtalk / msn : [email protected] pulse / skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
