What's better about Ruby than Python?
adalke at mindspring.com
Thu Aug 21 09:13:51 CEST 2003
> Macros, as found in Common Lisp, do not change the underlying language
> at all! Common Lisp macros, when run, always expand into 100% ANSI
> Common Lisp code!
I've created a new language, called Speech. It's based on the core
primitives found in the International Phonetic Alphabet. I've made some
demos using Speech. One is English and another is Xhosa. This just
goes to show how powerful Speech is because it can handle so many
domains. And it's extensible! Anything you say can be expressed in
> Using macros to become more productive is no
> different from using function abstractions or class hierarchies to
> become more productive.
One of the most incredible things about Speech is that you can
create domain-specific words. Verbing doesn't wierd nouns -
it's perfectly crumbulent and embiggens the soul!
> They all require that you, the programmer, become familiar with them.
Someone else's new words simple require that you, the programmer,
become familar with them. You can even get dictionaries which
explain how each word is used in (most of) the different contexts you
might find it in. In many cases you can even infer the meaning, because
of built-in redundancy.
> Macros don't cause Common Lisp to fork
> anymore than function or class abstractions do.
Making new words don't cause Speech to fork any more than
making new sentences does.
> They only alter the
> readability of "program code" (usually for the better), just like
> function or class abstractions do.
They only alter the comprehension of "talking" (usually for the
> Saying that all hell will break loose in the Python community seems
> rather unfounded and a bit knee-jerk
Saying that different people will decide to use only a part of Speech,
and not understand all the variations when needed seems rather
unfounded and a bit knee-jerk.
> After years of macro use, ANSI Common Lisp
> is till the same. Macros don't bypass ANSI committees anymore than
> they would the Guidos of this world.
After years of Speech use, ANSI Common Speech is still
the same. New Speech doesn't bypass ANSI committees anymore
than they would the Shakespeares and Chief Josephs of the world.
> On the contrary, they preclude
> the need to bypass them in the first place, and all parties end up
> getting what they need: on the one hand, a static base language, and
> on the other, much greater expressiveness.
On the contrary, Speech definitions preclude the need to make
new languages, and all parties end up getting what they need:
on the one hand, a static core set of syllables, and on the other,
much greater expressiveness.
> Speaking of expressiveness, someone asked on comp.lang.lisp.fr what
> macros were good for, concretely, and what quantitative difference
> they made in commercial applications (cf. "Macros: est-ce utile ?
> (attn Marc)"). The responses (in French) were quite enlightening. It
> boils down to using multiple macros, in multiple instances, thus
> allowing to reduce total code size (of otherwise pure CL code) by VERY
> significant margins. You can think of it as reuse (as per OOP) or as
> code compression.
Speaking of expressiveness, someone in France suggested that
"courriel" was a better fit for their local Dialect of Speech, instead of
the word "e-mail". That's just one perfect example of how different
groups can customize Speech for internal consistancy in a given
doman. This allows users to keep a consistent set of pronounciation
rules and reduce the dictionary size.
> Macros do not have to be used all the time or at all. There are times
> when a macro should not be used, e.g. when a function would do just
Creating new words of Speech does not have to be done all the
time or at all. There are times when an existing word or a sentence
(a set of existing words) would do just fine.
> But they are very powerful.
But making new words is very powerful.
> As Paul Graham put it, macros allow
> you to program up towards the problem at hand, as opposed to adapting
> the problem to fit the language specification. They allow greater
> expressiveness, when you need it. They allow you to "use" many lines
> of code you no longer have to write. And the lines of code you don't
> have to write are also the lines of code you don't have to debug (as
> it were).
As Some Dude put it, neologisms allows you to Talk about the problem
at hand, as opposed to adapting the problem to fit the words you
know. They allow greater expressivenes and precision, when you need
it. They allow you to "use" many sentences you no longer have to say.
And the words you don't say are the ones you don't need to pronounce
(as it were).
In short, no one is denying that the ability to create new macros is
a powerful tool, just like no one denies that creating new words is
a powerful tool. But both require extra training and thought for
proper use, and while they are easy to write, it puts more effort
for others to understand you. If I stick to Python/English then
more people can understand me than if I mixed in a bit of Erlang/
Danish, *even* *if* the latter makes a more precise description
of the solution.
By this analogy, Guido is someone who can come up with words
that a lot of people find useful, while I am someone who can come
up withs words appropriate to my specialization, while most
people come up with words which are never used by anything
other than close friend. Like, totally tubular dude.
And since I know you want a demo of Speech, here's an
example of Xhosa and it's direct translation into English,
which doesn't have a single word for "going for a purpose"
Ndiya kulala. -- I am going for the purpose of sleeping.
And here's an example of Swedish with a translation into
English, which lack some of the geneaological terms
min mormor -- my maternal grandmother
I can combine those and say
Umormor uya kulala -- my maternal grandmother is going
for the purpose of sleeping.
See how much more precise that is because I can select
words from different Dialects of Speech?
dalke at dalkescientific.com
More information about the Python-list