Jeez, one day Cello is loading GIFs and JPGs and PNGs and more without a
problem via ImageMagick, then it stops? Why? I don't know. Probably
because I installed a new version of IM. No, I am not running against
the new version, but I guess the installer installed over something used
by the old version and now the old IM has stopped working!
Why should it even stop working? because C is incredibly fragile that
way. Got line up those release numbers with a microscope.
When is the C community going to take up arms and cure this? I guess
they do not even think it is a problem, because you can build a business
just making C apps manageable. Users just toe the line and take abuse
for trying to use v8.3056 w v2.117.
So the first thing we have to do is build a consensus that there /is/ a
problem. I am sending Ron to talk to them.
:)
Ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
I really think that the recent slew of posts we have had about "CL
sucking" have been trying to make the point that CL, and its community,
is too resistant to change. For example we can all bitch about how C++
has issues, and as a C++ user I know that it does indeed have issues.
However they (the standards people) have promised us a new version,
C++0X, soon. In comparison there are no plans for updating the Common
Lisp standard. I think if there was a concrete plan for a CL0X that
promised to fix problems, add libraries, clean up CLOS, ect, people
wouldn't bitch. However if you suggest such a thing the CL community
goes a little crazy.
········@uci.edu wrote:
> I really think that the recent slew of posts we have had about "CL
> sucking" have been trying to make the point that CL, and its community,
> is too resistant to change. For example we can all bitch about how C++
> has issues, and as a C++ user I know that it does indeed have issues.
> However they (the standards people) have promised us a new version,
> C++0X, soon. In comparison there are no plans for updating the Common
> Lisp standard. I think if there was a concrete plan for a CL0X that
> promised to fix problems, add libraries, clean up CLOS, ect, people
> wouldn't bitch. However if you suggest such a thing the CL community
> goes a little crazy.
>
I am sorry, no, we are not starting that mind-numbing thread again.
:)
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Then maybe you shouldn't have started it again eh? I mean if you don't
want to talk about something than don't talk about it, not start a new
thread about it.
>Then maybe you shouldn't have started it again eh? I mean if you don't
>want to talk about something than don't talk about it, not start a new
>thread about it.
This does seem like a joke-ish thread just waiting to stir up some
controversy. While I do agree that there should be some discussion over
this, I do not believe this is the right way.
········@uci.edu wrote:
> Then maybe you shouldn't have started it again eh? I mean if you don't
> want to talk about something than don't talk about it, not start a new
> thread about it.
>
Oh, OK: apples and oranges.
Bjarne is going for the multi-paradigm thing this time around. ie, they
are still changing the language per se, trying to decide what C++ wants
to be when it grows up. Of course they need a formal process and
committees and votes and crap.
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
> Bjarne is going for the multi-paradigm thing this time around. ie, they
> are still changing the language per se, trying to decide what C++ wants
> to be when it grows up. Of course they need a formal process and
> committees and votes and crap.
Why should anyone take your opinions seriously? Besides, name-calling
directed at other languages won't improve CL in the slightest. If you
wish to believe that CL is perfect you can feel free to of course, but
at that point you have abandoned any pretense of being a rational
computer scientist, and are simply a cult member.
········@uci.edu wrote:
>>Bjarne is going for the multi-paradigm thing this time around. ie, they
>>are still changing the language per se, trying to decide what C++ wants
>>to be when it grows up. Of course they need a formal process and
>>committees and votes and crap.
>
>
> Why should anyone take your opinions seriously?
ha-ha, the argument sketch from Monty Python:
Continue that thread!
Ok.
Why should I listen to you?
You asked me to continue!
Did not.
Did, too!
Good one, you got me.
> Besides, name-calling
> directed at other languages won't improve CL in the slightest.
Name-calling? Where? Do you even know what C++0x is about? Hint: it is
not about adding a GUI to the C++ standard.... Oops. Bjarne says here:
http://public.research.att.com/~bs/rules.pdf
"The most commonly requested new feature for C++ is a standard GUI."
!!!! The same idiots must be running from NG to NG whining about
standard GUIs. But I was right in spirit, they have a separate process
for mo better standard libs as contrasted with language changes per se.
Now let's look at the list of open issues, suggestions, and proposals:
http://public.research.att.com/~bs/evol-issues.html
My favorite, a suggestion, in toto:
"ES017. Lambda.
???"
Can you say "culture gap"? Sher ya can. Now enter Greenspun:
ES049. Multimethods
Provide the ability to do a dynamic lookup on more than one operand.
Frequest suggestion."
ES057. Closures
"Like the ones in Borland C++"
ES062. Code blocks
Provide a way of providing code to be provided as arguments without
having to define a separate named function.
ES070. Allow default arguments for template template arguments
...and last but not least:
ES033. Optional garbage collection.
Explicitly acknowledge that garbage collection is a valid implementation
technique for C++ and define when destructors are called and what it
means for a an object to be unreferenced.
> If you
> wish to believe that CL is perfect you can feel free to of course, but
> at that point you have abandoned any pretense of being a rational
> computer scientist, and are simply a cult member.
>
You make that sound like a bad thing.
ken
--
Cells: http://common-lisp.net/project/cells/
"Well, I've wrestled with reality for 35 years, Doctor, and I'm happy to
state I finally won out over it." - Elwood P. Dowd
Ken Tilton wrote:
> > If you
> > wish to believe that CL is perfect you can feel free to of course, but
> > at that point you have abandoned any pretense of being a rational
> > computer scientist, and are simply a cult member.
> You make that sound like a bad thing.
On the count of three, chug that Kool-Aid!
<chugs glass of translucent blue liquid>
+ ········@uci.edu:
| Why should anyone take your opinions seriously?
Because Kenny is a serious guy, that's why.
His tone may be flippant, but don't let that fool you for a minute.
| Besides, name-calling directed at other languages won't improve CL
| in the slightest.
No, but it improves the mood. 8-)
Please don't take everything so seriously.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
········@uci.edu wrote:
> Then maybe you shouldn't have started it again eh? I mean if you don't
> want to talk about something than don't talk about it, not start a new
> thread about it.
Kenny talked about C and you about C++ and Common Lisp. So, who
has started what kind of thread?
Ken Tilton wrote:
> Jeez, one day Cello is loading GIFs and JPGs and PNGs and more without a
> problem via ImageMagick, then it stops? Why? I don't know. Probably
> because I installed a new version of IM. No, I am not running against
> the new version, but I guess the installer installed over something used
> by the old version and now the old IM has stopped working!
>
> Why should it even stop working? because C is incredibly fragile that
> way. Got line up those release numbers with a microscope.
>
> When is the C community going to take up arms and cure this? I guess
> they do not even think it is a problem, because you can build a business
> just making C apps manageable. Users just toe the line and take abuse
> for trying to use v8.3056 w v2.117.
>
> So the first thing we have to do is build a consensus that there /is/ a
> problem. I am sending Ron to talk to them.
>
> :)
>
> Ken
>
If this is to counter the "How CL Sucks" thread then it's got very weak
point.
C is so fragile because some programmer can create an installer and put
mismatch dll, configuration files? Sure this problem never happens with
CL. Every CL lib ALWAYS maintain full backward compatibility.
See, CL already solve this problem, by using ASDF you can install
multiple version of a library... err, wait, no. ASDF doesn't have that
concept of version dependency so...
ldconfig, Debian apt (via Python script?) or RubyGem has all solve
version dependency
Rubygem dependency can do things like
require 'foo', ">=1.5" # require foo library version 1.5 or above
require 'bar', "=~1.6" # require foo library version 1.6.* (any minor
upgrade is fine)
It is said that CL is so good at solving hard problem. May be, since
many silly toy language all have the tools for this problem, this is
too simple problem to be solved by CL. That's why CL package tool can
only do simple dependency.
"Pisin Bootvong" <··········@gmail.com> writes:
> C is so fragile because some programmer can create an installer and put
> mismatch dll, configuration files? Sure this problem never happens with
> CL. Every CL lib ALWAYS maintain full backward compatibility.
>
> See, CL already solve this problem, by using ASDF you can install
> multiple version of a library... err, wait, no. ASDF doesn't have that
> concept of version dependency so...
>
> ldconfig, Debian apt (via Python script?) or RubyGem has all solve
> version dependency
>
> Rubygem dependency can do things like
>
> require 'foo', ">=1.5" # require foo library version 1.5 or above
> require 'bar', "=~1.6" # require foo library version 1.6.* (any minor
> upgrade is fine)
>
> It is said that CL is so good at solving hard problem. May be, since
> many silly toy language all have the tools for this problem, this is
> too simple problem to be solved by CL. That's why CL package tool can
> only do simple dependency.
Why are you spending your time writing this instead of writing the
patch to asdf to support version dependencies?
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live.
Pascal Bourguignon wrote:
> "Pisin Bootvong" <··········@gmail.com> writes:
> > C is so fragile because some programmer can create an installer and put
> > mismatch dll, configuration files? Sure this problem never happens with
> > CL. Every CL lib ALWAYS maintain full backward compatibility.
> >
> > See, CL already solve this problem, by using ASDF you can install
> > multiple version of a library... err, wait, no. ASDF doesn't have that
> > concept of version dependency so...
> >
> > ldconfig, Debian apt (via Python script?) or RubyGem has all solve
> > version dependency
> >
> > Rubygem dependency can do things like
> >
> > require 'foo', ">=1.5" # require foo library version 1.5 or above
> > require 'bar', "=~1.6" # require foo library version 1.6.* (any minor
> > upgrade is fine)
> >
> > It is said that CL is so good at solving hard problem. May be, since
> > many silly toy language all have the tools for this problem, this is
> > too simple problem to be solved by CL. That's why CL package tool can
> > only do simple dependency.
>
> Why are you spending your time writing this instead of writing the
> patch to asdf to support version dependencies?
>
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> This is a signature virus. Add me to your signature and help me to live.
And why don't you spend your time writing that patch and send it for me
instead of just replying just to tell me to do it?
It must be even faster for seasoned programmer like you to do, isn't
it?
"Just shut up and code and send patch" goes both ways...
Now you have a chance to start first
"Pisin Bootvong" <··········@gmail.com> writes:
>> Why are you spending your time writing this instead of writing the
>> patch to asdf to support version dependencies?
>
> And why don't you spend your time writing that patch and send it for me
> instead of just replying just to tell me to do it?
> It must be even faster for seasoned programmer like you to do, isn't
> it?
>
> "Just shut up and code and send patch" goes both ways...
>
> Now you have a chance to start first
I've already sent in patches to clisp for example, even if not as many
as I'd like. Your turn. :-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
THIS IS A 100% MATTER PRODUCT: In the unlikely event that this
merchandise should contact antimatter in any form, a catastrophic
explosion will result.
+ Ken Tilton <·········@gmail.com>:
| Why should it even stop working? because C is incredibly fragile that
| way. Got line up those release numbers with a microscope.
|
| When is the C community going to take up arms and cure this?
Actually, I think they are. Well, maybe not the C community so much
as the Unix community. I understand there is work underway on
versionded dynamic libraries, which are not the standard dynamic
libraries with version numbers attached that we all love to hate, but
libraries which can contain different versions of the same function,
with the same function name and all. So your program can require
library A version 1 and library B version 2, while library A requires
library B version 3. No problem, libB.so can contain version 2 and 3
both, and functions in libA will link to version 3 while those in your
main program link to version 2. It may not solve every library
related problem under the sun, but it looks to me like a good step in
the right direction.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Harald Hanche-Olsen wrote:
> + Ken Tilton <·········@gmail.com>:
>
> | Why should it even stop working? because C is incredibly fragile that
> | way. Got line up those release numbers with a microscope.
> |
> | When is the C community going to take up arms and cure this?
>
> Actually, I think they are. Well, maybe not the C community so much
> as the Unix community. I understand there is work underway on
> versionded dynamic libraries, which are not the standard dynamic
> libraries with version numbers attached that we all love to hate, but
> libraries which can contain different versions of the same function,
> with the same function name and all.
Such libraries have been used on Linux for years. Six years ago I did
some work on glibc, where I had to make use of this: create different
versions of a function for old clients and new. These libraries still
have those version numbers that we love to hate, but they also contain
the versioned symbols.
Kaz Kylheku wrote:
> Harald Hanche-Olsen wrote:
>
>>+ Ken Tilton <·········@gmail.com>:
>>
>>| Why should it even stop working? because C is incredibly fragile that
>>| way. Got line up those release numbers with a microscope.
>>|
>>| When is the C community going to take up arms and cure this?
>>
>>Actually, I think they are. Well, maybe not the C community so much
>>as the Unix community. I understand there is work underway on
>>versionded dynamic libraries, which are not the standard dynamic
>>libraries with version numbers attached that we all love to hate, but
>>libraries which can contain different versions of the same function,
>>with the same function name and all.
>
>
> Such libraries have been used on Linux for years.
I must say to Harald, fat binaries are not a cure, they are a great
honking sign that something somewhere has gone terribly wrong and
something must be done to really solve the problem. Byte codes? I do not
know, but I cannot believe how complacent those people are. No wonder
everyone is talking about Python and Ruby and even Lisp.
How Ron is doing over on comp.lang.c?
:)
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Harald Hanche-Olsen wrote:
> + Ken Tilton <·········@gmail.com>:
>
> | Why should it even stop working? because C is incredibly fragile that
> | way. Got line up those release numbers with a microscope.
> |
> | When is the C community going to take up arms and cure this?
>
> Actually, I think they are. Well, maybe not the C community so much
> as the Unix community. I understand there is work underway on
> versionded dynamic libraries, which are not the standard dynamic
> libraries with version numbers attached that we all love to hate, but
> libraries which can contain different versions of the same function,
> with the same function name and all. So your program can require
> library A version 1 and library B version 2, while library A requires
> library B version 3. No problem, libB.so can contain version 2 and 3
> both, and functions in libA will link to version 3 while those in your
> main program link to version 2. It may not solve every library
> related problem under the sun, but it looks to me like a good step in
> the right direction.
>
Fat binary shared libraries? Interesting cross-platform proposition there..
--
+--------------------------------------------------------+
|Cyborg Animation Programmer | ·····@yagc.ndo.co.uk|
|http://badbyteblues.blogspot.com -----------------------|
+--------------------------------------------------------+