On Tue, Jun 29, 2010 at 8:03 AM, Mike Meyer <
mwm-keyword-googlegroups.620...@mired.org> wrote:
> You might also note that lisp behaves the same way as python - at least
> outside of macros. As noted in the last paragraph, the paper isn't about
> lisp vs other languages, its about readability vs "p
"Steve Molitor" wrote:
>> The Python approach leads to more readable
>>code: http://www.mired.org/home/mwm/papers/readability.html
>
>The two cases he sites do not apply to Clojure:
More accurately, the problem being analyzed (a variable changing to a bad
value) can't happen in clojure. It has
Erlang basically treats strings in one or two ways. 1) as pure binary
data (useless for most cases) or 2) as a list of numbers. Imagine if
clojure treated strings like this: (43, 22, 23, 32, 43)
So when you print any list in Erlang it checks to make sure if all the
numbers in the list are in a val
Terseness and density is what attracted me to lisp-style languages in the
first place. In Clojure it is generally easier to locally comprehend
everything that is going on without having to go chasing through a bunch of
class definitions, and the code is often declarative enough to serve as its
own
> The Python approach leads to more readable
>code: http://www.mired.org/home/mwm/papers/readability.html
The two cases he sites do not apply to Clojure:
The first case is a function that is allowed to change the value of a
variable passed into it. Variables are immutable in Clojure so you can't
On Jun 28, 3:04 pm, Mike Meyer wrote:
> What you're calling "The LISP way" I first met under the name
> "bottom-up programming" - the only real difference is that LISP lets
> you muck about with what is syntax in other languages - except you
> pretty much have to stay with S-expressions in LISP (b
On Mon, 28 Jun 2010 13:20:28 -0700 (PDT)
cageface wrote:
> On Jun 28, 1:10 pm, Mike Meyer 620...@mired.org> wrote:
> > Not true as I understand "the Lisp way". You also need to reread the
> > last paragraph again.
> I actually agree with you that the typical block of lisp code is less
> readable
>
>
> I actually agree with you that the typical block of lisp code is less
> readable than the typical block of python. It bugs me when lisp
> advocates present s-expr syntax as the "right" way instead of the
> engineering tradeoff that it is.
This is mostly due to Python's "There is only one ob
On Jun 28, 1:10 pm, Mike Meyer wrote:
> Not true as I understand "the Lisp way". You also need to reread the
> last paragraph again.
I actually agree with you that the typical block of lisp code is less
readable than the typical block of python. It bugs me when lisp
advocates present s-expr synta
On Mon, 28 Jun 2010 12:18:58 -0700 (PDT)
cageface wrote:
> On Jun 28, 12:04 pm, Mike Meyer 620...@mired.org> wrote:
> > The Python approach leads to more readable
> > code:http://www.mired.org/home/mwm/papers/readability.html
>
> You don't seem to be very sympathetic to the Lisp way of doing t
On Jun 28, 12:04 pm, Mike Meyer wrote:
> The Python approach leads to more readable
> code:http://www.mired.org/home/mwm/papers/readability.html
You don't seem to be very sympathetic to the Lisp way of doing things.
What's your interest in Clojure?
--
You received this message because you are
On Mon, 28 Jun 2010 11:21:24 -0700 (PDT)
cageface wrote:
> On Jun 28, 11:09 am, Daniel Gagnon wrote:
> > That feature would *not* be a simple macro. It isn't simply a call to .close
> > on whatever object, it's an arbitrary cleanup procedure on any object that
> > implements the feature. The who
>
> So in order to make this work in Python the *entire* standard library
> had to be modified to support it? That's worse than I thought.
>
>
Only the objects that made sense with the use of with.
>
> The python approach is superior if you believe, as Guido apparently
> does, that the useful set
On Jun 28, 11:09 am, Daniel Gagnon wrote:
> That feature would *not* be a simple macro. It isn't simply a call to .close
> on whatever object, it's an arbitrary cleanup procedure on any object that
> implements the feature. The whole standard library implements it and objects
> know how to clean a
I haven't done any Erlang coding but I have heard various complaints
in blogs etc that Erlang isn't great for string handling.
Is that what you mean? Is Erlang a good or bad example of this?
On Jun 27, 1:11 pm, Timothy Baldridge wrote:
> "1. a string/text type"
>
> *cough * Erlang *cough *
>
> T
On Sun, Jun 27, 2010 at 2:58 PM, cageface wrote:
> When I read about new "features" in other languages that would be
> simple macros in Lisp I just have to smile:
> http://docs.python.org/dev/reference/compound_stmts.html#with
>
>
That feature would *not* be a simple macro. It isn't simply a call
Here's some of Rich Hickey's rationale, from an old IRC chat (http://
clojure-log.n01se.net/date/2008-11-06.html):
"Clojure doesn't allow user-defined reader macros because they can't
be combined - there's no namespace support, unlike for regular macros"
"the clash problem is significant - I don'
"1. a string/text type"
*cough * Erlang *cough *
Tim
--
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 po
Certainly macros can be dangerous if used recklessly or clumsily, but
> isn't trusting the programmer and giving him powerful tools what Lisp
> is all about? No other language provides the same power of expression.
> A tour through the Clojure code demonstrates just how powerful this
> idea is and
On Jun 27, 1:17 pm, Mike Meyer wrote:
> Not quite - it's to keep the language *readable*. And if there's a use
> case for a feature that outweighs the damage done by abusing it,
> they'll add it. Witness with, list comprehensions, and those
> never-to-sufficiently-cursed augmented assignment opera
On Sun, 27 Jun 2010 12:41:36 -0700 (PDT)
cageface wrote:
> Python definitely seems to be the product of a very different design
> philosophy than Lisp. I've always felt it was too prescriptive.
> Omitting features that *might* be misused in an effort to keep the
> language simple seems to have ba
Python definitely seems to be the product of a very different design
philosophy than Lisp. I've always felt it was too prescriptive.
Omitting features that *might* be misused in an effort to keep the
language simple seems to have backfired on them. Too keep up with the
competition they've had to ad
On Sun, 27 Jun 2010 11:58:16 -0700 (PDT)
cageface wrote:
> When I read about new "features" in other languages that would be
> simple macros in Lisp I just have to smile:
> http://docs.python.org/dev/reference/compound_stmts.html#with
Many in the Python community consider this an advantage of Py
When I read about new "features" in other languages that would be
simple macros in Lisp I just have to smile:
http://docs.python.org/dev/reference/compound_stmts.html#with
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send ema
24 matches
Mail list logo
