| |
 |
|
| Computers Forum Index » Computer Languages (Misc) » fundamentalism, creativity, acceptance |
|
Page 1 of 1 |
|
| Author |
Message |
| cr88192 |
Posted: Mon Jan 03, 2005 8:41 am |
|
|
|
Guest
|
I think Paul Graham also had some cool thoughts on these subjects, one could
probably dig for them:
http://www.paulgraham.com/
from what I remember I think I am in disagreement, but I forget.
now, I have my own complaints about lisp anymore, but imo some are faults
shared with most languages...
a possible misguided thought of mine...
one thing I have seen in my experience is the occurance of fundamentalism
and creativity, and the apparent lack therof in mainstream languages.
mainstream languages are often older, and have both more cruft and
infexibilities than their counterparts, but are eventually replaced by
another which has some new features, but few that are particularly new on
the stance of creativity, nor does the language discard much for its seeming
development. many are about like some previous mainstream language, with
alterations.
fundamentalism leads to ripping out or ommiting features which the designer
doesn't like, or redefining them in some awkward way. some central set of
idioms is stressed, and sometimes the result can be interesting.
quite often, however, the language falls short on nearly every other front,
and has little chance of gaining any widespread use. even if it can do
something interesting, quite often it is difficult to understand the
language to guess at what that might be.
creativity often leads to things which are just weird or a broken form of
something else. creativity is often at odds with being conservative, keeping
what can be kept and making things feel fammiliar to those who are new, or
retaining much elegance or simplicity if the language becomes capable of
doing much. those being creative might not notice or borrow much from even
well known and comprable ideas, often discounting them for obvious reasons.
now mainstream languages, made over time in the forge of utility, are
typically neither. unoriginal masses of cruft piled together over time. the
less original the better so long as it does something the previous couldn't,
kind of a slight value added that might not be obvious at first glance.
of course, here it is incredibly difficult to change or effect anything, or
at least absent mass amounts of hype and money being forced into it to gain
even meager momentum. then is a more annoying condition: something being
pushed down one's throat by others regardless of whether or not it looks
useful or offers any real advantage of what they have allready, and
sometimes it is worse, a trap for those with poor judgement. this force in
effect being also anti-conservative.
but all this is not only what defines success, there are the issues of what
is allready in use and what has the most system support, or imo the power
and ease of the ffi. an ffi where it is trivial to switch to a language
without losing one's code or api's is a plus.
then there is popularity, which is partly driven by experience, word of
mouth, and hype. without this, few know something exists, or if they do they
know little.
and so forth...
so what? I don't know.
do I have any real change of my language becomming popular? I somehow doubt
it, seriously...
it is at least sort of conservative, but is also in many ways too creative,
and dies in that it has nearly no support nor much of any real ffi.
it at least works for my own code, it is not (too) all encompasing, and
resembles some other more popular languages. otherwise, I would have to use
other's languages, which typically have things I don't like about them, and
I like doing stuff myself...
somehow I think there are a lot here in the same general condition.
oh well, whatever, it was this or read a book some (or come up with
something to code...). |
|
|
| Back to top |
|
|
|
| Mike Austin |
Posted: Mon Jan 03, 2005 10:42 am |
|
|
|
Guest
|
I believe that creativity is simply the blending of two or more
unrelated ideas. That is the creativity - to see something in things
which are not alike. Hardly anything is created entirely from scratch -
be it music, art, language or any other subject which takes skill to
perform. In my pet language project, I've been pulling ideas from many
different corners and trying to combine, refactor and simplify them.
I think the best way to promote a language is to use it. Use it in a
project like a game, where it can be stress tested and also provide real
world example code. Also, try to look at the language from an
outsider's perspective. Sometimes things look so clear to us, but no
two people have the same perceptions. Your target audience makes a big
difference, too. Postscript was not designed for beginners, neither was
C. Python and Ruby are much easier to learn, but I think too much has
been added over time making them bloated.
For example, Python has "readlines" and also "xreadlines", which is the
same method except it is a lazy collection, i.e. you can iterate over a
file line by line without having to read in the entire file.
Personally, I'm fond of having every collection being lazy, and using
'collect' or similar to turn it into a list. I also like the separation
of functions and sub-objects. Hmm, in fact, collect without arguments
would be a nice fit - to generate a list out of a lazy collection.
lines = file lines collect
Regards,
Mike
cr88192 wrote:
Quote: I think Paul Graham also had some cool thoughts on these subjects, one could
probably dig for them:
http://www.paulgraham.com/
from what I remember I think I am in disagreement, but I forget.
now, I have my own complaints about lisp anymore, but imo some are faults
shared with most languages...
a possible misguided thought of mine...
one thing I have seen in my experience is the occurance of fundamentalism
and creativity, and the apparent lack therof in mainstream languages.
mainstream languages are often older, and have both more cruft and
infexibilities than their counterparts, but are eventually replaced by
another which has some new features, but few that are particularly new on
the stance of creativity, nor does the language discard much for its seeming
development. many are about like some previous mainstream language, with
alterations.
fundamentalism leads to ripping out or ommiting features which the designer
doesn't like, or redefining them in some awkward way. some central set of
idioms is stressed, and sometimes the result can be interesting.
quite often, however, the language falls short on nearly every other front,
and has little chance of gaining any widespread use. even if it can do
something interesting, quite often it is difficult to understand the
language to guess at what that might be.
creativity often leads to things which are just weird or a broken form of
something else. creativity is often at odds with being conservative, keeping
what can be kept and making things feel fammiliar to those who are new, or
retaining much elegance or simplicity if the language becomes capable of
doing much. those being creative might not notice or borrow much from even
well known and comprable ideas, often discounting them for obvious reasons.
now mainstream languages, made over time in the forge of utility, are
typically neither. unoriginal masses of cruft piled together over time. the
less original the better so long as it does something the previous couldn't,
kind of a slight value added that might not be obvious at first glance.
of course, here it is incredibly difficult to change or effect anything, or
at least absent mass amounts of hype and money being forced into it to gain
even meager momentum. then is a more annoying condition: something being
pushed down one's throat by others regardless of whether or not it looks
useful or offers any real advantage of what they have allready, and
sometimes it is worse, a trap for those with poor judgement. this force in
effect being also anti-conservative.
but all this is not only what defines success, there are the issues of what
is allready in use and what has the most system support, or imo the power
and ease of the ffi. an ffi where it is trivial to switch to a language
without losing one's code or api's is a plus.
then there is popularity, which is partly driven by experience, word of
mouth, and hype. without this, few know something exists, or if they do they
know little.
and so forth...
so what? I don't know.
do I have any real change of my language becomming popular? I somehow doubt
it, seriously...
it is at least sort of conservative, but is also in many ways too creative,
and dies in that it has nearly no support nor much of any real ffi.
it at least works for my own code, it is not (too) all encompasing, and
resembles some other more popular languages. otherwise, I would have to use
other's languages, which typically have things I don't like about them, and
I like doing stuff myself...
somehow I think there are a lot here in the same general condition.
oh well, whatever, it was this or read a book some (or come up with
something to code...).
|
|
|
| Back to top |
|
|
|
| cr88192 |
Posted: Mon Jan 03, 2005 1:44 pm |
|
|
|
Guest
|
"Mike Austin" <no@spam.com> wrote in message
news:Q29Cd.1215303$Gx4.1054851@bgtnsc04-news.ops.worldnet.att.net...
Quote: I believe that creativity is simply the blending of two or more unrelated
ideas. That is the creativity - to see something in things which are not
alike. Hardly anything is created entirely from scratch - be it music,
art, language or any other subject which takes skill to perform. In my pet
language project, I've been pulling ideas from many different corners and
trying to combine, refactor and simplify them.
ok, yeah.
a lot borrows from other languages.
Quote: I think the best way to promote a language is to use it. Use it in a
project like a game, where it can be stress tested and also provide real
world example code. Also, try to look at the language from an outsider's
perspective. Sometimes things look so clear to us, but no two people have
the same perceptions. Your target audience makes a big difference, too.
Postscript was not designed for beginners, neither was C. Python and Ruby
are much easier to learn, but I think too much has been added over time
making them bloated.
ok.
beginners, dunno wrt my lang, more it is designed for myself I guess, but
has some newbie-centric design choices.
Quote: For example, Python has "readlines" and also "xreadlines", which is the
same method except it is a lazy collection, i.e. you can iterate over a
file line by line without having to read in the entire file. Personally,
I'm fond of having every collection being lazy, and using 'collect' or
similar to turn it into a list. I also like the separation of functions
and sub-objects. Hmm, in fact, collect without arguments would be a nice
fit - to generate a list out of a lazy collection.
lines = file lines collect
dunno, different topic really.
I have a builtin "readline" method, along with a "split" method for strings.
may need another split as the current one doesn't handle quotes, but really,
I am not intending my lang for text processing.
or whatever... |
|
|
| Back to top |
|
|
|
| Wildhalcyon |
Posted: Sat Jan 08, 2005 4:41 am |
|
|
|
Guest
|
Acceptance rarely leads to creativity. Generally, the very interesting
creative stuff happens on the outside edges. C, C++... they've been
extremely utilitarian programming languages, but 99.999% of the users
don't do creative things with them, and won't because it's mainstream
and who needs that? It certainly added much to the computer science
world early on, but nowadays, the real knowledge and research is being
gained from other programming languages, and other paradigms.
At some point in time, programming is going to reach a point where man
can be the architect of a brain more powerful than the human brain, and
I can guarantee that it won't be programmed in C. |
|
|
| Back to top |
|
|
|
| unknown user |
Posted: Sat Jan 08, 2005 4:43 pm |
|
|
|
Guest
|
I personally think that any syntax used in a language should, for all
intensive purposes, match with the general idea of the language. I gave
Erc an obscure syntax because I wanted it to represent how I believed
Erc code should be visualized. I don't know if that's as creative as it
seems, but it certainly is practical. |
|
|
| Back to top |
|
|
|
| Wildhalcyon |
Posted: Sat Jan 08, 2005 6:43 pm |
|
|
|
Guest
|
Im not trying to knock C - C has some great ideas, but I think that
computing itself will have changed much more by then. Assuming that
it's just traditional computation (no quantum computing), I think that
quite a few things would have to change. The computer would probably
consist of millions of independent processors that could make and break
their own connections with each other, creating a dynamic network, and
all of that would require constructs that are not yet in the languages.
Would data even matter? If we're trying to create an artificial brain,
is there a place to store bits and strings? |
|
|
| Back to top |
|
|
|
| cr88192 |
Posted: Sun Jan 09, 2005 1:44 am |
|
|
|
Guest
|
"Wildhalcyon" <wildhalcyon@hotmail.com> wrote in message
news:1105206810.696550.299470@c13g2000cwb.googlegroups.com...
Quote: Im not trying to knock C - C has some great ideas, but I think that
computing itself will have changed much more by then. Assuming that
it's just traditional computation (no quantum computing), I think that
quite a few things would have to change. The computer would probably
consist of millions of independent processors that could make and break
their own connections with each other, creating a dynamic network, and
all of that would require constructs that are not yet in the languages.
Would data even matter? If we're trying to create an artificial brain,
is there a place to store bits and strings?
these are semantic issues and not syntactic ones.
I am arguing that the language could be nearly completely different, and
still have a syntax that resembles c, or some similar constructs.
things like memory management, or even whether the language is
imperative/functional/... or whether it is serial or a fine-grained
concurrent language, are really side issues wrt this.
eg:
what if I add a construct 'thread {...}'? does this somehow break a c-like
style? imo no.
what if I add functions that are called asynchronously? the semantics are
quite different, but the syntax doesn't necissarily look different really at
all.
foo(2, 3);
bar();
whether foo or bar gets called first is only defined if we define that the
language is synchronous, otherwise the syntax doesn't give this away.
what if foo is not a function at all? still, little different, that fragment
of syntax need not care.
all this is semantic.
all this is imo like the comment made about erlang that concurrency does not
necissarily need to be stuck on a functional language. it can be put on
nearly any model one feels (well, within reason, a concurrent forth, for
example, would be a little weird...).
just like, the only real requirement of syntax is that it fits the language
it is put on, but style is a much more liquid force, its constraints lie
elsewhere.
of course, too many changes and it starts looking quite different. some of
the examples I have written before showing me using more functional styles
much less resemble c, but still far more than many other clearly different
languages.
imo, similar could be said about, eg, s-expressions. however, imo,
s-expressions are far less flexible in some ways. s-expressions imply how
they are structured and are less appriciative of some of the common "abuse"
of c-style syntax.
yet, imo, one could use s-exps on many languages radically different from
lisp, but one looking at the code would likely feel at least that it
resembles lisp.
on the other hand, however, a forth style syntax would much more constrain
the models and applicable style, but even then, a pure functional language
with a vaguely forth style syntax seems within the realm of reason (though
currying could be difficult...). with a bit more tweaking a syntax like
forth could become one like in self, no longer executing commands but
defining the flow of messages. all this, and it may not have even really
changed much in appearance.
all this is not necissary, but I am trying to stress a point. |
|
|
| Back to top |
|
|
|
| cr88192 |
Posted: Sun Jan 09, 2005 1:44 am |
|
|
|
Guest
|
"unknown user" <john.ohno@gmail.com> wrote in message
news:1105200698.639874.224200@c13g2000cwb.googlegroups.com...
Quote: I personally think that any syntax used in a language should, for all
intensive purposes, match with the general idea of the language. I gave
Erc an obscure syntax because I wanted it to represent how I believed
Erc code should be visualized. I don't know if that's as creative as it
seems, but it certainly is practical.
it is maybe practical, but in a general sense the style of syntax does not
necissarily constrain the language that can be represented with it, and even
a syntax designed from the ground up for a particular style of language
could somewhat resemble one used on a different style.
there are limits though, eg, the syntax for variable declarations in many
c-style syntaxes is rather ambiguous and problematic apart from using a
context-sensitive parser, and not all languages have statements per-se.
these, however, are not show stoppers imo. one could, eg, view all
statements as expressions and the semicolon as something like a comma
operator or whatever...
yes, in many variants some issues would have to be worked out during such a
generalization (eg: the meaning of similar syntax having different meanings
in expression/statement context, ...). imo, these are not show stoppers
either...
one, however, can be creative or use something different if they feel like
it. |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Sun Nov 22, 2009 1:24 am
|
|