Your first lisp ? I suggest you immersed yourself in it. Clojure is my third.
Clojure is different from past languages because it allows features
that have existed for a number of years separately to coexist together nicely.
Many languages in the past have been created based on a couple of these
features and have failed to keep up. They got entrenched in their initial
feature set
and could not evolve easily from there.
>From what I saw in my 30yrs+ career, Clojure is the first language for which I
>can't see
no limits on the evolution scale. Clojure keeps your options opened at all
times.
It still evolves but you do not loose previous features or rarely (numerics
were
retooled for perf reasons and that was painful to some).
OO was created more than 50 years and it failed to deliver. Java evolves at a
very slow pace with excruciating pain. Most attempts to include new features to
it
has to rely on external frameworks with a lot of heaving tooling to achieve
mundane
tasks. The core of the language cannot keep the pace with the needs and new
Gizmos have to be invented outside of it to compensate.
So long for the "principles". Staying static is the best way to get caught
off guard when facing new problems. This applies to life and to software these
days.
As for maintenance, we have a code base above 20K lines here and it's
a breeze to maintain.
I did not say that LOC was the only important metric, I said that having a
single line of
code to hide a publicly known data accessor is to me a code line that has no
value.
It's even uglier in Clojure where data is immutable...
Luc
> On Jun 16, 2012, at 6:27 PM, Softaddicts <lprefonta...@softaddicts.ca> wrote:
>
> > 50 years of solid programming principles, OO being the Holy Grail ? :)
> >
> > I assume then that you programmed a lot in Simula-66 ? I did...
> >
> > For over 50 years, we made the same mistakes that Clojure attempts to
> > correct. Most of the time new languages repackaged the same flawed concepts
> > of the past, this has been done over and over again.
>
> How is clojure different? I have programmed in dozens of languages,
> message based and functional, static and dynamic, garbage collected
> and manage it yourself. One thing that I have realized is there is no
> magic bullet and they are as you say different versions of the same
> thing.
>
> Clojure is my first lisp however and I was really excited about it
> when I started but after writing a project with more than a few
> thousand lines of code I found it very frustrating to change.
>
> >
> > Programmer's throughput have to increase somehow, any superfluous line of
> > code is too many.
> >
> > Getters facades of any form are just that, superflous code lines that need
> > to be maintained later on.
> >
> > That led Java right in the russian puppet syndrom.
> >
> > In these 50 years solid principles, many failed to deliver. It's time for a
> > reset :)
> >
>
> I too have experienced the russian doll syndrome and logic scattered
> across multiple files, but I have already started migrating away from
> clojure because the code is difficult to maintain.
>
> If the code does not need to change then maintaining it is easy,
> however if it does need to change i would prefer to make that change
> in only one place. DRY. If that only requires one more line of code
> then I think it is well worth it and I certainly do not believe that
> lines of code are the best metric of maintainable code. IMHO,
> Readability and good domain abstractions are FAR more important then
> LOC.
>
> >
> > Luc
> >
> >
> >
> >>
> >>
> >> On Saturday, June 16, 2012 1:28:21 PM UTC-6, Vinzent wrote:
> >>>
> >>> I agree, an explicit type field makes dispatching easy. However this data
> >>>> structure returned by (http/get ... :as json) so if I want to add type
> >>>> information I need to walk the tree and rewrite it. Not necessarily a
> >>>> bad
> >>>> idea, but in some cases the only thing I need is the eTag and so the
> >>>> additional processing may in some cases unnecessary. One could easily
> >>>> make
> >>>> data conversions lazy by doing something like (defrecord Contact
> >>>> [contact])
> >>>> (defmethod emails Contact [contact] (map map->Email (:emails contact)) to
> >>>> delay the computation until the values are actually requested. However,
> >>>> note that emails is now a multimethod method not a value and the consumer
> >>>> needs to use (emails contact) rather than (:emails contact)... Thus as I
> >>>> was saying previously is that (def emails :emails) gives you the
> >>>> flexibility to delay computation if desired.
> >>>>
> >>>
> >>> You have delays and lazy sequences for delaying computation.
> >>>
> >>
> >> This still requires changing your code to @(:emails contact). If you use
> >> (emails contact) you need change your code in only one place.
> >>
> >>>
> >>> Clojure does not distinguish between properties and data representation
> >>>> and these are NOT the same thing.
> >>>>
> >>>
> >>> Properties is OOP concept; clojure is not an object-orinted language.
> >>>
> >>
> >>>
> >>>> There are many different ways to represent data. For example the area of
> >>>> a shape can be represented in many different ways, square inches, square
> >>>> miles, a rectangle, circles, polygons, or perhaps complex geometry
> >>>> requiring calculus all of which could be asked what is your area in
> >>>> square
> >>>> feet. Area is a property of the object, the width, radius, number of
> >>>> sides, etc is an implementation detail.
> >>>>
> >>>
> >>> No, area is a function.
> >>>
> >>
> >> Property is just the OO word for function, semantically they are the same.
> >> OO doesn't have functions they have properties and methods.
> >>
> >>
> >>>
> >>>
> >>>> You may then ask so why don't you just pass in {:area } as square feet
> >>>> instead of the radius of the circle? Because the value may not be used
> >>>> by
> >>>> the function. If its not used then why is it part of the contract?
> >>>> Because it may be used conditionally, for example, maybe the function
> >>>> needs to find the first shape that will fit within a region once that
> >>>> limit
> >>>> is reached it no longer requires the area for any other shapes. So if
> >>>> the
> >>>> shape requires complex calculus which has been written in another
> >>>> programming language and thus requires a rpc call to a network service to
> >>>> compute the value that is only used sometimes seems wasteful and
> >>>> inefficient if the value is only sometimes computed. This example is
> >>>> somewhat contrived, but it is not that different from what I am doing.
> >>>>
> >>>
> >>> If getting a 'property' requires such computations, then it's clearly
> >>> should be a function.
> >>>
> >>
> >> Agree.
> >>
> >>>
> >>>
> >>>> My point is that properties with getter functions allow you to defer
> >>>> computation, keywords do not. Keywords are not like java getters they
> >>>> are
> >>>> like java fields.
> >>>>
> >>>
> >>> Keywords are just one of clojure's data structures (see
> >>> http://clojure.org/data_structures#Data
> >>> Structures-Keywords)
> >>>
> >>
> >>>
> >>>> Instead of (:property themap), one should use (def property :property)
> >>>> (property themap).
> >>>>
> >>>
> >>> No, one shouldn't.
> >>>
> >>
> >> I disagree... but I will continue to recommend otherwise.
> >>
> >>
> >>>
> >>> Actually this is only somewhat contrived. It is not uncommon for a user
> >>>> to the same nickname in his email nickn...@domain.com and in twitter
> >>>> handle, and this is a useful similarity feature when this computation is
> >>>> performed for each *pair* of field in each *pair* of contacts this
> >>>> computation may need to be performed millions of times.
> >>>>
> >>>
> >>> Well, you can use memoization or choose to structure your data in some
> >>> other way.
> >>>
> >>>
> >>>> Perhaps lisp programmers already did? CLOS and OO was born?
> >>>>
> >>>
> >>> Clojure is not Common Lisp.
> >>>
> >>
> >> Agreed, clojure has a much stronger emphasis on immutability than
> >> traditional OO programming and is what I like about it... but it is
> >> possible to write OO code using immutable data structures but is not as
> >> idiomatic. I don't want clojure to be like CLOS, but I also don't think
> >> that we should ignore more than 50 years of lessons learned and "SOLID"
> >> programming principles.
> >>
> >>
> >> --
> >> 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
> > --
> > Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad!
> >
> > --
> > 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
>
--
Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad!
--
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
