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

Reply via email to