Am 06.11.2011 22:00, schrieb Alex Baranosky: > The problem with Java is you can write a ton of it easily with Intellij > (my facorite IDE), but Intellij cant read that code for you, so now you > have a novel to wade through when the code is revisited.
after some time, your brain will filter the clutter out. all i need is a big screen. :) but you're right, reading concise high level code > reading verbose low level code > > On Nov 6, 2011 11:49 AM, "Dennis Haupt" <d.haup...@googlemail.com > <mailto:d.haup...@googlemail.com>> wrote: > > "special cases" that depend on mutable state are evil. i avoid mutable > states as much as possible, no matter which language i am using. > what i meant were cases where i roughly think about 3/4 of all cases, > start coding and along the way i notice that in one case in need > another input parameter for my function and have to refactor > everything i have written so far. > > my experience is that you need to balance out planning and actual > coding. there's a limit for planning. if you plan too much, it won't > help. you'll just introduce problems and won't notice it because you > are skipping the reality check. reality never misses a case, but even > the smartest guy/gal does :) > > what i do in <random oo language> is to just start somewhere and code > recursively. as soon as something gets to complex, i split it up or do > minor refactorings. this works pretty good and i rarely end up in a > situation where i have to go back a big step. i rarely lose speed, > even if i encounter a surprise. > > i'll become faster once i get used to clojure, but i doubt i'll be > able to be as fast as in scala or java. this is not because the > language itself is bad. java is really verbose, but that doesn't > matter at all. i don't write java code. i use intellij idea. it writes > and rewrites java code for me. > with equal tool support, i'd prefer clojure over java. > > > > > > Am 06.11.2011 14:48, schrieb Colin Yates: >> But aren't the "edge cases" fewer given the notion that functions >> should be entirely defined by their inputs as oppose to being >> dependant on mutable state external to he function, in the most >> part. > >> I am agreeing with you, and find these real world experiences >> incredibly useful. > >> Sent from my iPad > >> On 6 Nov 2011, at 13:03, Dennis Haupt <d.haup...@googlemail.com > <mailto:d.haup...@googlemail.com>> >> wrote: > >> Am 06.11.2011 13:44, schrieb Colin Yates: >>>>> I have a hunch (as oppose to IME as I don't have any yet :)) >>>>> that Clojure doesn't require as much due to at least the >>>>> following points: >>>>> >>>>> - there is much less incidental complexity and ceremony >>>>> required to manage (and therefore refactor) - implementations >>>>> in Clojure require more thought and are much more focused on >>>>> one thing then in Java, therefore there is a much higher >>>>> chance that you get it right the first time > >> this is a double edged sword. you *do* get it right *if* you think >> it through, but reality is often more complex than you assume. if >> you suddenly see that you forgot to handle special case x, you are >> punished harder than in <random statically typed oo language>. > >> in oo, you can do a few "emergency hacks" before everything >> becomes unmaintainable. in clojure, i could not do this without >> committing maintenance suicide immediately. for each case that >> popped up surprisingly, i had to do a bit of refactoring. > >> that whole "dynamically typed" thing is creeping me out. > > >>>>> >>>>> To put it another way, how much refactoring we we do in Java >>>>> is down to managing the complexity of the problems inherent >>>>> in Java the language; complecting state and identity for >>>>> example. >>>>> >>>>> A concrete example: I know I often refactor code out of one >>>>> class into a utility once that becomes useful by other >>>>> classes. The reason I need to do this is because in java the >>>>> functionality is ring fenced by the data that it works on >>>>> (I.e. encapsulation in the container called a class). In >>>>> clojure that association can be made but right off the get-go >>>>> data and functionality are separate. >>>>> >>>>> Just my two-pence worth and I still haven't written more than >>>>> 2 lines of clojure so it probably isn't worth 2p :) >>>>> >>>>> Sent from my iPad >>>>> >>>>> On 5 Nov 2011, at 12:16, Dennis Haupt >>>>> <d.haup...@googlemail.com <mailto:d.haup...@googlemail.com>> wrote: >>>>> >>>>> hi, >>>>> >>>>> i'm half done with my asteroids clone. i stumbled over a few >>>>> problems and wanted to know how others already solved them >>>>> :) >>>>> >>>>> i am used to "less concrete programming". i ask my tools to >>>>> do the actual analysis and coding for me: * where is that >>>>> used? * rename that * show me all errors * add a parameter >>>>> here * autocomplete this for me, i am too lazy to even >>>>> remember the exact method name * show me a list of all >>>>> methods and fields starting with an "e" that fit in here. i >>>>> know the one i want is in that list. >>>>> >>>>> as elegant as clojure may be as a language, it's dragging me >>>>> down to almost native text editing which i did more than 10 >>>>> years ago when i wrote a game in turbo pascal. >>>>> >>>>> how did you solve these problem and get some tool-support? >>>>> or don't you miss it because of something i am not aware of? >>>>> >>>>> >>>>> >>>>>> >>>>>> -- You received this message because you are subscribed to >>>>>> the Google Groups "Clojure" group. To post to this group, >>>>>> send email to clojure@googlegroups.com > <mailto:clojure@googlegroups.com> Note that posts from >>>>>> new members are moderated - please be patient with your >>>>>> first post. To unsubscribe from this group, send email to >>>>>> clojure+unsubscr...@googlegroups.com > <mailto:clojure%2bunsubscr...@googlegroups.com> For more options, >>>>>> visit this group at >>>>>> http://groups.google.com/group/clojure?hl=en >>>>> > > >>> >>> -- You received this message because you are subscribed to the >>> Google Groups "Clojure" group. To post to this group, send email >>> to clojure@googlegroups.com <mailto:clojure@googlegroups.com> > Note that posts from new members are >>> moderated - please be patient with your first post. To >>> unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com > <mailto:clojure%2bunsubscr...@googlegroups.com> For more options, > visit this >>> group at http://groups.google.com/group/clojure?hl=en > > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > <mailto:clojure@googlegroups.com> > Note that posts from new members are moderated - please be patient > with your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > <mailto:clojure%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en