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
