-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 06.11.2011 18:11, schrieb Colin Yates:
> I suspect programming in clojure effectively is as much about
> changing the *way* you develop as much as it is about about the
> shape of the solution.  It sounds as if you are suggesting this is
> so.

yes. you are (almost) never going to write the final code. you are
going to write code which you are going to change later, so code
should be written in a way that allows you to do so quickly.

> I am about to start my first clojure project tomorrow which is to 
> replace an existing web app which is a case study in how short
> term wins quickly build up technical and architectural debt.

you *can* have short term wins without adding complexity. you just
can't have it always ;)

 It is also a
> wonderful example of how painful it is to live in a world where
> the code base is so bad that changing it is too dangerous so lets
> add another layer .....   Yuck.
> 
> How did you find IntelliJ iDEA for clojure?

very stable, but aside from the project/module setup, it's barely more
than a text editor with symbol highlighting, basic code
completion/auto import and basic function call resolution. compared to
the groovy, scala or even java capabilities of intellij - no contest.

i guess given the dynamic nature of clojure, you'd have to put a LOT
of resources in developing useful code analysis algorithms.

 I have used both it and
> eclipse (STs) for years but am considering emacs (with which I have
> a beginner's competency).  I am intentionally not using spring or 
> hibernate and I expect the project will be fairly small in the
> short term actually so I think emacs might be  achievable....  (I
> am also switching from spring MVC and jquery to conjure and yui3 -
> this is all about using the right technology from the start and I
> love vert iCal learning curves :)
> 
> To explain why this madness might actually be a great idea - the 
> existing app will be deployed with some additional json services
> so the new app will initially just be a very thin skin that uses
> those json services in the short term.  Later on the functionality
> will be rewritten in the new app.
> 
> Exciting times!
> 
> Sent from my iPad
> 
> On 6 Nov 2011, at 16:49, Dennis Haupt <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
> refacto 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> 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> 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 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
>>>> 
> 
> 
>> 
>> -- 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
> 


- -- 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOtsaYAAoJENRtux+h35aGPG0P/19Hj78/ujhlP3KTxDPhwoKR
1hudW9qqQMbq+XgY4cGVwcgjRuJvUu40zECsqQyHyioAmDLVO+IMcJnPFquogl5O
al9RhaIko1s92nxDKTAn6RB4PBhB44hTxlGlLQw5U8okde9FKoKg42h2THB6zhEp
DHotPBA28pADNZGHwcayMIxm5GBUfsI415pueneRoLP/R4KudVcDxLj4auGnTMic
702Rj/lqQfIcE8YS8lLmo9hq9yBLy3ELYpzsrfwPvoYhoxsyVxOmO4tmLOETAlGJ
yYfG1l51RSH/FLW8PAniyHDIaeYt+JGOyVHtxnok4BJOpHMd1cq6o+lnuKMPUFPb
z+0Hf8h5eAixWco9YS0Ues+Th571aSLYfdO92kv+r0aHSxmnUvI5N2AbEihT0nSJ
ay2RpQXBMjiWoGcfnANO11nA/VLHyfaZ59w8MaRn2IQ7VhY7IQXcVG/Rza8j/AuT
FqvZAd3GwsCx/beiAFC/OXJ/Lo6y30rdaWl5256KLRN+tGzBHYzSlYOHqpFOifnl
hdfN6R8gEIK/htm6o5u5x+P0LZSC93VPUaVfqNylAPF1aNhyiN2gJu7nkqOHGoC5
hEQKPzd22rplWsTGTCDp2D0lvR8OXYn6KNiSie/oNY46K6rVyqciGMoWADIHL/zW
IlODqaZcm0H6QSlRyZ2A
=pMSM
-----END PGP SIGNATURE-----

-- 
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