On Aug 19, 2:31 pm, ssecorp <············@gmail.com> wrote:
> What are you LISPers opinion of Haskell?
>
> Pros and cons compared to LISP?
Pros: Haskell is cool loaded with cool features
Cons: Haskell is not Lisp
On Aug 19, 12:31 pm, ssecorp <············@gmail.com> wrote:
> What are you LISPers opinion of Haskell?
>
> Pros and cons compared to LISP?
Caveat: It's been a while since I've used Haskell (2-3 yrs), and I've
only been working in common lisp recently (2 yrs)
I remember Haskell being very succinct, and having a very powerful
typing system. Lisp has more of the former, and much less of the
latter. Although very flexible, and good at catching errors at compile
time, I found the typing system in Haskell sometimes got in the way.
Lisp let's you declare types, but if you don't want to you don't have
to, and this tends to make it more flexible than Haskell. Furthermore,
with good unit testing, the sorts of errors one would catch in
haskell, also get caught early on in lisp.
Likewise, although Haskell has some capacity to define new language
constructs, Lisp's macros are more powerful, and this provides a
further degree of flexibility.
Haskell's built-in syntax has more succinct ways of describing things
like list comprehensions, return of multiple variables from a
function, and function currying. The assumed lazy evaluation also
means that you can do some very pretty stuff with 'infinite' lists,
that get's a little uglier in lisp. However, I also find Haskell to be
harder to read than lisp, largely because of these very features.
I also seem to recall haskell being pretty slow, but that might just
have been the compiler I was using, and what I was using it for. Lisp
on the other hand can be quite fast. (I believe some claim, as fast or
faster than C).
So in summary:
Haskell: a more powerful type checking system, that can catch more
errors, more succinct for some operations. Not quite as readable as
lisp
Lisp: More flexible. Faster. Possibly less succinct for particular
applications, but often the flexibility means you can define
constructs that lead to more succinct code than one would write in
Haskell. Possibly less error catching at compile time, but unit
testing can largely make up for this.
Perhaps I am biased in this regard, but I generally prefer Lisp.
Though I might consider using Haskell for a well defined problem where
I knew the sort of lazy evaluation and pattern matching that is easily
expressed in Haskell would be useful.
DeverLite <············@gmail.com> writes:
> [...] Although very flexible, and good at catching errors at compile
> time, I found the typing system in Haskell sometimes got in the way.
> Lisp let's you declare types, but if you don't want to you don't have
> to, and this tends to make it more flexible than Haskell.
Actually, what the lisp type system means is that in lisp we program
in generic mode by default.
When you write:
int fact(int x){ return (x<=0)?1:x*fact(x-1); }
it's statically typed, but it's also SPECIFICALLY typed.
When you write in lisp:
(defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
it's already a generic function (not a lisp generic function,
technically, but what other programming languages call a generic
function):
(mapcar 'fact '(4 4.0 4.0l0 5/2))
--> (24 24.0 24.0L0 15/8)
to get the same in C++ you would have to write:
#include <rational.hxx>
template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}
... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...
I hope Haskell is able to derive these instances automatically.
But you can easily get even more genericity, either using non CL
operators that you can easily redefine (eg. as lisp generic
functions), by shadowing them to the same effect, or by using
functions passed in argument. CL:SORT is generic because it takes a
LESSP function, so it can be applied on sequences of any kind of
object.
So what statically checked type system proponents detract as duck
typing is actually that lisp works in the Generic Mode gears by
default.
--
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!
On Aug 19, 7:07 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> DeverLite <············@gmail.com> writes:
> > [...] Although very flexible, and good at catching errors at compile
> > time, I found the typing system in Haskell sometimes got in the way.
> > Lisp let's you declare types, but if you don't want to you don't have
> > to, and this tends to make it more flexible than Haskell.
>
> Actually, what the lisp type system means is that in lisp we program
> in generic mode by default.
>
> When you write:
>
> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> it's statically typed, but it's also SPECIFICALLY typed.
>
> When you write in lisp:
>
> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> it's already a generic function (not a lisp generic function,
> technically, but what other programming languages call a generic
> function):
>
> (mapcar 'fact '(4 4.0 4.0l0 5/2))
> --> (24 24.0 24.0L0 15/8)
>
> to get the same in C++ you would have to write:
>
> #include <rational.hxx>
> template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}
>
> ... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...
>
> I hope Haskell is able to derive these instances automatically.
>
> But you can easily get even more genericity, either using non CL
> operators that you can easily redefine (eg. as lisp generic
> functions), by shadowing them to the same effect, or by using
> functions passed in argument. CL:SORT is generic because it takes a
> LESSP function, so it can be applied on sequences of any kind of
> object.
>
> So what statically checked type system proponents detract as duck
> typing is actually that lisp works in the Generic Mode gears by
> default.
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> I need a new toy.
> Tail of black dog keeps good time.
> Pounce! Good dog! Good dog!
Right. Thanks for the clarification. I didn't mean to imply that there
was no typing by default in lisp: just that it wasn't something you
had to *declare*.
On 2008-08-20, DeverLite <············@gmail.com> wrote:
> Right. Thanks for the clarification. I didn't mean to imply that there
> was no typing by default in lisp: just that it wasn't something you
> had to *declare*.
Static type systems that require declarations are not state-of-the-art. A
statically typed language isn't defined as one which requires everything to be
declared prior to use. The requirement for explicit declarations merely
reflects 1960's state-of-the-art in static typing (even though it happens to be
a feature of some programming languages designed in the 1990's).
On Thu, 28 Aug 2008 22:45:35 +0000 (UTC), Kaz Kylheku
<········@gmail.com> wrote:
>On 2008-08-20, DeverLite <············@gmail.com> wrote:
>> Right. Thanks for the clarification. I didn't mean to imply that there
>> was no typing by default in lisp: just that it wasn't something you
>> had to *declare*.
>
>Static type systems that require declarations are not state-of-the-art. A
>statically typed language isn't defined as one which requires everything to be
>declared prior to use. The requirement for explicit declarations merely
>reflects 1960's state-of-the-art in static typing (even though it happens to be
>a feature of some programming languages designed in the 1990's).
That's true ... but except in some simple instances, inference systems
can't infer the programmer's intended theoretical type, but only an ad
hoc type, or set of types, consistent with how the programmer uses the
variables. Declarations are (potentially at least) closer to the
intended theoretical type.
Personally I believe inference is fine for internal use but external
interfaces should always be explicitly declared. YMMV.
George
Kaz Kylheku wrote:
> On 2008-08-20, DeverLite <············@gmail.com> wrote:
>> Right. Thanks for the clarification. I didn't mean to imply that there
>> was no typing by default in lisp: just that it wasn't something you
>> had to *declare*.
>
> Static type systems that require declarations are not state-of-the-art.
So SML, Haskell and F# aren't state-of-the-art because they require sum
types to be declared?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
DeverLite wrote:
> Right. Thanks for the clarification. I didn't mean to imply that there
> was no typing by default in lisp: just that it wasn't something you
> had to *declare*.
You don't have to declare it in Haskell. E.g. save this as Test.hs:
module Test where
import Data.Ratio
fact x = if x <= 0 then 1 else x * fact (x-1)
and then you can test it with a Haskell REPL, like GHCi:
*Test> :load Test
[1 of 1] Compiling Test ( Test.hs, interpreted )
Ok, modules loaded: Test.
*Test> :type fact
fact :: (Num a, Ord a) => a -> a
*Test> fact 4
24
*Test> fact 4.0
24.0
*Test> fact 4::Double
24.0
*Test> fact (5%2)
15%8
*Test> take 10 [fact x | x <- [1..]]
[1,2,6,24,120,720,5040,40320,362880,3628800]
I really like the last example :-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On 19 ago, 21:07, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Actually, what the lisp type system means is that in lisp we program
> in generic mode by default.
>
> When you write:
>
> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> it's statically typed, but it's also SPECIFICALLY typed.
Yes.
> When you write in lisp:
>
> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> it's already a generic function
Not quite. More on that in a moment.
> to get the same in C++ you would have to write:
>
> #include <rational.hxx>
> template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}
>
> ... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...
The C++ example with template is far more generic than the Lisp one:
it's defined for all types T capable of handling operatotions <= and
*, whereas the Lisp one just takes them for granted over numbers.
Of course, in the case of factorial, it doesn't matter, but it means
you can have complex datatypes redefining useful operators (or
functions) *at compile time*. Same for Haskell. Functions are
defined and dispatched per type.
You could of course do something like this, say, in Scheme:
(define +
(let ((o+ +))
(lambda (a b . more)
(apply (if (string? a)
string-append
o+)
(cons a (cons b more))))))
and use it more "generically" like this:
(+ 1 2 3 4 5) => 15
(+ "foo" "bar") => "foobar"
In implementations which actually permit redefining such fundamental
functions.
But then, you gotta do run-time checks on the arguments not present in
the Haskell and C++ compile-time functions. Note such checks can go
on as you nest deep into possibly yet previous redefinitions of the
operator that do almost like the above.
> But you can easily get even more genericity, either using non CL
> operators that you can easily redefine (eg. as lisp generic
> functions), by shadowing them to the same effect, or by using
> functions passed in argument. CL:SORT is generic because it takes a
> LESSP function, so it can be applied on sequences of any kind of
> object.
These are all fine workarounds, even though perhaps more verbose than
simply being able to do function "overloading" per types. Sorry if I
sound froggy.
On Aug 20, 1:01 am, namekuseijin <············@gmail.com> wrote:
> On 19 ago, 21:07, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> > Actually, what the lisp type system means is that in lisp we program
> > in generic mode by default.
>
> > When you write:
>
> > int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> > it's statically typed, but it's also SPECIFICALLY typed.
>
> Yes.
>
> > When you write in lisp:
>
> > (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> > it's already a generic function
>
> Not quite. More on that in a moment.
>
> > to get the same in C++ you would have to write:
>
> > #include <rational.hxx>
> > template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}
>
> > ... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...
>
> The C++ example with template is far more generic than the Lisp one:
> it's defined for all types T capable of handling operatotions <= and
> *, whereas the Lisp one just takes them for granted over numbers.
>
> Of course, in the case of factorial, it doesn't matter, but it means
> you can have complex datatypes redefining useful operators (or
> functions) *at compile time*. Same for Haskell. Functions are
> defined and dispatched per type.
>
> You could of course do something like this, say, in Scheme:
> (define +
> (let ((o+ +))
> (lambda (a b . more)
> (apply (if (string? a)
> string-append
> o+)
> (cons a (cons b more))))))
or Common Lisp (with semi-Prolog naming convention).
(defmethod +//2 ((x string) (y string))
(concatenate 'string x y))
(defmethod +//2 ((x number) (y number))
(cl:+ x y))
(defun extmath:+ (x y &rest more-summable-things)
(reduce '+//2 more-summable-things
:initial-value (+//2 x y)))
You can expand on this code as much as you want.
Cheers
--
Marco
On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> DeverLite <············@gmail.com> writes:
> > [...] Although very flexible, and good at catching errors at compile
> > time, I found the typing system in Haskell sometimes got in the way.
> > Lisp let's you declare types, but if you don't want to you don't have
> > to, and this tends to make it more flexible than Haskell.
>
> Actually, what the lisp type system means is that in lisp we program
> in generic mode by default.
>
> When you write:
>
> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> it's statically typed, but it's also SPECIFICALLY typed.
>
> When you write in lisp:
>
> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> it's already a generic function (not a lisp generic function,
> technically, but what other programming languages call a generic
> function):
>
> (mapcar 'fact '(4 4.0 4.0l0 5/2))
> --> (24 24.0 24.0L0 15/8)
But the mathematical factorial function is defined only on natural
numbers, hence this behavior is most likely incorrect.
Moreover, in dynamically typed languages like Lisp there is the risk
of having a statement like this buried deep in your program:
(if (or (long-and-complicated-computation-returned-true) (user-pressed-
ctrl-alt-shift-tab-right-mouse-button))
(setq bomb "goodbye")
(setq bomb 42))
And then somewhere else a (fact bomb) makes your program crash and
your client angry.
> to get the same in C++ you would have to write:
>
> #include <rational.hxx>
> template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}
>
> ... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...
>
> I hope Haskell is able to derive these instances automatically.
Why do you hope so, given that this behavior is likely to be
incorrect?
Anyway, Haskell infers a generic type if you don't provide type
declarations, but it's generally considered a good programming
practice to provide type declarations precisely to avoid such kind of
behaviors.
> But you can easily get even more genericity, either using non CL
> operators that you can easily redefine (eg. as lisp generic
> functions), by shadowing them to the same effect, or by using
> functions passed in argument. CL:SORT is generic because it takes a
> LESSP function, so it can be applied on sequences of any kind of
> object.
>
> So what statically checked type system proponents detract as duck
> typing is actually that lisp works in the Generic Mode gears by
> default.
I'm not sure about Common Lisp, but in Scheme, while arithmetic
operators are overloaded, most library function aren't (there are
different procedures for doing the same operation on lists, vectors,
strings and streams, for instance), hence I wouldn't consider the
language particularly generically typed.
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> I need a new toy.
> Tail of black dog keeps good time.
> Pounce! Good dog! Good dog!
In article
<····································@k13g2000hse.googlegroups.com>,
Vend <······@virgilio.it> wrote:
> On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
> > DeverLite <············@gmail.com> writes:
> > > [...] Although very flexible, and good at catching errors at compile
> > > time, I found the typing system in Haskell sometimes got in the way.
> > > Lisp let's you declare types, but if you don't want to you don't have
> > > to, and this tends to make it more flexible than Haskell.
> >
> > Actually, what the lisp type system means is that in lisp we program
> > in generic mode by default.
> >
> > When you write:
> >
> > int fact(int x){ return (x<=0)?1:x*fact(x-1); }
> >
> > it's statically typed, but it's also SPECIFICALLY typed.
> >
> > When you write in lisp:
> >
> > (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
> >
> > it's already a generic function (not a lisp generic function,
> > technically, but what other programming languages call a generic
> > function):
> >
> > (mapcar 'fact '(4 4.0 4.0l0 5/2))
> > --> (24 24.0 24.0L0 15/8)
>
> But the mathematical factorial function is defined only on natural
> numbers, hence this behavior is most likely incorrect.
>
> Moreover, in dynamically typed languages like Lisp there is the risk
> of having a statement like this buried deep in your program:
>
> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> ctrl-alt-shift-tab-right-mouse-button))
> (setq bomb "goodbye")
> (setq bomb 42))
>
> And then somewhere else a (fact bomb) makes your program crash and
> your client angry.
The Lisp program will not crash. It will display an error,
dump an error report or send mail. The parts of the Lisp
program that don't have the bug will continue to run just fine.
If you want you can make the program send an error
report and a backtrace to the developer. He can send
a fix back, the client can load it and continue
to work without ever leaving his program.
It is quite fascinating to see how clients react to incremental
fixes that can be loaded - instead of waiting for a complete
new build or bug fix release of the complete software.
You can often see Lisp vendors shipping releases and then for
years only giving small patches to the customers. Often the
patches can be loaded into a running system.
For example the Lisp based server I'm using does not crash
every other day. I update the software from time to time
mostly while the server runs. When there is some problem
the server sends a mail with the error condition and
a backtrace. I log into the machine, connect to the
running software and fix the problem while it is running.
Actually problems are much better to debug, since all the
data and the software information (typed self-identifying objects,
documentation, etc.) is still there.
Lisp has been perfected over the years to support exactly this:
handling errors safely at runtime. In the last years
64bit Lisp systems have been used with very large datasets.
Crashing is no option. Handling errors is.
>
> > to get the same in C++ you would have to write:
> >
> > #include <rational.hxx>
> > template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}
> >
> > ... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...
> >
> > I hope Haskell is able to derive these instances automatically.
>
> Why do you hope so, given that this behavior is likely to be
> incorrect?
>
> Anyway, Haskell infers a generic type if you don't provide type
> declarations, but it's generally considered a good programming
> practice to provide type declarations precisely to avoid such kind of
> behaviors.
>
> > But you can easily get even more genericity, either using non CL
> > operators that you can easily redefine (eg. as lisp generic
> > functions), by shadowing them to the same effect, or by using
> > functions passed in argument. CL:SORT is generic because it takes a
> > LESSP function, so it can be applied on sequences of any kind of
> > object.
> >
> > So what statically checked type system proponents detract as duck
> > typing is actually that lisp works in the Generic Mode gears by
> > default.
>
> I'm not sure about Common Lisp, but in Scheme, while arithmetic
> operators are overloaded, most library function aren't (there are
> different procedures for doing the same operation on lists, vectors,
> strings and streams, for instance), hence I wouldn't consider the
> language particularly generically typed.
Common Lisp has lots of limited generic functions. For example
there are operations that work on sequences. Sequences are
for example vectors and lists.
Common Lisp also has CLOS, the Common Lisp Object System,
where 'generic functions' are a basic building block.
>
> > --
> > __Pascal Bourguignon__ http://www.informatimago.com/
> > I need a new toy.
> > Tail of black dog keeps good time.
> > Pounce! Good dog! Good dog!
--
http://lispm.dyndns.org/
On 28 Ago, 20:38, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@k13g2000hse.googlegroups.com>,
>
>
>
> Vend <······@virgilio.it> wrote:
> > On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> > > DeverLite <············@gmail.com> writes:
> > > > [...] Although very flexible, and good at catching errors at compile
> > > > time, I found the typing system in Haskell sometimes got in the way.
> > > > Lisp let's you declare types, but if you don't want to you don't have
> > > > to, and this tends to make it more flexible than Haskell.
>
> > > Actually, what the lisp type system means is that in lisp we program
> > > in generic mode by default.
>
> > > When you write:
>
> > > int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> > > it's statically typed, but it's also SPECIFICALLY typed.
>
> > > When you write in lisp:
>
> > > (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> > > it's already a generic function (not a lisp generic function,
> > > technically, but what other programming languages call a generic
> > > function):
>
> > > (mapcar 'fact '(4 4.0 4.0l0 5/2))
> > > --> (24 24.0 24.0L0 15/8)
>
> > But the mathematical factorial function is defined only on natural
> > numbers, hence this behavior is most likely incorrect.
>
> > Moreover, in dynamically typed languages like Lisp there is the risk
> > of having a statement like this buried deep in your program:
>
> > (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> > ctrl-alt-shift-tab-right-mouse-button))
> > (setq bomb "goodbye")
> > (setq bomb 42))
>
> > And then somewhere else a (fact bomb) makes your program crash and
> > your client angry.
>
> The Lisp program will not crash. It will display an error,
> dump an error report or send mail. The parts of the Lisp
> program that don't have the bug will continue to run just fine.
The program will not crash with a segfault like C/C++ programs do, but
usually it will still terminate abruptly giving an error message which
is probably unintellegible to the user.
Even if you design your programs to catch the error, send a bug report
and try to keep running, probably there will be some loss of
functionality.
Which, in the specific case under discussion, wouldn't happen in a
statically typed language.
> If you want you can make the program send an error
> report and a backtrace to the developer. He can send
> a fix back, the client can load it and continue
> to work without ever leaving his program.
> It is quite fascinating to see how clients react to incremental
> fixes that can be loaded - instead of waiting for a complete
> new build or bug fix release of the complete software.
> You can often see Lisp vendors shipping releases and then for
> years only giving small patches to the customers. Often the
> patches can be loaded into a running system.
>
> For example the Lisp based server I'm using does not crash
> every other day. I update the software from time to time
> mostly while the server runs. When there is some problem
> the server sends a mail with the error condition and
> a backtrace. I log into the machine, connect to the
> running software and fix the problem while it is running.
>
> Actually problems are much better to debug, since all the
> data and the software information (typed self-identifying objects,
> documentation, etc.) is still there.
>
> Lisp has been perfected over the years to support exactly this:
> handling errors safely at runtime. In the last years
> 64bit Lisp systems have been used with very large datasets.
> Crashing is no option. Handling errors is.
>
>
>
>
>
> > > to get the same in C++ you would have to write:
>
> > > #include <rational.hxx>
> > > template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}
>
> > > ... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...
>
> > > I hope Haskell is able to derive these instances automatically.
>
> > Why do you hope so, given that this behavior is likely to be
> > incorrect?
>
> > Anyway, Haskell infers a generic type if you don't provide type
> > declarations, but it's generally considered a good programming
> > practice to provide type declarations precisely to avoid such kind of
> > behaviors.
>
> > > But you can easily get even more genericity, either using non CL
> > > operators that you can easily redefine (eg. as lisp generic
> > > functions), by shadowing them to the same effect, or by using
> > > functions passed in argument. CL:SORT is generic because it takes a
> > > LESSP function, so it can be applied on sequences of any kind of
> > > object.
>
> > > So what statically checked type system proponents detract as duck
> > > typing is actually that lisp works in the Generic Mode gears by
> > > default.
>
> > I'm not sure about Common Lisp, but in Scheme, while arithmetic
> > operators are overloaded, most library function aren't (there are
> > different procedures for doing the same operation on lists, vectors,
> > strings and streams, for instance), hence I wouldn't consider the
> > language particularly generically typed.
>
> Common Lisp has lots of limited generic functions. For example
> there are operations that work on sequences. Sequences are
> for example vectors and lists.
>
> Common Lisp also has CLOS, the Common Lisp Object System,
> where 'generic functions' are a basic building block.
>
>
>
> > > --
> > > __Pascal Bourguignon__ http://www.informatimago.com/
> > > I need a new toy.
> > > Tail of black dog keeps good time.
> > > Pounce! Good dog! Good dog!
>
> --http://lispm.dyndns.org/
In article
<····································@l42g2000hsc.googlegroups.com>,
Vend <······@virgilio.it> wrote:
> On 28 Ago, 20:38, Rainer Joswig <······@lisp.de> wrote:
> > In article
> > <····································@k13g2000hse.googlegroups.com>,
> >
> >
> >
> > �Vend <······@virgilio.it> wrote:
> > > On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
> > > wrote:
> > > > DeverLite <············@gmail.com> writes:
> > > > > [...] Although very flexible, and good at catching errors at compile
> > > > > time, I found the typing system in Haskell sometimes got in the way.
> > > > > Lisp let's you declare types, but if you don't want to you don't have
> > > > > to, and this tends to make it more flexible than Haskell.
> >
> > > > Actually, what the lisp type system means is that in lisp we program
> > > > in generic mode by default.
> >
> > > > When you write:
> >
> > > > � �int fact(int x){ return (x<=0)?1:x*fact(x-1); }
> >
> > > > it's statically typed, but it's also SPECIFICALLY typed.
> >
> > > > When you write in lisp:
> >
> > > > � �(defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
> >
> > > > it's already a generic function (not a lisp generic function,
> > > > technically, but what other programming languages call a generic
> > > > function):
> >
> > > > � �(mapcar 'fact '(4 4.0 4.0l0 5/2))
> > > > � � --> (24 24.0 24.0L0 15/8)
> >
> > > But the mathematical factorial function is defined only on natural
> > > numbers, hence this behavior is most likely incorrect.
> >
> > > Moreover, in dynamically typed languages like Lisp there is the risk
> > > of having a statement like this buried deep in your program:
> >
> > > (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> > > ctrl-alt-shift-tab-right-mouse-button))
> > > � (setq bomb "goodbye")
> > > � (setq bomb 42))
> >
> > > And then somewhere else a (fact bomb) makes your program crash and
> > > your client angry.
> >
> > The Lisp program will not crash. It will display an error,
> > dump an error report or send mail. The parts of the Lisp
> > program that don't have the bug will continue to run just fine.
>
> The program will not crash with a segfault like C/C++ programs do, but
> usually it will still terminate abruptly giving an error message which
> is probably unintellegible to the user.
Why should it terminate? It will continue to run in most cases.
Why should the error message be unintellegible? The programmer
has full control over error handling and can present any type
of error user interface she likes.
>
> Even if you design your programs to catch the error, send a bug report
> and try to keep running, probably there will be some loss of
> functionality.
Sure. But you might want to consider that Erlang for example
is dynamically typed and designed to run extremely
complex telco software with zero downtime. There
are applications where a loss of some functionality
can be tolerated, but not the crash of the whole software.
Errors are isolated and fixed at runtime. Shutting down
a central switching system of a telco with many
customers affected is no option. Patching the running
system in a controlled fashion is an option.
Isn't it ironic that dynamically typed software
is at the heart of extremely demanding
applications with zero downtime?
The same is true for some Lisp systems. Before Erlang existed,
AT&T / Lucent built similar systems (ATM switches) in Lisp.
It was also designed for zero downtime. The switching nodes
were running LispWorks on some embedded systems.
>
> Which, in the specific case under discussion, wouldn't happen in a
> statically typed language.
Check this:
RJMBP:~ joswig$ sbcl
This is SBCL 1.0.16, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (defun foo (a) (let ((bar 3)) (setf bar "baz") (+ bar a)))
; in: LAMBDA NIL
; (+ BAR A)
;
; note: deleting unreachable code
;
; caught WARNING:
; Asserted type NUMBER conflicts with derived type
; (VALUES (SIMPLE-ARRAY CHARACTER (3)) &OPTIONAL).
; See also:
; The SBCL Manual, Node "Handling of Types"
;
; compilation unit finished
; caught 1 WARNING condition
; printed 1 note
FOO
*
Looks like Lisp has detected that I want to set a variable
to a string and later want to use it in an addition.
>
> > If you want you can make the program send an error
> > report and a backtrace to the developer. He can send
> > a fix back, the client can load it and continue
> > to work without ever leaving his program.
> > It is quite fascinating to see how clients react to incremental
> > fixes that can be loaded - instead of waiting for a complete
> > new build or bug fix release of the complete software.
> > You can often see Lisp vendors shipping releases and then for
> > years only giving small patches to the customers. Often the
> > patches can be loaded into a running system.
> >
> > For example the Lisp based server I'm using does not crash
> > every other day. I update the software from time to time
> > mostly while the server runs. When there is some problem
> > the server sends a mail with the error condition and
> > a backtrace. I log into the machine, connect to the
> > running software and fix the problem while it is running.
> >
> > Actually problems are much better to debug, since all the
> > data and the software information (typed self-identifying objects,
> > documentation, etc.) is still there.
> >
> > Lisp has been perfected over the years to support exactly this:
> > handling errors safely at runtime. In the last years
> > 64bit Lisp systems have been used with very large datasets.
> > Crashing is no option. Handling errors is.
> >
> >
> >
> >
> >
> > > > to get the same in C++ you would have to write:
> >
> > > > � #include <rational.hxx>
> > > > � template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}
> >
> > > > � ... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...
> >
> > > > I hope Haskell is able to derive these instances automatically.
> >
> > > Why do you hope so, given that this behavior is likely to be
> > > incorrect?
> >
> > > Anyway, Haskell infers a generic type if you don't provide type
> > > declarations, but it's generally considered a good programming
> > > practice to provide type declarations precisely to avoid such kind of
> > > behaviors.
> >
> > > > But you can easily get even more genericity, either using non CL
> > > > operators that you can easily redefine (eg. as lisp generic
> > > > functions), by shadowing them to the same effect, or by using
> > > > functions passed in argument. �CL:SORT is generic because it takes a
> > > > LESSP function, so it can be applied on sequences of any kind of
> > > > object.
> >
> > > > So what statically checked type system proponents detract as duck
> > > > typing is actually that lisp works in the Generic Mode gears by
> > > > default.
> >
> > > I'm not sure about Common Lisp, but in Scheme, while arithmetic
> > > operators are overloaded, most library function aren't (there are
> > > different procedures for doing the same operation on lists, vectors,
> > > strings and streams, for instance), hence I wouldn't consider the
> > > language particularly generically typed.
> >
> > Common Lisp has lots of limited generic functions. For example
> > there are operations that work on sequences. Sequences are
> > for example vectors and lists.
> >
> > Common Lisp also has CLOS, the Common Lisp Object System,
> > where 'generic functions' are a basic building block.
> >
> >
> >
> > > > --
> > > > __Pascal Bourguignon__ � � � � � � � � � �http://www.informatimago.com/
> > > > I need a new toy.
> > > > Tail of black dog keeps good time.
> > > > Pounce! Good dog! Good dog!
> >
> > --http://lispm.dyndns.org/
--
http://lispm.dyndns.org/
Vend wrote:
> On 28 Ago, 20:38, Rainer Joswig <······@lisp.de> wrote:
>> In article
>> <····································@k13g2000hse.googlegroups.com>,
>>
>>
>>
>> Vend <······@virgilio.it> wrote:
>>> On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
>>> wrote:
>>>> DeverLite <············@gmail.com> writes:
>>>>> [...] Although very flexible, and good at catching errors at compile
>>>>> time, I found the typing system in Haskell sometimes got in the way.
>>>>> Lisp let's you declare types, but if you don't want to you don't have
>>>>> to, and this tends to make it more flexible than Haskell.
>>>> Actually, what the lisp type system means is that in lisp we program
>>>> in generic mode by default.
>>>> When you write:
>>>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>>>> it's statically typed, but it's also SPECIFICALLY typed.
>>>> When you write in lisp:
>>>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>>>> it's already a generic function (not a lisp generic function,
>>>> technically, but what other programming languages call a generic
>>>> function):
>>>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
>>>> --> (24 24.0 24.0L0 15/8)
>>> But the mathematical factorial function is defined only on natural
>>> numbers, hence this behavior is most likely incorrect.
>>> Moreover, in dynamically typed languages like Lisp there is the risk
>>> of having a statement like this buried deep in your program:
>>> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
>>> ctrl-alt-shift-tab-right-mouse-button))
>>> (setq bomb "goodbye")
>>> (setq bomb 42))
>>> And then somewhere else a (fact bomb) makes your program crash and
>>> your client angry.
>> The Lisp program will not crash. It will display an error,
>> dump an error report or send mail. The parts of the Lisp
>> program that don't have the bug will continue to run just fine.
>
> The program will not crash with a segfault like C/C++ programs do, but
> usually it will still terminate abruptly giving an error message which
> is probably unintellegible to the user.
>
> Even if you design your programs to catch the error, send a bug report
> and try to keep running, probably there will be some loss of
> functionality.
You don't seem to be well-informed about what's possible in good dynamic
languages.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Vend wrote:
>> Even if you design your programs to catch the error, send a bug report
>> and try to keep running, probably there will be some loss of
>> functionality.
>
> You don't seem to be well-informed about what's possible in good dynamic
> languages.
Can you be more generic?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2008-08-28, Vend <······@virgilio.it> wrote:
> On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> DeverLite <············@gmail.com> writes:
>> > [...] Although very flexible, and good at catching errors at compile
>> > time, I found the typing system in Haskell sometimes got in the way.
>> > Lisp let's you declare types, but if you don't want to you don't have
>> > to, and this tends to make it more flexible than Haskell.
>>
>> Actually, what the lisp type system means is that in lisp we program
>> in generic mode by default.
>>
>> When you write:
>>
>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>>
>> it's statically typed, but it's also SPECIFICALLY typed.
>>
>> When you write in lisp:
>>
>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>>
>> it's already a generic function (not a lisp generic function,
>> technically, but what other programming languages call a generic
>> function):
>>
>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
>> --> (24 24.0 24.0L0 15/8)
>
> But the mathematical factorial function is defined only on natural
> numbers, hence this behavior is most likely incorrect.
That is nonsense. The factorial function has generalizations which behave like
factorial for the natural numbers.
Remove foot from mouth and visit:
http://en.wikipedia.org/wiki/Gamma_function
Of course, the above function isn't the gamma function. That's beside the
point; we could fix FACT so that it computes the gamma in the general case, but
is optimized using the factorial for special cases.
> Moreover, in dynamically typed languages like Lisp there is the risk
> of having a statement like this buried deep in your program:
Bombs can be buried in code written in any programming language.
> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> ctrl-alt-shift-tab-right-mouse-button))
> (setq bomb "goodbye")
> (setq bomb 42))
You can use any mainstream programming language to hide an easter egg that is
activated by ctrl-alt-shift-tab-right-mouse-button, and other conditions.
> And then somewhere else a (fact bomb) makes your program crash and
> your client angry.
This is false. The program will not crash, but rather signal a condition, which
is something different.
Type is simply being treated as a run-time value.
Yes, when some run-time object has an invalid value, that is a programming bug.
Congratulations on figuring that out!
If types are not allowed to be run-time values, programmers invent ad-hoc type
systems which use existing value representations (such as integral
enumerations) as type.
For instance, in the BSD operating system, open files are represented by a
``struct vnode''. That's the C language type, but there is a ``v_type'' field
which can be, for instance, VDIR.
Faced with the static programming language, the programmers have hacked up an
ad-hoc, fragile form of dynamic typing which /really/ breaks if a critical type
check is missing. There is no recoverable condition. What happens is that the
kernel crashes, or worse: the filesystem becomes corrupt.
Of course, the Lisp kernel is built on a foundation of static typing rigidity.
Just like the BSD kernel, thanks to C static type checking, will not (in the
absence of memory corruption or bad casts) mistakenly treat the ``v_type''
field of a struct vnode as anything but a of type ``enum vtype'', the Lisp will
correctly, reliably treat the bits of a value which represent its type.
If the given Lisp system encodes some type information in the top three bits of
the word representing a value, then by golly, all of its operations will
reliably store and retrieve that type information in those top three bits.
So you see there is the same kind of low-level static typing going on in Lisp,
and similar languages, just under the hood.
The programmer-visible types in Lisp are a higher level concept, because it's a
higher level language. They are simply an additional kind of domain value
attributed to an object. They are not like type in a static language, even
though they express the same concept in simple-minded programs which
ipmlement a design that is also directly implementable in a static language.
Dynamic typing allows an entire class maintainable, clear, useful program
/designs/ to be coded in the obvious, straightforward way, and safely executed
in the presence of run-time checks.
Static typing which rejects the straightforward implementation of these designs
nevertheless allows the programmer to implement these designs in a different
way, one which is not so straightforward, and not well supported (or at all) in
the language. Not only can this be done, but it is regular practice.
> I'm not sure about Common Lisp, but in Scheme ...
Trolling asshole, since you're sending articles to comp.lang.lisp rather than
comp.lang.scheme, maybe you should take a few steps to become sure.
On 29 Ago, 00:06, Kaz Kylheku <········@gmail.com> wrote:
> On 2008-08-28, Vend <······@virgilio.it> wrote:
>
>
>
> > On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> DeverLite <············@gmail.com> writes:
> >> > [...] Although very flexible, and good at catching errors at compile
> >> > time, I found the typing system in Haskell sometimes got in the way.
> >> > Lisp let's you declare types, but if you don't want to you don't have
> >> > to, and this tends to make it more flexible than Haskell.
>
> >> Actually, what the lisp type system means is that in lisp we program
> >> in generic mode by default.
>
> >> When you write:
>
> >> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> >> it's statically typed, but it's also SPECIFICALLY typed.
>
> >> When you write in lisp:
>
> >> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> >> it's already a generic function (not a lisp generic function,
> >> technically, but what other programming languages call a generic
> >> function):
>
> >> (mapcar 'fact '(4 4.0 4.0l0 5/2))
> >> --> (24 24.0 24.0L0 15/8)
>
> > But the mathematical factorial function is defined only on natural
> > numbers, hence this behavior is most likely incorrect.
>
> That is nonsense. The factorial function has generalizations which behave like
> factorial for the natural numbers.
>
> Remove foot from mouth and visit:
>
> http://en.wikipedia.org/wiki/Gamma_function
I'm aware of that function, which isn't what Pascal's code calculates.
> Of course, the above function isn't the gamma function.
Indeed.
> That's beside the
> point;
No, that's the point: You made an useless remark.
> we could fix FACT so that it computes the gamma in the general case, but
> is optimized using the factorial for special cases.
In which case it would be desirable to have two different definitions:
one for integers and one for reals, which means that generic
programming would be of no use.
> > Moreover, in dynamically typed languages like Lisp there is the risk
> > of having a statement like this buried deep in your program:
>
> Bombs can be buried in code written in any programming language.
>
> > (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> > ctrl-alt-shift-tab-right-mouse-button))
> > (setq bomb "goodbye")
> > (setq bomb 42))
>
> You can use any mainstream programming language to hide an easter egg that is
> activated by ctrl-alt-shift-tab-right-mouse-button, and other conditions.
You missed the point.
That was not an example of an easter egg, that was meant to illustrate
that type errors can occur in response to external input or complex
calculations in dynamical typed systems.
> > And then somewhere else a (fact bomb) makes your program crash and
> > your client angry.
>
> This is false. The program will not crash, but rather signal a condition, which
> is something different.
Ok. Let's say it will malfunction, ok?
> Type is simply being treated as a run-time value.
>
> Yes, when some run-time object has an invalid value, that is a programming bug.
> Congratulations on figuring that out!
>
> If types are not allowed to be run-time values, programmers invent ad-hoc type
> systems which use existing value representations (such as integral
> enumerations) as type.
>
> For instance, in the BSD operating system, open files are represented by a
> ``struct vnode''. That's the C language type, but there is a ``v_type'' field
> which can be, for instance, VDIR.
>
> Faced with the static programming language, the programmers have hacked up an
> ad-hoc, fragile form of dynamic typing which /really/ breaks if a critical type
> check is missing. There is no recoverable condition. What happens is that the
> kernel crashes, or worse: the filesystem becomes corrupt.
>
> Of course, the Lisp kernel is built on a foundation of static typing rigidity.
>
> Just like the BSD kernel, thanks to C static type checking, will not (in the
> absence of memory corruption or bad casts) mistakenly treat the ``v_type''
> field of a struct vnode as anything but a of type ``enum vtype'', the Lisp will
> correctly, reliably treat the bits of a value which represent its type.
>
> If the given Lisp system encodes some type information in the top three bits of
> the word representing a value, then by golly, all of its operations will
> reliably store and retrieve that type information in those top three bits.
>
> So you see there is the same kind of low-level static typing going on in Lisp,
> and similar languages, just under the hood.
>
> The programmer-visible types in Lisp are a higher level concept, because it's a
> higher level language. They are simply an additional kind of domain value
> attributed to an object. They are not like type in a static language, even
> though they express the same concept in simple-minded programs which
> ipmlement a design that is also directly implementable in a static language.
>
> Dynamic typing allows an entire class maintainable, clear, useful program
> /designs/ to be coded in the obvious, straightforward way, and safely executed
> in the presence of run-time checks.
>
> Static typing which rejects the straightforward implementation of these designs
> nevertheless allows the programmer to implement these designs in a different
> way, one which is not so straightforward, and not well supported (or at all) in
> the language. Not only can this be done, but it is regular practice.
>
> > I'm not sure about Common Lisp, but in Scheme ...
>
> Trolling asshole, since you're sending articles to comp.lang.lisp rather than
> comp.lang.scheme, maybe you should take a few steps to become sure.
Scheme is Lisp.
Vend wrote:
> On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> DeverLite <············@gmail.com> writes:
>>> [...] Although very flexible, and good at catching errors at compile
>>> time, I found the typing system in Haskell sometimes got in the way.
>>> Lisp let's you declare types, but if you don't want to you don't have
>>> to, and this tends to make it more flexible than Haskell.
>> Actually, what the lisp type system means is that in lisp we program
>> in generic mode by default.
>>
>> When you write:
>>
>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>>
>> it's statically typed, but it's also SPECIFICALLY typed.
>>
>> When you write in lisp:
>>
>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>>
>> it's already a generic function (not a lisp generic function,
>> technically, but what other programming languages call a generic
>> function):
>>
>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
>> --> (24 24.0 24.0L0 15/8)
>
> But the mathematical factorial function is defined only on natural
> numbers, hence this behavior is most likely incorrect.
Who said that his definition is about the "mathematical factorial function"?
> Moreover, in dynamically typed languages like Lisp there is the risk
> of having a statement like this buried deep in your program:
>
> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> ctrl-alt-shift-tab-right-mouse-button))
> (setq bomb "goodbye")
> (setq bomb 42))
The risk is very low, unless you have total retards working on your code
base.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 28 Ago, 23:43, Pascal Costanza <····@p-cos.net> wrote:
> Vend wrote:
> > On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> DeverLite <············@gmail.com> writes:
> >>> [...] Although very flexible, and good at catching errors at compile
> >>> time, I found the typing system in Haskell sometimes got in the way.
> >>> Lisp let's you declare types, but if you don't want to you don't have
> >>> to, and this tends to make it more flexible than Haskell.
> >> Actually, what the lisp type system means is that in lisp we program
> >> in generic mode by default.
>
> >> When you write:
>
> >> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> >> it's statically typed, but it's also SPECIFICALLY typed.
>
> >> When you write in lisp:
>
> >> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> >> it's already a generic function (not a lisp generic function,
> >> technically, but what other programming languages call a generic
> >> function):
>
> >> (mapcar 'fact '(4 4.0 4.0l0 5/2))
> >> --> (24 24.0 24.0L0 15/8)
>
> > But the mathematical factorial function is defined only on natural
> > numbers, hence this behavior is most likely incorrect.
>
> Who said that his definition is about the "mathematical factorial function"?
>
> > Moreover, in dynamically typed languages like Lisp there is the risk
> > of having a statement like this buried deep in your program:
>
> > (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> > ctrl-alt-shift-tab-right-mouse-button))
> > (setq bomb "goodbye")
> > (setq bomb 42))
>
> The risk is very low, unless you have total retards working on your code
> base.
>
> Pascal
My example was specifically written to make the flaw apparent, but are
you sure that these situations are rare in practice?
Have you ever seen a program which manages a collection of objects of
heterogeneous type, which isn't know at compile-time?
Now let's assume there is an operation done infrequently on some
objects of that collection, which works on all the possible types
except an infrequently occurring one.
Maybe the guy who wrote that operation wasn't aware of the existence
of that type, or wasn't thinking about it, or that type was added
later by someone not aware of the existence and contract of that
operation. It doesn't seem a very unlikely scenario does it?
Anyway the result will be an infrequent runtime type error which will
probably escape the testing.
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
On Aug 28, 4:13 pm, Vend <······@virgilio.it> wrote:
>
> Have you ever seen a program which manages a collection of objects of
> heterogeneous type, which isn't know at compile-time?
>
> Now let's assume there is an operation done infrequently on some
> objects of that collection, which works on all the possible types
> except an infrequently occurring one.
Yes, there are programming errors that can be caught by static type
checking. I don't think anyone is disputing that.
But there are also plenty of errors that cannot be caught by static
typing. Any substantial program these days, even in a statically
typed language, has (or should have) numerous calls to `assert' or the
equivalent, checking preconditions of operations at runtime that
cannot be checked statically. Often, a formal proof that a particular
assertion is not violated would be quite difficult to produce; there
certainly is no static analyzer out there that can generate such
proofs in very many cases.
So although static typing does catch some errors, and can be useful,
it can't catch all of them. Furthermore, the ones it does catch are
those that are relatively easy to find anyway because they primarily
show up as violations of local constraints. Those that require deep
analysis, and particularly those requiring inductive proofs, are out
of its reach.
Static typing advocates want to make this a difference of kind, but
it's really just a difference of degree. With static typing, you
invest more effort up front and accept some limitations on the way you
can write your program, and in exchange the compiler finds some bugs
for you. It's a tradeoff. I'm not even saying it's never a trade
worth making. But in the end you still have to write interface
documentation to (try to) make sure that clients of your interface
don't abuse it.
-- Scott
On 2008-08-28, Vend <······@virgilio.it> wrote:
> Have you ever seen a program which manages a collection of objects of
> heterogeneous type, which isn't know at compile-time?
This is almost the same as asking, ``Have you worked in the software
industry for any period within the last twenty years?''
Vend wrote:
> On 28 Ago, 23:43, Pascal Costanza <····@p-cos.net> wrote:
>> Vend wrote:
>>> On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
>>> wrote:
>>>> DeverLite <············@gmail.com> writes:
>>>>> [...] Although very flexible, and good at catching errors at compile
>>>>> time, I found the typing system in Haskell sometimes got in the way.
>>>>> Lisp let's you declare types, but if you don't want to you don't have
>>>>> to, and this tends to make it more flexible than Haskell.
>>>> Actually, what the lisp type system means is that in lisp we program
>>>> in generic mode by default.
>>>> When you write:
>>>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>>>> it's statically typed, but it's also SPECIFICALLY typed.
>>>> When you write in lisp:
>>>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>>>> it's already a generic function (not a lisp generic function,
>>>> technically, but what other programming languages call a generic
>>>> function):
>>>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
>>>> --> (24 24.0 24.0L0 15/8)
>>> But the mathematical factorial function is defined only on natural
>>> numbers, hence this behavior is most likely incorrect.
>> Who said that his definition is about the "mathematical factorial function"?
>>
>>> Moreover, in dynamically typed languages like Lisp there is the risk
>>> of having a statement like this buried deep in your program:
>>> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
>>> ctrl-alt-shift-tab-right-mouse-button))
>>> (setq bomb "goodbye")
>>> (setq bomb 42))
>> The risk is very low, unless you have total retards working on your code
>> base.
>>
>> Pascal
>
> My example was specifically written to make the flaw apparent, but are
> you sure that these situations are rare in practice?
What if they are rare: How would you recognize that?
> Have you ever seen a program which manages a collection of objects of
> heterogeneous type, which isn't know at compile-time?
Yep, I use them quite a lot actually.
> Now let's assume there is an operation done infrequently on some
> objects of that collection, which works on all the possible types
> except an infrequently occurring one.
>
> Maybe the guy who wrote that operation wasn't aware of the existence
> of that type, or wasn't thinking about it, or that type was added
> later by someone not aware of the existence and contract of that
> operation. It doesn't seem a very unlikely scenario does it?
>
> Anyway the result will be an infrequent runtime type error which will
> probably escape the testing.
That's all just speculation.
Where do you see the masses of experience reports and anecdotes how such
errors _actually_ screw up software systems?
The most often reported screw up is buffer overruns, which can be
exploited in security attacks. Such overruns are best handled by dynamic
checks.
You see the pattern?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 29 Ago, 01:31, Pascal Costanza <····@p-cos.net> wrote:
> Vend wrote:
> > On 28 Ago, 23:43, Pascal Costanza <····@p-cos.net> wrote:
> >> Vend wrote:
> >>> On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
> >>> wrote:
> >>>> DeverLite <············@gmail.com> writes:
> >>>>> [...] Although very flexible, and good at catching errors at compile
> >>>>> time, I found the typing system inHaskellsometimes got in the way.
> >>>>> Lisp let's you declare types, but if you don't want to you don't have
> >>>>> to, and this tends to make it more flexible thanHaskell.
> >>>> Actually, what the lisp type system means is that in lisp we program
> >>>> in generic mode by default.
> >>>> When you write:
> >>>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
> >>>> it's statically typed, but it's also SPECIFICALLY typed.
> >>>> When you write in lisp:
> >>>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
> >>>> it's already a generic function (not a lisp generic function,
> >>>> technically, but what other programming languages call a generic
> >>>> function):
> >>>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
> >>>> --> (24 24.0 24.0L0 15/8)
> >>> But the mathematical factorial function is defined only on natural
> >>> numbers, hence this behavior is most likely incorrect.
> >> Who said that his definition is about the "mathematical factorial function"?
>
> >>> Moreover, in dynamically typed languages like Lisp there is the risk
> >>> of having a statement like this buried deep in your program:
> >>> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> >>> ctrl-alt-shift-tab-right-mouse-button))
> >>> (setq bomb "goodbye")
> >>> (setq bomb 42))
> >> The risk is very low, unless you have total retards working on your code
> >> base.
>
> >> Pascal
>
> > My example was specifically written to make the flaw apparent, but are
> > you sure that these situations are rare in practice?
>
> What if they are rare: How would you recognize that?
>
> > Have you ever seen a program which manages a collection of objects of
> > heterogeneous type, which isn't know at compile-time?
>
> Yep, I use them quite a lot actually.
>
> > Now let's assume there is an operation done infrequently on some
> > objects of that collection, which works on all the possible types
> > except an infrequently occurring one.
>
> > Maybe the guy who wrote that operation wasn't aware of the existence
> > of that type, or wasn't thinking about it, or that type was added
> > later by someone not aware of the existence and contract of that
> > operation. It doesn't seem a very unlikely scenario does it?
>
> > Anyway the result will be an infrequent runtime type error which will
> > probably escape the testing.
>
> That's all just speculation.
>
> Where do you see the masses of experience reports and anecdotes how such
> errors _actually_ screw up software systems?
>
> The most often reported screw up is buffer overruns, which can be
> exploited in security attacks.
Which affect programs written in C and C++.
> Such overruns are best handled by dynamic
> checks.
They are best handled by a combination of static and dynamic checks,
put in place by the compiler. Leaving array access unchecked like C/C+
+ do, is the worst way of doing it. It was justifiable given the
original design goal of C: a semi-portable efficient mid-level
language for OS programming, but it's a shame that it still remains in
modern C++.
> You see the pattern?
>
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
Vend wrote:
> On 29 Ago, 01:31, Pascal Costanza <····@p-cos.net> wrote:
>> The most often reported screw up is buffer overruns, which can be
>> exploited in security attacks.
>
> Which affect programs written in C and C++.
>
>> Such overruns are best handled by dynamic
>> checks.
>
> They are best handled by a combination of static and dynamic checks,
Pascal was a language that checked array boundaries statically. If I
recall correctly, that was a serious failure in language design. Most
languages I am aware of perform array boundary checks dynamically, and
for good reason.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 2008-08-29, Vend <······@virgilio.it> wrote:
> They are best handled by a combination of static and dynamic checks,
> put in place by the compiler.
Bet you've never held down a serious software job.
What exactly are your credentials?
> Leaving array access unchecked like C/C++ do
Under-informed idiot, C++ has higher level arrays in the std::vector template.
Of course, it retains compatibility with C by supporting C-like arrays.
In C++ you can easily program in a style which makes buffer overflows
impossible.
> is the worst way of doing it. It was justifiable given the
> original design goal of C: a semi-portable efficient mid-level
> language for OS programming, but it's a shame that it still remains in
> modern C++.
Doh, without its high level of C compatibility, C++ wouldn't be what it is.
C++ code can directly use platform interfaces which are defined in C, if only a
little care is taken in the header files (which is common practice nowadays).
In C++ you can directly #include some platform header, POSIX, Win32 or
whatever, and link to the corresponding library. The functions in that library
might use C style arrays. For instance, if you call uname on a Unix-like
system, the struct utsname structure contains C arrays. You can use that
directly from C++, arrays and all, without having to deal with any kind of
clunky foreign function wrapping.
Go back on kook medication.
On 29 Ago, 21:00, Kaz Kylheku <········@gmail.com> wrote:
> On 2008-08-29, Vend <······@virgilio.it> wrote:
>
> > They are best handled by a combination of static and dynamic checks,
> > put in place by the compiler.
>
> Bet you've never held down a serious software job.
>
> What exactly are your credentials?
Are you attempting to mount and argument from authority?
> > Leaving array access unchecked like C/C++ do
>
> Under-informed idiot, C++ has higher level arrays in the std::vector template.
Which isn't the language default implementation of arrays.
Moreover, the [] operator of std::vector isn't required to perform
boundary checks.
> Of course, it retains compatibility with C by supporting C-like arrays.
It uses C-like arrays as it's default and native implementation of
arrays, that's more than just retaining compatibility.
A compatibility that isn't complete anyway: an array allocated with
'new' can't be safely deallocated with 'free()' and an array allocated
with 'malloc()' can't be safely deallocated with 'delete []'.
And anyway I presume that it wouldn't be so difficult to add array
bounds checking to C and C++.
All heap-allocated arrays already contain length information in some
form to allow deallocation, so one would just need to add length
information for stack-allocated and global arrays in a consistent
representation.
I presume that the main problem would be preserving compatibility with
existing binary interfaces.
> In C++ you can easily program in a style which makes buffer overflows
> impossible.
Yes, in C too.
> > is the worst way of doing it. It was justifiable given the
> > original design goal of C: a semi-portable efficient mid-level
> > language for OS programming, but it's a shame that it still remains in
> > modern C++.
>
> Doh, without its high level of C compatibility, C++ wouldn't be what it is.
>
> C++ code can directly use platform interfaces which are defined in C, if only a
> little care is taken in the header files (which is common practice nowadays).
> In C++ you can directly #include some platform header, POSIX, Win32 or
> whatever, and link to the corresponding library. The functions in that library
> might use C style arrays. For instance, if you call uname on a Unix-like
> system, the struct utsname structure contains C arrays. You can use that
> directly from C++, arrays and all, without having to deal with any kind of
> clunky foreign function wrapping.
>
> Go back on kook medication.
Says somebody who insults people on the internet.
P� Sat, 30 Aug 2008 12:59:14 +0200, skrev Vend <······@virgilio.it>:
>
> And anyway I presume that it wouldn't be so difficult to add array
> bounds checking to C and C++.
> All heap-allocated arrays already contain length information in some
> form to allow deallocation, so one would just need to add length
> information for stack-allocated and global arrays in a consistent
> representation.
>
> I presume that the main problem would be preserving compatibility with
> existing binary interfaces.
>
And do.. Microsoft's C/C++ has this as a optional feature.
It can also check for stack overflow and stack overwrite (in software)
Also on newer Intel processors you can have DEP protection. (Data
Execution Prevention)
(I recommend changing the OS setting to enable it for all programs even
that can cause some older programs to abort.)
For the last 25 years I have always run C/C++ with a bounds checker.
(CodeGuard or NuMega BoundsChecker)
It will inform me if I write to deleted item on the heap or if I forget to
deallocate a object.
In fact overflows and heap management are two of the most over-hyped
criticisms in C++ development.
I have to go back to 80's to see the last time this was a serious issue.
Similarly the first fit heap management scheme is long dead. Heap
fragmentation is less of a problem.
--------------
John Thingstad
On 30 Ago, 13:38, "John Thingstad" <·······@online.no> wrote:
> På Sat, 30 Aug 2008 12:59:14 +0200, skrev Vend <······@virgilio.it>:
>
>
>
> > And anyway I presume that it wouldn't be so difficult to add array
> > bounds checking to C and C++.
> > All heap-allocated arrays already contain length information in some
> > form to allow deallocation, so one would just need to add length
> > information for stack-allocated and global arrays in a consistent
> > representation.
>
> > I presume that the main problem would be preserving compatibility with
> > existing binary interfaces.
>
> And do.. Microsoft's C/C++ has this as a optional feature.
> It can also check for stack overflow and stack overwrite (in software)
Good.
> Also on newer Intel processors you can have DEP protection. (Data
> Execution Prevention)
> (I recommend changing the OS setting to enable it for all programs even
> that can cause some older programs to abort.)
> For the last 25 years I have always run C/C++ with a bounds checker.
> (CodeGuard or NuMega BoundsChecker)
> It will inform me if I write to deleted item on the heap or if I forget to
> deallocate a object.
Ok.
> In fact overflows and heap management are two of the most over-hyped
> criticisms in C++ development.
> I have to go back to 80's to see the last time this was a serious issue.
I disagree. Many security-critical bugs of programs still in use are
caused by unchecked array overflows. Not everybody is using bounds
chekers.
> Similarly the first fit heap management scheme is long dead. Heap
> fragmentation is less of a problem.
>
> --------------
> John Thingstad
John Thingstad wrote:
> In fact overflows and heap management are two of the most over-hyped
> criticisms in C++ development. I have to go back to 80's to see the last
> time this was a serious issue. Similarly the first fit heap management
> scheme is long dead. Heap fragmentation is less of a problem.
You obviously haven't been reading the news:
Google's new web browser Chrome is written in C++. A buffer overrun security
vulnerability was found in it 6 days ago:
http://julianrdz.wordpress.com/2008/09/05/google-chrome-buffer-overflow-vulnerability/
Avoiding heap fragmentation in concurrent C++ was a major problem for
Google:
http://www.google.com/googlebooks/chrome/small_04.html
Heap fragmentation has been a headache for Mono since its inception:
http://www.mono-project.com/Compacting_GC
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 11 Set, 11:09, Jon Harrop <····@ffconsultancy.com> wrote:
> John Thingstad wrote:
> > In fact overflows and heap management are two of the most over-hyped
> > criticisms in C++ development. I have to go back to 80's to see the last
> > time this was a serious issue. Similarly the first fit heap management
> > scheme is long dead. Heap fragmentation is less of a problem.
>
> You obviously haven't been reading the news:
>
> Google's new web browser Chrome is written in C++. A buffer overrun security
> vulnerability was found in it 6 days ago:
>
> http://julianrdz.wordpress.com/2008/09/05/google-chrome-buffer-overfl...
>
> Avoiding heap fragmentation in concurrent C++ was a major problem for
> Google:
>
> http://www.google.com/googlebooks/chrome/small_04.html
I'm a bit skeptical about the claim that heap fragmentation can be a
significant problem in a web browser.
My cynical guess is that Google realized that their browser was so
prone to crashes and glitches that they decided to split it in several
processes as a form of "damage control".
> Heap fragmentation has been a headache for Mono since its inception:
>
> http://www.mono-project.com/Compacting_GC
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u
On Sep 11, 12:54 pm, Vend <······@virgilio.it> wrote:
> On 11 Set, 11:09, Jon Harrop <····@ffconsultancy.com> wrote:
> > Avoiding heap fragmentation in concurrent C++ was a major problem for
> > Google:
>
> >http://www.google.com/googlebooks/chrome/small_04.html
>
> I'm a bit skeptical about the claim that heap fragmentation can be a
> significant problem in a web browser.
>
> My cynical guess is that Google realized that their browser was so
> prone to crashes and glitches that they decided to split it in several
> processes as a form of "damage control".
Yes, what is really amazing in that brain-damaged comics is that it
markets "processes" as a major feature of every modern SO. That is so
70s...
Suddenly, with so many bugs due to concurrency and the availability of
multi-core CPUs and cheap memory, lightweight processes -- threads --
are not that funny anymore, despite being the big hype in the industry
for the last 20 years. Anyone remember the time when Microsoft SOs
did not have a good process model and, thus, threads were the way of
the future?
On 11 Set, 19:55, namekuseijin <············@gmail.com> wrote:
> On Sep 11, 12:54 pm, Vend <······@virgilio.it> wrote:
>
> > On 11 Set, 11:09, Jon Harrop <····@ffconsultancy.com> wrote:
> > > Avoiding heap fragmentation in concurrent C++ was a major problem for
> > > Google:
>
> > >http://www.google.com/googlebooks/chrome/small_04.html
>
> > I'm a bit skeptical about the claim that heap fragmentation can be a
> > significant problem in a web browser.
>
> > My cynical guess is that Google realized that their browser was so
> > prone to crashes and glitches that they decided to split it in several
> > processes as a form of "damage control".
>
> Yes, what is really amazing in that brain-damaged comics is that it
> markets "processes" as a major feature of every modern SO. That is so
> 70s...
>
> Suddenly, with so many bugs due to concurrency and the availability of
> multi-core CPUs and cheap memory, lightweight processes -- threads --
> are not that funny anymore, despite being the big hype in the industry
> for the last 20 years. Anyone remember the time when Microsoft SOs
> did not have a good process model and, thus, threads were the way of
> the future?
And even is (some) unix circles "fork" had become a form of profanity.
On Sep 11, 6:07 pm, Vend <······@virgilio.it> wrote:
> On 11 Set, 19:55, namekuseijin <············@gmail.com> wrote:
>
>
>
> > On Sep 11, 12:54 pm, Vend <······@virgilio.it> wrote:
>
> > > On 11 Set, 11:09, Jon Harrop <····@ffconsultancy.com> wrote:
> > > > Avoiding heap fragmentation in concurrent C++ was a major problem for
> > > > Google:
>
> > > >http://www.google.com/googlebooks/chrome/small_04.html
>
> > > I'm a bit skeptical about the claim that heap fragmentation can be a
> > > significant problem in a web browser.
>
> > > My cynical guess is that Google realized that their browser was so
> > > prone to crashes and glitches that they decided to split it in several
> > > processes as a form of "damage control".
>
> > Yes, what is really amazing in that brain-damaged comics is that it
> > markets "processes" as a major feature of every modern SO. That is so
> > 70s...
>
> > Suddenly, with so many bugs due to concurrency and the availability of
> > multi-core CPUs and cheap memory, lightweight processes -- threads --
> > are not that funny anymore, despite being the big hype in the industry
> > for the last 20 years. Anyone remember the time when Microsoft SOs
> > did not have a good process model and, thus, threads were the way of
> > the future?
>
> And even is (some) unix circles "fork" had become a form of profanity.
Indeed. Apache was a proud user of processes, then moved on for
multithreading both to better support Windows and to look cool. How
times change! Now they even get money from Microsoft...
Vend wrote:
> My cynical guess is that Google realized that their browser was so
> prone to crashes and glitches that they decided to split it in several
> processes as a form of "damage control".
Indeed. They obviously have serious problems with reliability. I cannot help
but wonder why they wrote their browser in an unsafe dying language...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
P� Thu, 11 Sep 2008 20:12:45 +0200, skrev Jon Harrop
<···@ffconsultancy.com>:
> Vend wrote:
>> My cynical guess is that Google realized that their browser was so
>> prone to crashes and glitches that they decided to split it in several
>> processes as a form of "damage control".
>
> Indeed. They obviously have serious problems with reliability. I cannot
> help
> but wonder why they wrote their browser in an unsafe dying language...
>
You mean like COBOL? :)
Languages with such a HUGE codebase won't die in my lifetime. Ocalm and F#
on the on the hand...
As far as I know all the popular browsers are written in C++.
--------------
John Thingstad
On 11 Set, 19:22, "John Thingstad" <·······@online.no> wrote:
> På Thu, 11 Sep 2008 20:12:45 +0200, skrev Jon Harrop
> <····@ffconsultancy.com>:
>
> > Vend wrote:
> >> My cynical guess is that Google realized that their browser was so
> >> prone to crashes and glitches that they decided to split it in several
> >> processes as a form of "damage control".
>
> > Indeed. They obviously have serious problems with reliability. I cannot
> > help
> > but wonder why they wrote their browser in an unsafe dying language...
>
> You mean like COBOL? :)
> Languages with such a HUGE codebase won't die in my lifetime. Ocalm and F#
> on the on the hand...
> As far as I know all the popular browsers are written in C++.
Yes but the popular browsers (Mozilla, IE and Opera) are all older
than 10 years, Mozilla even descends from Mosaic, the first popular
web browser.
Changing language during development is difficult, and nevertheless
Mozilla is currently moving complexity from C++ to Javascript and XUL,
eventually the C++ part may reduce to little more than a VM.
I suppose that if one were to start the development of a web browser
from the scratch, C++ wouldn't be a good choose as the main language.
C++ is good for doing low-level stuff, careful manual optimization and
easy interfacing to C libraries, so I suppose it will still be used
for developing videogames and other computationally intensive
applications, and system utilities.
But a web browser is a high-level application, quite complex, and,
being the user main gateway to the internet, is the access point of
most remote threats, hence security should be the overriding design
goal.
Therefore a memory-safe, type-safe language should be used as the main
language.
Perhaps even a language which support automatic verification such that
security properties can be checked by a theorem prover would be
advisable (But I don't know if these languages ever made past the
research stage).
I suppose that Google used C++ because their browser is not as
innovative as they advertise it, but actually a pastiche of various
components (Safari rendering engine, some bits of Mozilla, an
externally developed Javascript VM) decorated with the Google
branding.
On Sep 11, 9:50 pm, Vend <······@virgilio.it> wrote:
> I suppose that if one were to start the development of a web browser
> from the scratch, C++ wouldn't be a good choose as the main language.
Google wanted their browser to be fast and have low memory usage.
Why is C++ a bad choice of language then?What was the language they
should have used?
On Sep 11, 6:15 pm, Ali <·············@gmail.com> wrote:
> On Sep 11, 9:50 pm, Vend <······@virgilio.it> wrote:
>
> > I suppose that if one were to start the development of a web browser
> > from the scratch, C++ wouldn't be a good choose as the main language.
>
> Google wanted their browser to be fast and have low memory usage.
Fast and low memory are not usually read in the same phrase as
process. They blame heap fragmentation, yet are just handling the
problem to the SO kernel, itself written in C/C++...
> Why is C++ a bad choice of language then?What was the language they
> should have used?
Well, now that they have a fast javascript VM... can you say
metacircul, err, I mean, self-hosting javascript browser?! ;)
Ali <·············@gmail.com> writes:
> On Sep 11, 9:50��pm, Vend <······@virgilio.it> wrote:
>
> > I suppose that if one were to start the development of a web browser
> > from the scratch, C++ wouldn't be a good choose as the main language.
>
> Google wanted their browser to be fast and have low memory usage.
> Why is C++ a bad choice of language then?What was the language they
> should have used?
Well, they also wanted it to be robust.
C++ certainly has problems in the robustness arena.
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> Ali <·············@gmail.com> writes:
>
>> On Sep 11, 9:50pm, Vend <······@virgilio.it> wrote:
>>
>> > I suppose that if one were to start the development of a web browser
>> > from the scratch, C++ wouldn't be a good choose as the main language.
>>
>> Google wanted their browser to be fast and have low memory usage.
>> Why is C++ a bad choice of language then?What was the language they
>> should have used?
>
> Well, they also wanted it to be robust.
> C++ certainly has problems in the robustness arena.
Doesn't crashing in little pieces count as robust?
On 12 Set, 01:05, Paul Donnelly <·············@sbcglobal.net> wrote:
> ····@sevak.isi.edu (Thomas A. Russ) writes:
>
> > Ali <·············@gmail.com> writes:
>
> >> On Sep 11, 9:50pm, Vend <······@virgilio.it> wrote:
>
> >> > I suppose that if one were to start the development of a web browser
> >> > from the scratch, C++ wouldn't be a good choose as the main language.
>
> >> Google wanted their browser to be fast and have low memory usage.
> >> Why is C++ a bad choice of language then?What was the language they
> >> should have used?
>
> > Well, they also wanted it to be robust.
> > C++ certainly has problems in the robustness arena.
>
> Doesn't crashing in little pieces count as robust?
If the little pieces can execute malicious remote code before
crashing, no.
On 11 Set, 23:15, Ali <·············@gmail.com> wrote:
> On Sep 11, 9:50 pm, Vend <······@virgilio.it> wrote:
>
> > I suppose that if one were to start the development of a web browser
> > from the scratch, C++ wouldn't be a good choose as the main language.
>
> Google wanted their browser to be fast and have low memory usage.
That's why they use multiple processes, isn't it?
> Why is C++ a bad choice of language then?
Because a web browser should be first secure and reliable and second
fast and light on memory.
>What was the language they
> should have used?
Lisp, Java, Basic, pretty much anything would have been a better
choice.
In article
<····································@t54g2000hsg.googlegroups.com>,
Vend <······@virgilio.it> wrote:
> On 11 Set, 23:15, Ali <·············@gmail.com> wrote:
> > On Sep 11, 9:50�pm, Vend <······@virgilio.it> wrote:
> >
> > > I suppose that if one were to start the development of a web browser
> > > from the scratch, C++ wouldn't be a good choose as the main language.
> >
> > Google wanted their browser to be fast and have low memory usage.
>
> That's why they use multiple processes, isn't it?
>
> > Why is C++ a bad choice of language then?
>
> Because a web browser should be first secure and reliable and second
> fast and light on memory.
There is not a single web browser that is secure and reliable.
Most users want fast. Unfortunately, but that's what it is.
Most browser users don't know much about computers...
>
> >What was the language they
> > should have used?
>
> Lisp, Java, Basic, pretty much anything would have been a better
> choice.
Really? There is not a single comparable Common Lisp application
for Windows. Not one. Not even close.
Java on the Desktop is mostly dead.
Welcome to the real world. It's ugly.
On 12 Set, 14:30, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@t54g2000hsg.googlegroups.com>,
>
> Vend <······@virgilio.it> wrote:
> > On 11 Set, 23:15, Ali <·············@gmail.com> wrote:
> > > On Sep 11, 9:50 pm, Vend <······@virgilio.it> wrote:
>
> > > > I suppose that if one were to start the development of a web browser
> > > > from the scratch, C++ wouldn't be a good choose as the main language.
>
> > > Google wanted their browser to be fast and have low memory usage.
>
> > That's why they use multiple processes, isn't it?
>
> > > Why is C++ a bad choice of language then?
>
> > Because a web browser should be first secure and reliable and second
> > fast and light on memory.
>
> There is not a single web browser that is secure and reliable.
> Most users want fast. Unfortunately, but that's what it is.
> Most browser users don't know much about computers...
I don't think that it's that simple:
Users actually want security and reliability, the problem is that
speed and the UI are the most visible properties of a software, while
security and reliability are more difficult to evaluate, particularly
for lay-people who don't read security bulletins.
Developers, on the other hand, have an approximate idea of the level
of security and reliability of their products, hence you get an
information asymmetry situation.
Which is why, IMHO, Windows NT was a reasonably stable OS while the
consumer versions of Windows were crap, until Windows got a bad
reputation even among lay-people M$ needed to do something about it.
> > >What was the language they
> > > should have used?
>
> > Lisp, Java, Basic, pretty much anything would have been a better
> > choice.
>
> Really? There is not a single comparable Common Lisp application
> for Windows. Not one. Not even close.
>
> Java on the Desktop is mostly dead.
What's the problem with using Java on desktop?
> Welcome to the real world. It's ugly.
From: Joost Diepenmaat
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <87r67p5e66.fsf@zeekat.nl>
Vend <······@virgilio.it> writes:
> What's the problem with using Java on desktop?
It's slow to start, but mostly; it looks foreign. People don't like
that. If java used microsoft's MFC or something close enough on windows,
and similar for OS-X out of the box it would have been much more popular
already.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
On 12 Set, 21:58, Joost Diepenmaat <·····@zeekat.nl> wrote:
> Vend <······@virgilio.it> writes:
> > What's the problem with using Java on desktop?
>
> It's slow to start, but mostly; it looks foreign. People don't like
> that.
Many popular desktop apps look foreign. It actually seem that
developer do that on purpose.
> If java used microsoft's MFC or something close enough on windows,
> and similar for OS-X out of the box it would have been much more popular
> already.
There is IBM SWT which gives a native look-and-feel in Java. It's used
in the Azureus BitTorrent client, for instance.
> --
> Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/
From: Joost Diepenmaat
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <878wtw6dqj.fsf@zeekat.nl>
Vend <······@virgilio.it> writes:
> On 12 Set, 21:58, Joost Diepenmaat <·····@zeekat.nl> wrote:
>> Vend <······@virgilio.it> writes:
>> > What's the problem with using Java on desktop?
>>
>> It's slow to start, but mostly; it looks foreign. People don't like
>> that.
>
> Many popular desktop apps look foreign. It actually seem that
> developer do that on purpose.
>
>> If java used microsoft's MFC or something close enough on windows,
>> and similar for OS-X out of the box it would have been much more popular
>> already.
>
> There is IBM SWT which gives a native look-and-feel in Java. It's used
> in the Azureus BitTorrent client, for instance.
I know about SWT. IMHO it was too little, too late.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Joost Diepenmaat wrote:
> Vend <······@virgilio.it> writes:
>
>> What's the problem with using Java on desktop?
>
> It's slow to start, but mostly; it looks foreign. People don't like
> that. If java used microsoft's MFC or something close enough on windows,
> and similar for OS-X out of the box it would have been much more popular
> already.
It actually looks relatively decent on Mac OS X, and there are a couple
of relatively successful Java desktop applications for the Mac available.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Fri, 12 Sep 2008 14:30:54 +0200, Rainer Joswig wrote:
>> Because a web browser should be first secure and reliable and second
>> fast and light on memory.
>
> There is not a single web browser that is secure and reliable. Most
> users want fast. Unfortunately, but that's what it is.
Well, there's MMM (in ocaml!) and HotJava and whatever the web browser
that runs/ran inside emacs is called, and dillo, and probably several
others, that will argue that what people *really* want isn't security and
reliability, but bug-compatability with however the "important" websites
are abusing the medium. And the only thing that they care about is how
they render in the "important" browsers.
If just following the spec was all that was required, they'd all be doing
it...
Looks as though there might be a brief window of mostly-standards-
compliance before the whole shooting match dissolves into a Babel-esque
mish-mash of AJAX/GEARS/FLASH/Silverlight...
I'd say "be happy" that google seems to be pushing for standards
compliance at the protocol level, irrespective of what they're coding in.
Cheers,
--
Andrew
P� Sun, 14 Sep 2008 14:10:54 +0200, skrev Andrew Reilly
<···············@areilly.bpc-users.org>:
> On Fri, 12 Sep 2008 14:30:54 +0200, Rainer Joswig wrote:
>
>>> Because a web browser should be first secure and reliable and second
>>> fast and light on memory.
>>
>> There is not a single web browser that is secure and reliable. Most
>> users want fast. Unfortunately, but that's what it is.
>
> Well, there's MMM (in ocaml!) and HotJava and whatever the web browser
> that runs/ran inside emacs is called, and dillo, and probably several
> others, that will argue that what people *really* want isn't security and
> reliability, but bug-compatability with however the "important" websites
> are abusing the medium. And the only thing that they care about is how
> they render in the "important" browsers.
>
"Bug" compatibility is a bit imprecise. Identical error recovery from HTML
errors to MSIE is probably what you mean. As for idiosyncrasies in CSS
etc. MSIE 8 promises to be the first fully standards compliant MSIE
browser. This should make the life for all of us, also those who don't use
MSIE, a bit easier eventually. (I 'mostly' use Opera.) Security through
obscurity seems to work. Though generally not a good recomendation, most
browser hack's (really crack's) for MSIE or Firefox don't work under Opera.
--------------
John Thingstad
In article <····························@news-europe.giganews.com>,
Rainer Joswig <······@lisp.de> wrote:
...
>
>Java on the Desktop is mostly dead.
May-be. But go to a bookstore, and there's SHELF after SHELF after BOOKCASE
after BOOKCASE after AISLE --- of Java books.
What then is the main use of that language?
>Welcome to the real world. It's ugly.
Curious
David
·······@panix.com (David Combs) writes:
> In article <····························@news-europe.giganews.com>,
> Rainer Joswig <······@lisp.de> wrote:
> ...
>>
>>Java on the Desktop is mostly dead.
>
> May-be. But go to a bookstore, and there's SHELF after SHELF after BOOKCASE
> after BOOKCASE after AISLE --- of Java books.
>
> What then is the main use of that language?
Based on the evidence at hand, selling books?
David Combs wrote:
> In article <····························@news-europe.giganews.com>,
> Rainer Joswig <······@lisp.de> wrote:
> ...
>
>>Java on the Desktop is mostly dead.
>
>
> May-be. But go to a bookstore, and there's SHELF after SHELF after BOOKCASE
> after BOOKCASE after AISLE --- of Java books.
That sword cuts two ways. Why are so many books needed to program with
that language? I mean, it ain't just books on the core language, it's
books on layers and layers god knows what, I was lucky enough to miss it.
That's why it is dead. Agile won. Groovy? Too little too late. Java
thinks it is fighting off Python and Ruby but that steady weight it
feels pushing it to the sea is Lisp.
>
> What then is the main use of that language?
>
Like Oracle, mostly making projects and businesses fail.
kt
Kenny wrote:
> Java thinks it is fighting off Python and Ruby but that steady weight it
> feels pushing it to the sea is Lisp.
That is probably the least convincing argument I have ever encountered.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
David Combs wrote:
> In article <····························@news-europe.giganews.com>,
> Rainer Joswig <······@lisp.de> wrote:
> > Java on the Desktop is mostly dead.
>
> May-be. But go to a bookstore, and there's SHELF after SHELF after
> BOOKCASE after BOOKCASE after AISLE --- of Java books.
>
> What then is the main use of that language?
Enterprise-level web programming AFAICT. You order goods over the web and
the remote servers are running tons of Java interrogating databases because
it is perceived by the decision makers in industry to be a trusted
higher-reliability alternative to dynamic languages like Python and Groovy.
In the job market, Java appears to be faltering but is not seeing the
catastrophic decline of C++:
http://www.itjobswatch.co.uk/jobs/uk/java.do
Looking at the Java jobs on offer you see lots of SOA with server-side Java
but also everything else out to "Unix systems administrators" requiring
Java skills to maintain Oracle DBs and Apache-based web services.
Java is also strong in the embedded market, where it is used to program
enormous numbers of revolutionary games for mobile phone, like Snake.
Rumour has it there may even be a new Repton version in the pipeline.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Vend wrote:
>> Google wanted their browser to be fast and have low memory usage.
>
> That's why they use multiple processes, isn't it?
At least to me, it looks like a process is a very suitable construct for
encapsulating how a user interacts with the web in a single window.
Processes guarantee isolation and safety at the OS level, that's their
purpose. Why reinvent these (badly) at the application level?
Michael
--
Michael Schuerig
··············@schuerig.de
http://www.schuerig.de/michael/
Michael Schuerig wrote:
> Vend wrote:
>>> Google wanted their browser to be fast and have low memory usage.
>>
>> That's why they use multiple processes, isn't it?
>
> At least to me, it looks like a process is a very suitable construct for
> encapsulating how a user interacts with the web in a single window.
> Processes guarantee isolation and safety at the OS level, that's their
> purpose. Why reinvent these (badly) at the application level?
Because the application level can provide concurrent garbage collection that
allows data structures to be shared between threads transparently. Solving
that problem with processes is either too slow (copying) or too error prone
(manual memory management).
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> Michael Schuerig wrote:
>> Vend wrote:
>>>> Google wanted their browser to be fast and have low memory usage.
>>>
>>> That's why they use multiple processes, isn't it?
>>
>> At least to me, it looks like a process is a very suitable construct
>> for encapsulating how a user interacts with the web in a single
>> window. Processes guarantee isolation and safety at the OS level,
>> that's their purpose. Why reinvent these (badly) at the application
>> level?
>
> Because the application level can provide concurrent garbage
> collection that allows data structures to be shared between threads
> transparently. Solving that problem with processes is either too slow
> (copying) or too error prone (manual memory management).
That's what you want and I agree, these features would be nice to have.
However, someone else on this thread is asking for security over speed
and memory use. So, it looks like it might be pretty hard to give
everyone what they want.
Michael
--
Michael Schuerig
··············@schuerig.de
http://www.schuerig.de/michael/
Michael Schuerig wrote:
> That's what you want and I agree, these features would be nice to have.
> However, someone else on this thread is asking for security over speed
> and memory use. So, it looks like it might be pretty hard to give
> everyone what they want.
I think it is feasible to write a secure and reliable browser upon a
high-level VM like .NET. The weakest link is probably video codecs which
need to be unmanaged and unsafe for speed and could take down the whole
app.
I am personally happy with Mozilla just reloading my tabs every time it
crashes. My main concern is that it is only uses one core and leaves my
seven other CPU cores and my GPU idle.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Sep 12, 10:28 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Michael Schuerig wrote:
> > Vend wrote:
> >>> Google wanted their browser to be fast and have low memory usage.
>
> >> That's why they use multiple processes, isn't it?
>
> > At least to me, it looks like a process is a very suitable construct for
> > encapsulating how a user interacts with the web in a single window.
> > Processes guarantee isolation and safety at the OS level, that's their
> > purpose. Why reinvent these (badly) at the application level?
>
> Because the application level can provide concurrent garbage collection that
> allows data structures to be shared between threads transparently. Solving
> that problem with processes is either too slow (copying) or too error prone
> (manual memory management).
>
Using processes, calling exit(0) is a really great garbage collector.
Arguably faster than any other mechanism. I doubt there are many
shared data structures between tabs on a web browser, so I think your
copying argument is a lark in this case.
Scott wrote:
> Using processes, calling exit(0) is a really great garbage collector.
> Arguably faster than any other mechanism.
Not if unnecessary copying incurs swap.
> I doubt there are many shared data structures between tabs on a web
> browser, so I think your copying argument is a lark in this case.
IME browser tabs often contain many pages from the same site which will,
inevitably, share a huge amount of data like images and flash animations.
Given that such data forms the majority of data, I'd expect there to be a
lot of scope for sharing data between tabs.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2008-09-20, Jon Harrop <···@ffconsultancy.com> wrote:
> Scott wrote:
>> Using processes, calling exit(0) is a really great garbage collector.
>> Arguably faster than any other mechanism.
>
> Not if unnecessary copying incurs swap.
>
>> I doubt there are many shared data structures between tabs on a web
>> browser, so I think your copying argument is a lark in this case.
>
> IME browser tabs often contain many pages from the same site which will,
> inevitably, share a huge amount of data like images and flash animations.
> Given that such data forms the majority of data, I'd expect there to be a
> lot of scope for sharing data between tabs.
At least on unix-like OS, you have copy-on-write cloning of the same process
via fork. If a browser tab is created using fork, but without exec'ing a new
process image in the child, the child inherits the parent's data quite cheaply.
One thing you do want is that new cache entries introduced by one tab should be
available to the other tabs. There are some obvious ways to do that, like using
shared memory for volatile caches.
On Sep 11, 2:54 pm, Vend <······@virgilio.it> wrote:
>
> > Google wanted their browser to be fast and have low memory usage.
>
> That's why they use multiple processes, isn't it?
>
If that was sarcasm, then you don't know what you're talking about.
Processes don't have much memory overhead at all, and the amount of
shared data between tabs on a web browser is probably pretty minimal
(they're rendering different pages after all). The memory that the
code takes up between each of the processes is shared (or at least it
will be on OS's that support "shared objects").
Ali wrote:
> On Sep 11, 9:50 pm, Vend <······@virgilio.it> wrote:
>> I suppose that if one were to start the development of a web browser
>> from the scratch, C++ wouldn't be a good choose as the main language.
>
> Google wanted their browser to be fast and have low memory usage.
> Why is C++ a bad choice of language then?
Because C++ is slow with high memory usage in the context of these kinds of
programs. Specifically, lack of a GC in the context of software as
complicated as a browser leaves the programmer copy data structures rather
than sharing because collecting shared data is prohibitively complicated
without a GC and using scope-based deallocation (which is slow and wastes
memory) and reference counting (which is extremely slow and wastes even
more memory).
For example, C++'s scope-based destructors are the reason its exception
handling is 6x slower than OCaml's. C++ also lacks decent standard library
support for important things like trees.
> What was the language they should have used?
Any managed language running in a platform independent VM (OCaml, Haskell,
Lisp, Scheme, JavaScript). That pushes the performance-critical memory
allocation and collection onto a rock solid existing code base that has
already been heavily tested and heavily optimized.
Perhaps this would have been the ideal opportunity to test run Mono and
write the whole thing in C#?
Here are some interesting factoids about the Google Chrome code base,
courtesy of Sloccount:
. Google Chrome totals 2.2MLOC.
. Of that, 1.4MLOC are in the src/thirdparty directory, i.e. Google only
wrote 700kLOC of new code which is 94% C++.
. There are 250,000 lines of Perl in there.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Fri, 12 Sep 2008 10:59:00 +0100, Jon Harrop <···@ffconsultancy.com>
wrote:
>Ali wrote:
>> On Sep 11, 9:50�pm, Vend <······@virgilio.it> wrote:
>>
>> Google wanted their browser to be fast and have low memory usage.
>> Why is C++ a bad choice of language then?
>
>Because C++ is slow with high memory usage in the context of these kinds of
>programs. Specifically, lack of a GC in the context of software as
>complicated as a browser leaves the programmer copy data structures rather
>than sharing because collecting shared data is prohibitively complicated
>without a GC and using scope-based deallocation (which is slow and wastes
>memory) and reference counting (which is extremely slow and wastes even
>more memory).
It's more the performance of the dynamic memory system than anything
to do with "scope-based" deallocation.
>For example, C++'s scope-based destructors are the reason its exception
>handling is 6x slower than OCaml's.
Destructors, per se, are not the problem. Again the problem is the
need for manual deallocation and the memory system impacting
destructors that manage heap objects.
Exception performance in C++ is tied to that of the memory system
through destructors. Also, There are a number of ways to implement
exceptions themselves which make different trade offs between the
performance of the normal code path and that of the exception path.
Exception performance varies widely by implementation (and GCC on
x86(-64) is not a particularly stunning example of it).
George
On 12 Set, 21:52, George Neuner <········@comcast.net> wrote:
> On Fri, 12 Sep 2008 10:59:00 +0100, Jon Harrop <····@ffconsultancy.com>
> wrote:
>
> >Ali wrote:
> >> On Sep 11, 9:50 pm, Vend <······@virgilio.it> wrote:
>
> >> Google wanted their browser to be fast and have low memory usage.
> >> Why is C++ a bad choice of language then?
>
> >Because C++ is slow with high memory usage in the context of these kinds of
> >programs. Specifically, lack of a GC in the context of software as
> >complicated as a browser leaves the programmer copy data structures rather
> >than sharing because collecting shared data is prohibitively complicated
> >without a GC and using scope-based deallocation (which is slow and wastes
> >memory) and reference counting (which is extremely slow and wastes even
> >more memory).
>
> It's more the performance of the dynamic memory system than anything
> to do with "scope-based" deallocation.
>
> >For example, C++'s scope-based destructors are the reason its exception
> >handling is 6x slower than OCaml's.
>
> Destructors, per se, are not the problem. Again the problem is the
> need for manual deallocation and the memory system impacting
> destructors that manage heap objects.
That is, if there wasn't the need to explicitely deallocate heap
objects, most destructors would be unnecessary.
> Exception performance in C++ is tied to that of the memory system
> through destructors. Also, There are a number of ways to implement
> exceptions themselves which make different trade offs between the
> performance of the normal code path and that of the exception path.
> Exception performance varies widely by implementation (and GCC on
> x86(-64) is not a particularly stunning example of it).
>
> George
On Fri, 12 Sep 2008 16:33:12 -0700 (PDT), Vend <······@virgilio.it>
wrote:
>On 12 Set, 21:52, George Neuner <········@comcast.net> wrote:
>> On Fri, 12 Sep 2008 10:59:00 +0100, Jon Harrop <····@ffconsultancy.com>
>> wrote:
>>
>> >For example, C++'s scope-based destructors are the reason its exception
>> >handling is 6x slower than OCaml's.
>>
>> Destructors, per se, are not the problem. �Again the problem is the
>> need for manual deallocation and the memory system impacting
>> destructors that manage heap objects.
>
>That is, if there wasn't the need to explicitely deallocate heap
>objects, most destructors would be unnecessary.
Very true. But IMO destructors are a reasonable way to manage
resources other than memory. The developer has to design the object
properly, but it is rather hard for a user of the object to forget to
destruct it when it goes out of scope. Destructors don't help with
persistent objects ... but then neither do constructs like
unwind-protect.
George
On 14 Set, 01:32, George Neuner <········@comcast.net> wrote:
> On Fri, 12 Sep 2008 16:33:12 -0700 (PDT), Vend <······@virgilio.it>
> wrote:
>
> >On 12 Set, 21:52, George Neuner <········@comcast.net> wrote:
> >> On Fri, 12 Sep 2008 10:59:00 +0100, Jon Harrop <····@ffconsultancy.com>
> >> wrote:
>
> >> >For example, C++'s scope-based destructors are the reason its exception
> >> >handling is 6x slower than OCaml's.
>
> >> Destructors, per se, are not the problem. Again the problem is the
> >> need for manual deallocation and the memory system impacting
> >> destructors that manage heap objects.
>
> >That is, if there wasn't the need to explicitely deallocate heap
> >objects, most destructors would be unnecessary.
>
> Very true. But IMO destructors are a reasonable way to manage
> resources other than memory. The developer has to design the object
> properly, but it is rather hard for a user of the object to forget to
> destruct it when it goes out of scope.
Yes, provided that the language doesn't have constructs like call-with-
current-continuation.
And, in general, full closures.
> Destructors don't help with
> persistent objects ... but then neither do constructs like
> unwind-protect.
>
> George
Jon Harrop wrote:
> . Of that, 1.4MLOC are in the src/thirdparty directory, i.e. Google only
> wrote 700kLOC of new code which is 94% C++.
Actually most of the remaining code was also not written by Google. Grepping
for files containing Google (for the copyright notices) and running
sloccount on those indicates that the total amount of C++ code by Google is
only 74kLOC and much of that is nothing more than a rehash of their
existing code.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Sep 11, 10:15 pm, Ali <·············@gmail.com> wrote:
> Google wanted their browser to be fast and have low memory usage.
> Why is C++ a bad choice of language then?What was the language they
> should have used?
I guess conversation has moved on a bit since this, but a bit of
googling suggests that Google strictly uses only C++, Java, Python and
Javascript and for valid reasons.
Out of these, C++ or Java would be the only possible reasonable
options, and Java could have been rejected on the basis of the
standardised look argument or just not wanting to force the JVM onto
user machines, I suppose.
Writing the bulk of the application in Javascript sounds like a good
idea to me. Possibly not done with Chrome though if they were worried
about the Javascript implementation being too unstable.
So again I see no reason to slag off C++ here, I would have used it
myself.
Let's slag off Intercal instead, followed by Blub for desert.
Well I haven't used it myself, but here you go:
http://www.stud.uni-karlsruhe.de/~unk6/closure/
A web browser in CL.
Me, Software Consultant in the making?
John Thingstad wrote:
> På Thu, 11 Sep 2008 20:12:45 +0200, skrev Jon Harrop
> <···@ffconsultancy.com>:
>> Vend wrote:
>>> My cynical guess is that Google realized that their browser was so
>>> prone to crashes and glitches that they decided to split it in several
>>> processes as a form of "damage control".
>>
>> Indeed. They obviously have serious problems with reliability. I cannot
>> help
>> but wonder why they wrote their browser in an unsafe dying language...
>
> You mean like COBOL? :)
COBOL would be an equally bad choice, IMHO.
> Languages with such a HUGE codebase won't die in my lifetime. Ocalm and F#
> on the on the hand...
OCaml has already outlived most browsers. I'd be surprised in F# doesn't
also.
> As far as I know all the popular browsers are written in C++.
If they haven't already, I suspect Microsoft will port to managed code (C++
first and then better languages).
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
P� Fri, 12 Sep 2008 11:41:52 +0200, skrev Jon Harrop
<···@ffconsultancy.com>:
>
> If they haven't already, I suspect Microsoft will port to managed code
> (C++
> first and then better languages).
>
Visual C++ can produce managed code so why bother with C#? Agreebly if you
had to start from scratch C# is a no brainer, but not if you already have
500 000 or more lines of C++ code.It is easier for a C/C++ programmer to
move to Java or C# than to OCalm or F#. Most managers wouldn't want to
wait a year for the programmers to get up to speed.
--------------
John Thingstad
On Sep 12, 10:09 am, "John Thingstad" <·······@online.no> wrote:
> Visual C++ can produce managed code so why bother with C#? Agreebly if you
> had to start from scratch C# is a no brainer, but not if you already have
> 500 000 or more lines of C++ code.It is easier for a C/C++ programmer to
> move to Java or C# than to OCalm or F#. Most managers wouldn't want to
> wait a year for the programmers to get up to speed.
>
> --------------
> John Thingstad
Although technically all of those languages are good choices to write
a browser, I would imagine the choice for Google was only ever C++ or
Java for the bulk of their code.
It's perfectly okay to slag off C++, but if you are doing it in
context of Google Chrome, then you would also have to argue that
Google should have written Chrome in Java, since it would be highly
unlikely for them to use a different language.
I'd be interested to be proven wrong on that very last part though.
Ali <·············@gmail.com> writes:
> Although technically all of those languages are good choices to write
> a browser, I would imagine the choice for Google was only ever C++ or
> Java for the bulk of their code.
>
> It's perfectly okay to slag off C++, but if you are doing it in
> context of Google Chrome, then you would also have to argue that
> Google should have written Chrome in Java, since it would be highly
> unlikely for them to use a different language.
>
> I'd be interested to be proven wrong on that very last part though.
I see no reason why google people couldn't have written Chrome in Lisp.
(Apart from management deciding for no good reason against it).
--
__Pascal Bourguignon__
In article <··············@pbourguignon.anevia.com>,
···@informatimago.com (Pascal J. Bourguignon) wrote:
> Ali <·············@gmail.com> writes:
> > Although technically all of those languages are good choices to write
> > a browser, I would imagine the choice for Google was only ever C++ or
> > Java for the bulk of their code.
> >
> > It's perfectly okay to slag off C++, but if you are doing it in
> > context of Google Chrome, then you would also have to argue that
> > Google should have written Chrome in Java, since it would be highly
> > unlikely for them to use a different language.
> >
> > I'd be interested to be proven wrong on that very last part though.
>
> I see no reason why google people couldn't have written Chrome in Lisp.
> (Apart from management deciding for no good reason against it).
A few (pragmatic) reasons:
Because there is no free Common Lisp mature enough to
run such an desktop application (on Windows, Mac OS X, ...).
I haven't seen one Common Lisp application under Windows that
has a million+ users with all the different OS versions/installations and
all the different computers. I would not want to be the first one
to write such an application.
Because there are no competent developers to write such an application.
Because Plugins like Flash don't work.
I also can't imagine that anybody would want to use a commercial
Common Lisp for that.
In article <··············@gazonk.vestre.net>,
Espen Vestre <·····@vestre.net> wrote:
> Rainer Joswig <······@lisp.de> writes:
>
> > I also can't imagine that anybody would want to use a commercial
> > Common Lisp for that.
>
> Why not?
You would need to fork some money to the vendors first:
* Allegro CL by default has a pricing model that one might
check first when having a millions of customers.
A guess some agreement is possible.
* LispWorks comes with zero source code (besides the editor).
I can't imagine anybody doing such GUI intensive app
without source. So the source needs to be bought.
* All low-level stuff is very different in Lisp implementations.
Say you want to make flash, jvm, active x plugins working.
A robust solution is very special to each implementation.
That needs to be developed first.
* If you open source the browser, developers need to have the
right tools.
* There is no useful implementation of CL on ARM
(like native compiled with threads) I'm aware of.
No Mobile Chrome for Google's Android.
I well aware that one can develop and ship complex applications
on Windows (and some other platforms) with Lsip. But a demanding
application like a Web browser (that is abused by users to the max)
is outside Lisp's capabilities right now. Plugins,
threading, multitude of files, fast javascript implementation,
complex drawing environment, lots of networking connections is
a very tough combination. Especially when there is a code base
of almost zero to write such an application in Lisp. Chrome
evolved from Webkit, Webkit from KHTML. Developing that
from scratch in Lisp would be kind of tough. How many web browsers
in Lisp are in use? None.
I know, in theory it could be done. But practically it has
not been done yet and there is currently very little
available infrastructure in Lisp to do so. Nobody wants
to be the first one to find out.
I think Apple's experience with their Lisp experiments
(Dylan as a replacement language for C++ and Object Pascal)
was that it is hard to get it usable for groups that
want to do mass market products. Apple Dylan was (by all its coolness)
underwhelming - and that was especially targetted at application
development for C++ developers.
Rainer Joswig wrote:
> In article <··············@gazonk.vestre.net>,
> Espen Vestre <·····@vestre.net> wrote:
>
> > Rainer Joswig <······@lisp.de> writes:
> >
> > > I also can't imagine that anybody would want to use a commercial
> > > Common Lisp for that.
> >
> > Why not?
>
> You would need to fork some money to the vendors first:
>
> * Allegro CL by default has a pricing model that one might
> check first when having a millions of customers.
> A guess some agreement is possible.
>
> * LispWorks comes with zero source code (besides the editor).
> I can't imagine anybody doing such GUI intensive app
> without source. So the source needs to be bought.
Since they're giving Chrome for free there is no royalties, beside
google is a huge corporation, I don't think the money was the issue.
They could easily buy both Franz & LW or offer them good money for
some kind of agreement. But if they decided to build on existing C++
codebase I understand why lisp is not a good answer. Actually no
language is because c++ coooperates only with c++ and in one way with
c. Calling c from c++ is ok but vice versa is usally a bad idea or
almost impossible.
>
> * All low-level stuff is very different in Lisp implementations.
> Say you want to make flash, jvm, active x plugins working.
> A robust solution is very special to each implementation.
> That needs to be developed first.
>
> * If you open source the browser, developers need to have the
> right tools.
>
> * There is no useful implementation of CL on ARM
> (like native compiled with threads) I'm aware of.
> No Mobile Chrome for Google's Android.
>
>
> I well aware that one can develop and ship complex applications
> on Windows (and some other platforms) with Lsip. But a demanding
> application like a Web browser (that is abused by users to the max)
> is outside Lisp's capabilities right now. Plugins,
> threading, multitude of files, fast javascript implementation,
> complex drawing environment, lots of networking connections is
> a very tough combination. Especially when there is a code base
> of almost zero to write such an application in Lisp. Chrome
> evolved from Webkit, Webkit from KHTML. Developing that
> from scratch in Lisp would be kind of tough. How many web browsers
> in Lisp are in use? None.
>
> I know, in theory it could be done. But practically it has
> not been done yet and there is currently very little
> available infrastructure in Lisp to do so. Nobody wants
> to be the first one to find out.
>
>
> I think Apple's experience with their Lisp experiments
> (Dylan as a replacement language for C++ and Object Pascal)
> was that it is hard to get it usable for groups that
> want to do mass market products. Apple Dylan was (by all its coolness)
> underwhelming - and that was especially targetted at application
> development for C++ developers.
On Fri, 12 Sep 2008 08:24:44 -0700, Slobodan Blazeski wrote:
> Since they're giving Chrome for free there is no royalties, beside
> google is a huge corporation, I don't think the money was the issue.
> They could easily buy both Franz & LW or offer them good money for some
> kind of agreement. But if they decided to build on existing C++ codebase
All the speculation on what Google could "easily" do is missing the
point. Google has a lot of money, and could "easily" do a lot of stuff.
But it should still choose the most profitable option to reach its
objective, like any company.
This kind of misunderstanding is prevalent. The other version is the
"war chest" argument: Microsoft has this huge pile of money, so they
could easily... No, they are not going to do stuff which has negative
net present value, even if they could, because it would not make sense.
Being big does not mean that you don't care about profits any more.
Tamas
Tamas K Papp wrote:
> On Fri, 12 Sep 2008 08:24:44 -0700, Slobodan Blazeski wrote:
>> Since they're giving Chrome for free there is no royalties, beside
>> google is a huge corporation, I don't think the money was the issue.
>> They could easily buy both Franz & LW or offer them good money for some
>> kind of agreement. But if they decided to build on existing C++ codebase
>
> All the speculation on what Google could "easily" do is missing the
> point. Google has a lot of money, and could "easily" do a lot of stuff.
> But it should still choose the most profitable option to reach its
> objective, like any company.
>
> This kind of misunderstanding is prevalent. The other version is the
> "war chest" argument: Microsoft has this huge pile of money, so they
> could easily... No, they are not going to do stuff which has negative
> net present value, even if they could, because it would not make sense.
>
> Being big does not mean that you don't care about profits any more.
You are assuming that it is possible to accurately estimate the profit
resulting from any given piece of work when, in fact, Google have
absolutely no idea how much money their ventures will make.
They are a one trick pony that is (quite rightly, IMHO) throwing their money
and resources into anything and everything in the hope that something will
win big.
Microsoft are in a much stronger position because they have Windows and
Office both earning a lot of money independently. They could do with more
best selling products, so they fund a lot of interesting research, but they
can be much more confident in their decisions because what they are doing
is closer to home and more predictable.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Rainer Joswig <······@lisp.de> writes:
> You would need to fork some money to the vendors first:
If you're Google, that part wouldn't be the most difficult one,
I guess.
> * There is no useful implementation of CL on ARM
> (like native compiled with threads) I'm aware of.
> No Mobile Chrome for Google's Android.
Good point. But with the money...
> is outside Lisp's capabilities right now. Plugins,
> threading, multitude of files, fast javascript implementation,
> complex drawing environment, lots of networking connections is
> a very tough combination.
Of course I agree all that plugin and file format and standars support
is immensely complex, but I don't understand your comments on
threading and networking connections - my PrimeTrader application
usually runs more threads with more simultanous network connections
than Safari, and with a much smaller memory footprint - even though,
unlike Safari, it's already 64 bit.
> Especially when there is a code base of almost zero to write such an
> application in Lisp. Chrome evolved from Webkit, Webkit from
> KHTML. Developing that from scratch in Lisp would be kind of
> tough. How many web browsers in Lisp are in use? None.
Exactly. The value of all that existing code is immense.
> I think Apple's experience with their Lisp experiments
[...]
Like with the Newton, they were a few years too early with their lisp
experiments, I think. Despite the fascinating small memory footprint
of old MACL/MCL (I used it for some real work on a mac SE with 2,5MB
RAM), it was a bit too bloaty at that time.
--
(espen)
In article <··············@gazonk.vestre.net>,
Espen Vestre <·····@vestre.net> wrote:
> Rainer Joswig <······@lisp.de> writes:
>
> > You would need to fork some money to the vendors first:
>
> If you're Google, that part wouldn't be the most difficult one,
> I guess.
>
> > * There is no useful implementation of CL on ARM
> > (like native compiled with threads) I'm aware of.
> > No Mobile Chrome for Google's Android.
>
> Good point. But with the money...
And time...
>
> > is outside Lisp's capabilities right now. Plugins,
> > threading, multitude of files, fast javascript implementation,
> > complex drawing environment, lots of networking connections is
> > a very tough combination.
>
> Of course I agree all that plugin and file format and standars support
> is immensely complex, but I don't understand your comments on
> threading and networking connections - my PrimeTrader application
> usually runs more threads with more simultanous network connections
> than Safari, and with a much smaller memory footprint - even though,
> unlike Safari, it's already 64 bit.
But here you have an application that creates network connections
to all kinds of random network devices from all kinds of ill-configured
Windows computers (plus all kinds of other devices) over
all kinds of ill-configured network connections. Takes some
time to get the error handling right.
The threads may run all kind of bad-written plugins (unless
you don't want to support flash, acrobat, active-x, ...
and all that stuff - I can understand if one does not want to
support that ;-) - but if it helps with market share? ),
so you need to get that stuff safely killed, you need
some error handling - I can understand that Google just gives
up and kills a whole process if Flash goes into the wild.
> > Especially when there is a code base of almost zero to write such an
> > application in Lisp. Chrome evolved from Webkit, Webkit from
> > KHTML. Developing that from scratch in Lisp would be kind of
> > tough. How many web browsers in Lisp are in use? None.
>
> Exactly. The value of all that existing code is immense.
>
> > I think Apple's experience with their Lisp experiments
> [...]
>
> Like with the Newton, they were a few years too early with their lisp
> experiments, I think. Despite the fascinating small memory footprint
> of old MACL/MCL (I used it for some real work on a mac SE with 2,5MB
> RAM), it was a bit too bloaty at that time.
;-) True, I agree with that. But I think Apple was also
underwhelmed with what was delivered from the Dylan group
(given THEIR expectations to replace C++ with Dylan
for systems and app development - it does not matter that I
think it is cool stuff). Like it took 'ages' to get the
macro stuff and the new syntax - when the thing was a little
bit too large (for the shipped Newton) and useful compilers/devtools
(for ARM and then PowerPC) were more important. Space is no
longer an issue (in fact it would be less when using Dylan
then the other stuff we see now). With no shipping product
using the technology it is kind of hard to survive - especially
when an important project moves away. MCL was not really seen
as an environment to write apps in. All of Apple's MCL apps were
either inhouse apps or 'prototypes'.
Rainer Joswig <······@lisp.de> writes:
> But here you have an application that creates network connections
> to all kinds of random network devices from all kinds of ill-configured
> Windows computers (plus all kinds of other devices) over
> all kinds of ill-configured network connections. Takes some
> time to get the error handling right.
Well, I should know, this could just as well be a description of the
PrimeTrader application... (even though we have full server control,
the "random network devices" part still applies, we have to adapt to
myriads of ill-behaving transparent proxies, like e.g. Personal
Firewalls - IMHO some of the well known "anti virus" software is more
destructive than viruses themselves these days...).
> ;-) True, I agree with that. But I think Apple was also
> underwhelmed with what was delivered from the Dylan group
> (given THEIR expectations to replace C++ with Dylan
> for systems and app development - it does not matter that I
> think it is cool stuff).
Just like Apple v. 2.0 (a.k.a. NeXt ;-)) was underwhelmed by java - do
you remember how they talked about java at the time of OS X
introduction? The Objective C guys were seriously fearing that
Objective C would die off. Now it's /just/ Objective C that Apple
promotes - and how to integrate C++ with it.
--
(espen)
Espen Vestre wrote:
> Just like Apple v. 2.0 (a.k.a. NeXt ;-)) was underwhelmed by java - do
> you remember how they talked about java at the time of OS X
> introduction? The Objective C guys were seriously fearing that
> Objective C would die off. Now it's /just/ Objective C that Apple
> promotes - and how to integrate C++ with it.
Yes, Apple have really dug themselves an enormous trench by providing only
the world's worst support to the developers who build their platform. On
the other hand, they seem to have written it off anyway...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
In article <··············@gazonk.vestre.net>,
Espen Vestre <·····@vestre.net> wrote:
my other answer does not seem to be posted successfully. sigh.
> Rainer Joswig <······@lisp.de> writes:
>
> > But here you have an application that creates network connections
> > to all kinds of random network devices from all kinds of ill-configured
> > Windows computers (plus all kinds of other devices) over
> > all kinds of ill-configured network connections. Takes some
> > time to get the error handling right.
>
> Well, I should know, this could just as well be a description of the
> PrimeTrader application... (even though we have full server control,
> the "random network devices" part still applies, we have to adapt to
> myriads of ill-behaving transparent proxies, like e.g. Personal
> Firewalls - IMHO some of the well known "anti virus" software is more
> destructive than viruses themselves these days...).
Yes, your application is probably a good a example what
you can do with Lisp. Though I suspect that your users
are motivated enough to get the app running. Not sure
if an average browser user would be motivated
to get a Lisp-based browser running if he/she faces
networking problems. Making a good first impression
in a already crowded area (there are already competitors)
would be very important.
>
> > ;-) True, I agree with that. But I think Apple was also
> > underwhelmed with what was delivered from the Dylan group
> > (given THEIR expectations to replace C++ with Dylan
> > for systems and app development - it does not matter that I
> > think it is cool stuff).
>
> Just like Apple v. 2.0 (a.k.a. NeXt ;-)) was underwhelmed by java - do
> you remember how they talked about java at the time of OS X
> introduction? The Objective C guys were seriously fearing that
> Objective C would die off. Now it's /just/ Objective C that Apple
> promotes - and how to integrate C++ with it.
Well, it was the height of the 'Java on the Desktop' hype. Sun
was pushing hard. The business is a fashion industry
(read that remark lately) and its partly true. Java
on the Desktop failed to deliver, but it was tried
very hard and many many millions have been invested into
that. But in the end it was clear that look&feel and
performance of these Java apps were not the best. The
last successful Java desktop app that I have started was
Eclipse - and even that is not what I would want to use.
Not that there are no successful desktop apps written in Java,
it is just that I (!) don't use one and I don't know any that
I should use.
The Objective C stuff works quite well together with the
Interface Builder and Apple has added some improved tools
lately. All iPhone apps are written in Objective C.
But Objective C is also dead end, IMHO. Apple tries to get some more
life into it by adding (conservative) Garbage Collection.
I guess getting rid of reference counting is a good idea, but I
doubt that the combination of GC and Objective C is a good idea.
Lisp on the other hand is almost totally out of fashion for developing
apps in larger corporations. In the mid 80s everybody was using
Lisp to some extent: SUN, DEC, Apple, TI, ... All of
them had a Common Lisp environment and even some GUI toolkit.
SUN had SLE (Symbolic Language Environment, IIRC), TI had
lots of stuff - for GUIs they were developing CLX/CLUE/CLIO.
Others were doing Common Windows, Garnet, CLIM, etc. Expertelligence
sold a Lisp-based GUI builder - which Steve Jobs saw and he
had the developer recode in Objective C as NeXT's famous
Interface Builder.
So, I still think that at some point it will be rediscovered
that one can write GUI toolkits in Lisp and that it isn't
that difficult. There are some already (still in use (like CAPI) or
in experimentation stage (like McCLIM)). But I would
guess that after a lot of experimenting with server based
apps, at some point GUI-based desktop apps will also
be looked at. I don't believe that it will be Google that
develops a web browser in Lisp, but why shouldn't a small
team develop a presentation program, a drawing app,
a calendar app, a word processor, a spreadsheet, or something
like that in Lisp? A mail reader which looks cool and
can be configured and extended in Lisp? Why not? Just
provide a slightly extended Lisp base (similar to what
Emacs is to text editors) with a GUI focus.
--
http://lispm.dyndns.org/
Rainer Joswig wrote:
> So, I still think that at some point it will be rediscovered
> that one can write GUI toolkits in Lisp and that it isn't
> that difficult. There are some already (still in use (like CAPI) or
> in experimentation stage (like McCLIM)). But I would
> guess that after a lot of experimenting with server based
> apps, at some point GUI-based desktop apps will also
> be looked at. I don't believe that it will be Google that
> develops a web browser in Lisp, but why shouldn't a small
> team develop a presentation program, a drawing app,
> a calendar app, a word processor, a spreadsheet, or something
> like that in Lisp? A mail reader which looks cool and
> can be configured and extended in Lisp? Why not?
There are several reasons why not. Most notably the lack of concurrent GCs
in all Lisps rendering them incapable of leveraging shared memory
parallelism when that is now ubiquitous on the desktop.
But the real question is not why won't people write applications in Lisp but
why should they when they have languages like Scala and F# that are better
in every respect?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Sep 12, 10:13 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Rainer Joswig wrote:
> > So, I still think that at some point it will be rediscovered
> > that one can write GUI toolkits in Lisp and that it isn't
> > that difficult. There are some already (still in use (like CAPI) or
> > in experimentation stage (like McCLIM)). But I would
> > guess that after a lot of experimenting with server based
> > apps, at some point GUI-based desktop apps will also
> > be looked at. I don't believe that it will be Google that
> > develops a web browser in Lisp, but why shouldn't a small
> > team develop a presentation program, a drawing app,
> > a calendar app, a word processor, a spreadsheet, or something
> > like that in Lisp? A mail reader which looks cool and
> > can be configured and extended in Lisp? Why not?
>
> There are several reasons why not. Most notably the lack of concurrent GCs
> in all Lisps rendering them incapable of leveraging shared memory
> parallelism when that is now ubiquitous on the desktop.
>
> But the real question is not why won't people write applications in Lisp but
> why should they when they have languages like Scala and F# that are better
> in every respect?
Why not discuss that in your Blog with your sock puppets?
Rainer Joswig wrote:
> So, I still think that at some point it will be rediscovered
> that one can write GUI toolkits in Lisp and that it isn't
> that difficult. There are some already (still in use (like CAPI) or
> in experimentation stage (like McCLIM)). But I would
> guess that after a lot of experimenting with server based
> apps, at some point GUI-based desktop apps will also
> be looked at. I don't believe that it will be Google that
> develops a web browser in Lisp, but why shouldn't a small
> team develop a presentation program, a drawing app,
> a calendar app, a word processor, a spreadsheet, or something
> like that in Lisp? A mail reader which looks cool and
> can be configured and extended in Lisp? Why not? Just
> provide a slightly extended Lisp base (similar to what
> Emacs is to text editors) with a GUI focus.
InspireData seems a decent and recent example. See
http://www.inspiration.com/productinfo/inspiredata/index.cfm
(Note how the product website carefully doesn't mention what language
the used to implement it. [1])
Pascal
[1] I think that's a good thing.
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Sat, 13 Sep 2008 00:30:07 +0200, Pascal Costanza wrote:
> InspireData seems a decent and recent example. See
> http://www.inspiration.com/productinfo/inspiredata/index.cfm
Gosh, Edward Tufte would have a heart attack looking at those graphs :-)
> (Note how the product website carefully doesn't mention what language
> the used to implement it. [1])
>
> Pascal
>
> [1] I think that's a good thing.
I agree. Why would a user care about the language per se? I don't care
what tools the carpenter used, as long as I like the table he made.
Tamas
On Sep 13, 12:58 am, Tamas K Papp <······@gmail.com> wrote:
> On Sat, 13 Sep 2008 00:30:07 +0200, Pascal Costanza wrote:
> > InspireData seems a decent and recent example. See
> >http://www.inspiration.com/productinfo/inspiredata/index.cfm
>
> Gosh, Edward Tufte would have a heart attack looking at those graphs :-)
>
> > (Note how the product website carefully doesn't mention what language
> > the used to implement it. [1])
>
> > Pascal
>
> > [1] I think that's a good thing.
>
> I agree. Why would a user care about the language per se? I don't care
> what tools the carpenter used, as long as I like the table he made.
>
> Tamas
Right. But it should be known to the Lisp community and publically
discussable.
It is fortunately known that InspireData is written in LispWorks by
Clozure.
In the 80s there were a lot of doubts that Lisp paid back the
investments.
The customer demanded from the Lisp companies to not publish a single
word about their Lisp usage. If a project would fail they feared
the publicity and when it was successful they did not want to tell
the competition about how it was done. Government usage was never
wanted to be mentioned
and even the companies using it demanded that there was no publicity.
So there were few (success) stories and very little user reports.
Mostly a few apps were mentioned over and over. When the AI winter
set in and the Lisp market was on a decline, suddenly some more
success stories were published - but then it was too late - few were
interested in those anymore.
A good place to report the usage of Lisp is at some user group
meeting,
workshop or even the International Lisp Conference. At recent meetings
there were quite a few interesting talks about applications.
······@corporate-world.lisp.de wrote:
> On Sep 13, 12:58 am, Tamas K Papp <······@gmail.com> wrote:
>> On Sat, 13 Sep 2008 00:30:07 +0200, Pascal Costanza wrote:
>>> InspireData seems a decent and recent example. See
>>> http://www.inspiration.com/productinfo/inspiredata/index.cfm
>> Gosh, Edward Tufte would have a heart attack looking at those graphs :-)
>>
>>> (Note how the product website carefully doesn't mention what language
>>> the used to implement it. [1])
>>> Pascal
>>> [1] I think that's a good thing.
>> I agree. Why would a user care about the language per se? I don't care
>> what tools the carpenter used, as long as I like the table he made.
>>
>> Tamas
>
> Right. But it should be known to the Lisp community and publically
> discussable.
Full ack!
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Rainer Joswig <······@lisp.de> writes:
> Making a good first impression in a already crowded area (there are
> already competitors) would be very important.
Sure. And because it's so crowded... well, I don't really think it makes
sense.
> Not that there are no successful desktop apps written in Java,
> it is just that I (!) don't use one and I don't know any that
> I should use.
Neither do I, and the ones I've been forced to struggle with every now
and then (for instance one which my kids are using) are such stellar
examples of cross-platformness done utterly wrong that my fingers itch
to reimplement it in CAPI ;-)
> The Objective C stuff works quite well together with the
> Interface Builder and Apple has added some improved tools
> lately. All iPhone apps are written in Objective C.
Yes, I've had a quick glance at the iPhone toolkit. Apple's Objective
C stuff is pretty nice, but it's still somewhat appalling to a lisp
programmer...
> But Objective C is also dead end, IMHO.
It would be strange if it wasn't, but I guess Obj-C and C++ will be
with us for a long time still.
> Lisp on the other hand is almost totally out of fashion for developing
> apps in larger corporations.
It did go totally out of fashion, but that was already some time ago,
long enough for it to be able to turn into the Next Big Thing again
by now.
--
(espen)
John Thingstad wrote:
> På Fri, 12 Sep 2008 11:41:52 +0200, skrev Jon Harrop
> <···@ffconsultancy.com>:
>> If they haven't already, I suspect Microsoft will port to managed code
>> (C++ first and then better languages).
>
> Visual C++ can produce managed code so why bother with C#?
C# is a much better language with a much better standard library = more
features for a lot less money.
> Agreebly if you had to start from scratch C# is a no brainer, but not if
> you already have 500 000 or more lines of C++ code.
What relevant C++ code is not already available from C# in a better form?
> It is easier for a C/C++ programmer to move to Java or C# than to OCalm or
> F#. Most managers wouldn't want to wait a year for the programmers to get
> up to speed.
C++ is dying and has already been overtaken by C#:
http://www.google.com/trends?q=c%23%2Cc%2B%2B
There is no need to train people in C# because it is already more widely
known and used (in addition to being far more suitable).
Unmanaged C++ (which I assume they are using or these security flaws could
not have existed) is also notoriously bad for interoperability with other
native languages.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> John Thingstad wrote:
> > På Fri, 12 Sep 2008 11:41:52 +0200, skrev Jon Harrop
> > <···@ffconsultancy.com>:
> >> If they haven't already, I suspect Microsoft will port to managed code
> >> (C++ first and then better languages).
> >
> > Visual C++ can produce managed code so why bother with C#?
>
> C# is a much better language with a much better standard library = more
> features for a lot less money.
BS C# is just a bunch of object oriented crup and poorly integrated
features stolen from everywhere. They even have lambda and first
order functions -delegates. The problem is that nobody is using them,
unless you really must to because of the poor integration.
The only place I wrote delegate is :
SPSecurity.RunWithElevatedPrivileges(delegate()
{ //something });
and I have 0 lambda's in my code.
>
> > Agreebly if you had to start from scratch C# is a no brainer, but not if
> > you already have 500 000 or more lines of C++ code.
>
> What relevant C++ code is not already available from C# in a better form?
Unless you're doing some webby staff, c++ libs wins with flying
colors, just look at boost or game libs to get some idea. C++ libs are
usually open source, C# libs are what MS gives you or what you can buy
for money (and that's closed source ). There is very few c# libs
outisde MS especially open source. I don't say none, but still very
little, and the gap isn't decreasing because people don't write open
source code for c# unless they must support Mono.
>
> > It is easier for a C/C++ programmer to move to Java or C# than to OCalm or
> > F#. Most managers wouldn't want to wait a year for the programmers to get
> > up to speed.
>
> C++ is dying and has already been overtaken by C#:
>
> http://www.google.com/trends?q=c%23%2Cc%2B%2B
Your google trends arguments are childish at best.
>
> There is no need to train people in C# because it is already more widely
> known and used (in addition to being far more suitable).
People who know only C# are usually very poor quality mill produced
coders. I wouldn't want to make anything with such folks beside a
neighbourhood video store web site . MS tried to make Vista with
managed c# code, and guess what it didn't work. With all their fancy
bragging they need c++.
BTW since when you become a fan of gc collected languages? Oh wait
you're selling f# book now.
>
> Unmanaged C++ (which I assume they are using or these security flaws could
> not have existed) is also notoriously bad for interoperability with other
> native languages.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?u
Slobodan Blazeski wrote:
> Jon Harrop wrote:
>> John Thingstad wrote:
>> > På Fri, 12 Sep 2008 11:41:52 +0200, skrev Jon Harrop
>> > <···@ffconsultancy.com>:
>> >> If they haven't already, I suspect Microsoft will port to managed code
>> >> (C++ first and then better languages).
>> >
>> > Visual C++ can produce managed code so why bother with C#?
>>
>> C# is a much better language with a much better standard library = more
>> features for a lot less money.
>
> BS C# is just a bunch of object oriented crup and poorly integrated
> features stolen from everywhere.
It also took parametric polymorphism from ML and first-class lexical
closures into the mainstream.
> They even have lambda and first order functions -delegates. The problem is
> that nobody is using them,
Of the companies I have personally dealt with, all are using them. For
example, Microsoft's Task Parallel library uses them (and far exceeds the
capabilities of anything available in C++).
>> > Agreebly if you had to start from scratch C# is a no brainer, but not
>> > if you already have 500 000 or more lines of C++ code.
>>
>> What relevant C++ code is not already available from C# in a better form?
>
> Unless you're doing some webby staff,
We're talking about writing a web browser here.
> c++ libs wins with flying colors, just look at boost or game libs to get
> some idea.
They don't even approach XNA or WPF. Moreover, C++ libs are almost all
unstable and uninteroperable (just look at the state of Qt bindings in
OCaml or Haskell).
> C++ libs are usually open source,
Only on Linux and Chrome is still Windows only.
> C# libs are what MS gives you or what you can buy
> for money (and that's closed source ). There is very few c# libs
> outisde MS especially open source.
There are a huge number of C# libs available. I know because we compete with
them.
> I don't say none, but still very little, and the gap isn't decreasing
> because people don't write open source code for c# unless they must
> support Mono.
There is also a lot of open source code available for .NET. Microsoft have
released a lot of their own code.
>> > It is easier for a C/C++ programmer to move to Java or C# than to OCalm
>> > or F#. Most managers wouldn't want to wait a year for the programmers
>> > to get up to speed.
>>
>> C++ is dying and has already been overtaken by C#:
>>
>> http://www.google.com/trends?q=c%23%2Cc%2B%2B
>
> Your google trends arguments are childish at best.
That is an objective and quantitative metric. There are others, like jobs,
but they all show the same strongly downward trend for C++ and growth for
C#. For example, demand for C++ programmers has halved over the past four
years here and C# has doubled:
http://www.itjobswatch.co.uk/jobs/uk/c++.do
http://www.itjobswatch.co.uk/jobs/uk/csharp.do
>> There is no need to train people in C# because it is already more widely
>> known and used (in addition to being far more suitable).
>
> People who know only C# are usually very poor quality mill produced
> coders.
C++ is no better in that respect.
> I wouldn't want to make anything with such folks beside a
> neighbourhood video store web site . MS tried to make Vista with
> managed c# code, and guess what it didn't work.
What do you think WPF is?
> BTW since when you become a fan of gc collected languages? Oh wait
> you're selling f# book now.
OCaml is also garbage collected.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
P� Fri, 12 Sep 2008 16:45:50 +0200, skrev Jon Harrop
<···@ffconsultancy.com>:
> John Thingstad wrote:
>> P� Fri, 12 Sep 2008 11:41:52 +0200, skrev Jon Harrop
>> <···@ffconsultancy.com>:
>>> If they haven't already, I suspect Microsoft will port to managed code
>>> (C++ first and then better languages).
>>
>> Visual C++ can produce managed code so why bother with C#?
>
> C# is a much better language with a much better standard library = more
> features for a lot less money.
>
>> Agreebly if you had to start from scratch C# is a no brainer, but not if
>> you already have 500 000 or more lines of C++ code.
>
> What relevant C++ code is not already available from C# in a better form?
How about the 500 000 or so lines of you YOUR company wrote.
Why do you think banks still use COBOL? They cant afford to rewrite their
existing code base.
A typical banking system took 100 programmers 3 years to write. It is hard
to justify the expense of a rewrite.
>
>> It is easier for a C/C++ programmer to move to Java or C# than to OCalm
>> or
>> F#. Most managers wouldn't want to wait a year for the programmers to
>> get
>> up to speed.
>
> C++ is dying and has already been overtaken by C#:
>
> http://www.google.com/trends?q=c%23%2Cc%2B%2B
>
What world are you on?
There about 4 000 000 programmers that use C++ professionally.
Have you ever even worked in the computer industry?
> There is no need to train people in C# because it is already more widely
> known and used (in addition to being far more suitable).
Not on planet earth!
>
> Unmanaged C++ (which I assume they are using or these security flaws
> could
> not have existed) is also notoriously bad for interoperability with other
> native languages.
>
Security flaws can happen with any programming language. And they do.
Managing memory and won't make them magically disappear.
But if you are concerned I suggest to turn Data Execution Prevention (DEP)
on for all programs.
That way the program will be terminated if a buffer overflow attempt is
made.
Last I checked about 80% of all break-ins used a buffer overflow attack.
--------------
John Thingstad
John Thingstad wrote:
> På Fri, 12 Sep 2008 16:45:50 +0200, skrev Jon Harrop
> <···@ffconsultancy.com>:
>> What relevant C++ code is not already available from C# in a better form?
>
> How about the 500 000 or so lines of you YOUR company wrote.
We ported it, like almost everyone else.
> Why do you think banks still use COBOL? They cant afford to rewrite their
> existing code base.
> A typical banking system took 100 programmers 3 years to write. It is hard
> to justify the expense of a rewrite.
Irrelevant: this is about Google's *new* web browser.
>>> It is easier for a C/C++ programmer to move to Java or C# than to OCalm
>>> or
>>> F#. Most managers wouldn't want to wait a year for the programmers to
>>> get
>>> up to speed.
>>
>> C++ is dying and has already been overtaken by C#:
>>
>> http://www.google.com/trends?q=c%23%2Cc%2B%2B
>
> What world are you on?
> There about 4 000 000 programmers that use C++ professionally.
Demand for C++ programmers has halved since 2004 and was overtaken by C# two
years ago:
http://www.itjobswatch.co.uk/jobs/uk/c++.do
http://www.itjobswatch.co.uk/jobs/uk/csharp.do
> Have you ever even worked in the computer industry?
Yes. An abundance of ancient technology does not justify its use in a new
project.
>> There is no need to train people in C# because it is already more widely
>> known and used (in addition to being far more suitable).
>
> Not on planet earth!
How do you explain the above data?
>> Unmanaged C++ (which I assume they are using or these security flaws
>> could not have existed) is also notoriously bad for interoperability with
>> other native languages.
>
> Security flaws can happen with any programming language. And they do.
> Managing memory and won't make them magically disappear.
> But if you are concerned I suggest to turn Data Execution Prevention (DEP)
> on for all programs.
> That way the program will be terminated if a buffer overflow attempt is
> made.
> Last I checked about 80% of all break-ins used a buffer overflow attack.
DEP does not make C++ fast and reliable. Those problems do not even exist in
modern languages.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
P� Sat, 13 Sep 2008 11:44:28 +0200, skrev Jon Harrop
<···@ffconsultancy.com>:
>> Have you ever even worked in the computer industry?
>
> Yes. An abundance of ancient technology does not justify its use in a new
> project.
>
Unless the ancient tecknology includes libraries that do a lot of the work
and you otherwise would have to write them yourself..
As was the case for Chrome..
>>> There is no need to train people in C# because it is already more
>>> widely
>>> known and used (in addition to being far more suitable).
>>
>> Not on planet earth!
>
> How do you explain the above data?
>
Simple, it just list's new job opportunities. Since old project's already
have programmers they have less need of new programmers than projects that
are just starting. You could conclude that C++ use has stopped growing,
but that is hardly the same as dying.
>>> Unmanaged C++ (which I assume they are using or these security flaws
>>> could not have existed) is also notoriously bad for interoperability
>>> with
>>> other native languages.
>>
>> Security flaws can happen with any programming language. And they do.
>> Managing memory and won't make them magically disappear.
>> But if you are concerned I suggest to turn Data Execution Prevention
>> (DEP)
>> on for all programs.
>> That way the program will be terminated if a buffer overflow attempt is
>> made.
>> Last I checked about 80% of all break-ins used a buffer overflow attack.
>
> DEP does not make C++ fast and reliable. Those problems do not even
> exist in
> modern languages.
>
On the contrary ADA for instance sufferers this problem too if all
checking is turned off.
So for that matter does Lisp. The option is to never allow for the
programmer to turn checking off which could make tight loops run too slow.
So do you give programmers that freedom, or restrict it. I should add that
Microsoft's C++ compiler can generate code that checks for stack overwrite
and if array's are out of bounds. Although most people use this in their
debug version and inhibit it in their distribution version there is
nothing preventing you from performing these checks by in the release
version as well.
--------------
John Thingstad
John Thingstad wrote:
> På Sat, 13 Sep 2008 11:44:28 +0200, skrev Jon Harrop
> <···@ffconsultancy.com>:
>>> Have you ever even worked in the computer industry?
>>
>> Yes. An abundance of ancient technology does not justify its use in a new
>> project.
>
> Unless the ancient tecknology includes libraries that do a lot of the work
> and you otherwise would have to write them yourself..
> As was the case for Chrome..
What exactly do you think a Java or C# programmer would have to rewrite
themselves?
>>>> There is no need to train people in C# because it is already more
>>>> widely
>>>> known and used (in addition to being far more suitable).
>>>
>>> Not on planet earth!
>>
>> How do you explain the above data?
>
> Simple, it just list's new job opportunities. Since old project's already
> have programmers they have less need of new programmers than projects that
> are just starting. You could conclude that C++ use has stopped growing,
> but that is hardly the same as dying.
That does not explain the dramatic reduction in searches for C++ compared to
Java and C#. The only logical explanation for these figures is that use of
C++ has declined dramatically over the past few years and both Java and C#
have overtaken it.
>> DEP does not make C++ fast and reliable. Those problems do not even
>> exist in modern languages.
>
> On the contrary ADA for instance sufferers this problem too if all
> checking is turned off. So for that matter does Lisp.
Ada and Lisp are not modern languages.
> The option is to never allow for the programmer to turn checking off which
> could make tight loops run too slow.
Java and C# are both easily fast enough in the context of writing a web
browser.
> So do you give programmers that freedom, or restrict it. I should add that
> Microsoft's C++ compiler can generate code that checks for stack overwrite
> and if array's are out of bounds. Although most people use this in their
> debug version and inhibit it in their distribution version there is
> nothing preventing you from performing these checks by in the release
> version as well.
Google only have this security problem because they made the mistake of
choosing C++.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
P� Sat, 13 Sep 2008 14:20:36 +0200, skrev Jon Harrop
<···@ffconsultancy.com>:
> John Thingstad wrote:
I don't think whether it is modern or not factors into this.
What I envision is a system that checks the source per default and where
programmers have to earn the privilege of turning off boundary checks by
passing exam. Even if they pass it should be double checked. If they
introduce a declaration which exceeds their 'privilege' they get a slap on
the wrist. Naughty, naughty -- pass the exam first. I believe these simple
management techniques would help a lot.
--------------
John Thingstad
John Thingstad wrote:
> > > > DEP does not make C++ fast and reliable. Those problems do not even
> > > > exist in modern languages.
> > >
> > > On the contrary ADA for instance sufferers this problem too if all
> > > checking is turned off. So for that matter does Lisp.
> >
> > Ada and Lisp are not modern languages.
>
> I don't think whether it is modern or not factors into this.
Even if it were possible, there is no reason to turn off checking in modern
language implementations.
> What I envision is a system that checks the source per default and where
> programmers have to earn the privilege of turning off boundary checks by
> passing exam. Even if they pass it should be double checked. If they
> introduce a declaration which exceeds their 'privilege' they get a slap on
> the wrist. Naughty, naughty -- pass the exam first. I believe these simple
> management techniques would help a lot.
Alternatively, get rid of C++ and its incompetent programmers and use a more
mainstream modern language instead where the compiler's optimizations
obviate the need to turn bounds checking off.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
P� Sat, 13 Sep 2008 14:20:36 +0200, skrev Jon Harrop
<···@ffconsultancy.com>:
> That does not explain the dramatic reduction in searches for C++
> compared to
> Java and C#. The only logical explanation for these figures is that use
> of
> C++ has declined dramatically over the past few years and both Java and
> C#
> have overtaken it.
>
You are wrong. The people fluent in C++ have less need for searching for
C++ articles and are more likely to search for articles on a specific
library.
The only thing it prooves is that C++ has been around for a longer time.
--------------
John Thingstad
John Thingstad wrote:
> På Sat, 13 Sep 2008 14:20:36 +0200, skrev Jon Harrop
> <···@ffconsultancy.com>:
>> That does not explain the dramatic reduction in searches for C++
>> compared to Java and C#. The only logical explanation for these figures
>> is that use of C++ has declined dramatically over the past few years and
>> both Java and C# have overtaken it.
>
> You are wrong. The people fluent in C++ have less need for searching for
> C++ articles and are more likely to search for articles on a specific
> library.
> The only thing it prooves is that C++ has been around for a longer time.
Then why do other languages of the same age not show this unique decline?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Sat, 13 Sep 2008 13:20:36 +0100, Jon Harrop wrote:
> What exactly do you think a Java or C# programmer would have to rewrite
> themselves?
Besides WebKit?
If you allow inclusion of WebKit (or, probably, Gecko) I agree with the
Pascal (I think): the rest of it could be done in anything north of
interpreted Basic. C++ just draws on a ready pool of coders, and
probably makes it a bit easier to get to WebKit's API, since that's C++
already.
Not that I think that there's anything intrinsic in WebKit or Gecko that
can only be done in C++ or C, just that it's a powerful amount of stuff
that *has* been done in C++ and C. The important stuff isn't written
down in any other form besides C++ or C, so rewriting is a job of reverse
engineering. The web is not (much) based on well written standards, but
on bug-compatability.
--
Andrew
On Fri, 12 Sep 2008 15:45:50 +0100, Jon Harrop wrote:
> C# is a much better language with a much better standard library = more
> features for a lot less money.
How is the C# library any more "standard" than any other language
vendor's supplied library? You'd be as well as to call Matlab's toolkits
a "standard" library (and no doubt some do.) Probably have as many users.
Not that I'd dream of arguing that the C++ standard library is anything
to shout about... I gave up on C++ when they added templates (actually
before then: I didn't care much for RTTI and exceptions, either. I was
probably wrong about that, though.)
Cheers,
--
Andrew
Jon Harrop wrote:
> You obviously haven't been reading the news:
>
> Google's new web browser Chrome is written in C++. A buffer overrun security
> vulnerability was found in it 6 days ago:
>
> http://julianrdz.wordpress.com/2008/09/05/google-chrome-buffer-overflow-vulnerability/
Which language and development process would you recommend to use for safe
applications? I think a managed language is necessary, like the .NET
environment or Java, because even in Lisp you can crash the Lisp system,
e.g. when compiling this program in Lispworks 4.3:
(proclaim '(optimize (speed 3) (debug 0) (safety 0)))
(let ((test (make-array 10)))
(loop for i from 0 to 1000000 do (setf (aref test i) 0)))
But even with managed languages many bugs are possible, like bugs in the
application logic, memory leaking, deadlocks (in multithreaded
applications) etc. I wonder how much more time you'll need for programming
with more formal and automated verification systems, like SPARKAda, and if
in the end it is less time, because of less bugfixing and more user
productivity.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> But even with managed languages many bugs are possible, like bugs in the
> application logic, memory leaking, deadlocks (in multithreaded
> applications) etc. I wonder how much more time you'll need for programming
> with more formal and automated verification systems, like SPARKAda, and if
> in the end it is less time, because of less bugfixing and more user
> productivity.
Lisp programs should never be compiled with (safety 0). Only a few
carefully debugged critical functions may be compiled in this way.
Actually, I wouldn't consider (safety 0) to be a license to crash. As
a customer, I'd rather pay for an implementation who would keep a
minimal set of safety checks to avoid such an occurence.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
On Sep 12, 8:52 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Frank Buss <····@frank-buss.de> writes:
> > But even with managed languages many bugs are possible, like bugs in the
> > application logic, memory leaking, deadlocks (in multithreaded
> > applications) etc. I wonder how much more time you'll need for programming
> > with more formal and automated verification systems, like SPARKAda, and if
> > in the end it is less time, because of less bugfixing and more user
> > productivity.
>
> Lispprograms should never be compiled with (safety 0). Only a few
> carefully debugged critical functions may be compiled in this way.
I think that's an important message. Common Lisp software should
almost always
run with safety 2 or 3. If one sees benchmark code where the developer
attempted to create code that is as fast as C code (or whatever
language Lisp is compared to), then users should be aware that
this is benchmark code. Running large amounts of Lisp code with
security set to zero (and speed to 3) is wrong, wrong, wrong.
We not only need to look at benchmarks that run code with zero
security, we also need to look at benchmarks where the code runs
with full runtime safety - because that should be the default
for Lisp code. I want a Lisp that is fully checked and fast.
Code sections with low safety should be isolated and be kept as small
as possible. Lisp allows locally changing these settings with LOCALLY
or declarations for single functions. Even when I see a low-level
interfaces (say, say to TCP) and it uses lots of speed 3 + security 0
I would guess that it is not needed in most places and some the
crucial
optimizations (like buffering) can't be done by the compiler
(but have to written by the developer).
Users, don't set safety to zero globally!
We can nowadays run most compiled Lisp code with full runtime safety
and
lots of debugging info - usually processors are fast enough. That's
one of the beauty of Lisp implementations - they have a compiler
that creates reasonably fast code for fully checked code (no buffer
overflows, full error recovery at runtime, full heap safety, ...).
>
> Actually, I wouldn't consider (safety 0) to be a license to crash. As
> a customer, I'd rather pay for an implementation who would keep a
> minimal set of safety checks to avoid such an occurence.
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> Until real software engineering is developed, the next best practice
> is to develop with a dynamic system that has extreme late binding in
> all aspects. The first system to really do this in an important way
> is Lisp. -- Alan Kay
Vend <······@virgilio.it> writes:
> On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> DeverLite <············@gmail.com> writes:
>> > [...] Although very flexible, and good at catching errors at compile
>> > time, I found the typing system in Haskell sometimes got in the way.
>> > Lisp let's you declare types, but if you don't want to you don't have
>> > to, and this tends to make it more flexible than Haskell.
>>
>> Actually, what the lisp type system means is that in lisp we program
>> in generic mode by default.
>>
>> When you write:
>>
>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>>
>> it's statically typed, but it's also SPECIFICALLY typed.
>>
>> When you write in lisp:
>>
>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>>
>> it's already a generic function (not a lisp generic function,
>> technically, but what other programming languages call a generic
>> function):
>>
>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
>> --> (24 24.0 24.0L0 15/8)
>
> But the mathematical factorial function is defined only on natural
> numbers, hence this behavior is most likely incorrect.
Please, explain how something that is outside of the scope encompassed
by a mathematical definition can be "incorrect"?
"Blue" is not defined by the mathmatical factorial function
definition. Does that make "blue" incorrect?
> Moreover, in dynamically typed languages like Lisp there is the risk
> of having a statement like this buried deep in your program:
>
> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> ctrl-alt-shift-tab-right-mouse-button))
> (setq bomb "goodbye")
> (setq bomb 42))
>
> And then somewhere else a (fact bomb) makes your program crash and
> your client angry.
But strangely enough, lisp programs crash less often than C and C++
programs...
> I'm not sure about Common Lisp, but in Scheme, while arithmetic
> operators are overloaded, most library function aren't (there are
> different procedures for doing the same operation on lists, vectors,
> strings and streams, for instance), hence I wouldn't consider the
> language particularly generically typed.
Indeed, scheme has almost no generic functions. A shame.
--
__Pascal Bourguignon__ http://www.informatimago.com/
PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.
On 28 Ago, 23:54, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Vend <······@virgilio.it> writes:
> > On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> DeverLite <············@gmail.com> writes:
> >> > [...] Although very flexible, and good at catching errors at compile
> >> > time, I found the typing system in Haskell sometimes got in the way.
> >> > Lisp let's you declare types, but if you don't want to you don't have
> >> > to, and this tends to make it more flexible than Haskell.
>
> >> Actually, what the lisp type system means is that in lisp we program
> >> in generic mode by default.
>
> >> When you write:
>
> >> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> >> it's statically typed, but it's also SPECIFICALLY typed.
>
> >> When you write in lisp:
>
> >> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> >> it's already a generic function (not a lisp generic function,
> >> technically, but what other programming languages call a generic
> >> function):
>
> >> (mapcar 'fact '(4 4.0 4.0l0 5/2))
> >> --> (24 24.0 24.0L0 15/8)
>
> > But the mathematical factorial function is defined only on natural
> > numbers, hence this behavior is most likely incorrect.
>
> Please, explain how something that is outside of the scope encompassed
> by a mathematical definition can be "incorrect"?
I said *most likely* incorrect.
That behavior is correct if it's what you want to get, but when
somebody writes or uses a procedure which calculates the factorial
function he or she probably means it to be used on natural numbers.
Maybe I'm not very informed but there is no application of your
function with arguments that are anything but natural numbers I'm
aware of.
(the only partial exception I can think is using it on floats
restricted to mantissa-length integer values, which can be used as 53
bits integers on systems which support 64 bits floats but not 64 bits
integers. But on Lisp systems these low-level issues are probably
irrelevant).
> "Blue" is not defined by the mathmatical factorial function
> definition. Does that make "blue" incorrect?
>
> > Moreover, in dynamically typed languages like Lisp there is the risk
> > of having a statement like this buried deep in your program:
>
> > (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> > ctrl-alt-shift-tab-right-mouse-button))
> > (setq bomb "goodbye")
> > (setq bomb 42))
>
> > And then somewhere else a (fact bomb) makes your program crash and
> > your client angry.
>
> But strangely enough, lisp programs crash less often than C and C++
> programs...
C is statically typed but type-unsafe, among other kind of unsafe
"features" it has.
C++ is as unsafe as C and, due to its object orientation model, not
completely statically typed, but the language doesn't insert any
runtime dynamical type checks, so this is another source of unsafety.
Java has an OO model similar to that of C++ (but simplified) and it's
type-safe.
Runtime type errors can occour when attempting to cast the reference
of a given class type to a reference typed with one of its subclasses.
I don't have statistics, but I presume that this happens less
frequently than type errors in completely dynamically typed languages
like Lisp or Python.
(I'm not claiming that Java is better than Lisp or Python, I'm just
comparing this aspect).
> > I'm not sure about Common Lisp, but in Scheme, while arithmetic
> > operators are overloaded, most library function aren't (there are
> > different procedures for doing the same operation on lists, vectors,
> > strings and streams, for instance), hence I wouldn't consider the
> > language particularly generically typed.
>
> Indeed, scheme has almost no generic functions. A shame.
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> PLEASE NOTE: Some quantum physics theories suggest that when the
> consumer is not directly observing this product, it may cease to
> exist or will exist only in a vague and undetermined state.
On 2008-08-28, Vend <······@virgilio.it> wrote:
> C is statically typed but type-unsafe, among other kind of unsafe
> "features" it has.
Some of the reasons that C is type unsafe are very good, to the point that a
language which doesn't allow the same flexibility is a useless pile of crap
for any real-world software development.
> C++ is as unsafe as C and, due to its object orientation model, not
> completely statically typed, but the language doesn't insert any
> runtime dynamical type checks, so this is another source of unsafety.
That is false. C++ has dynamic checks in the dynamic_cast conversion
operator. If a class pointer is converted using dynamic_cast, the result may be
a null value, which must be checked by the program. If a reference is
converted, then a bad_cast exception may be thrown.
Of course, you can use an unsafe conversion operator which doesn't have checks.
> Java has an OO model similar to that of C++ (but simplified) and it's
> type-safe.
From Java, you can call a native platform function. That function can do
anything: crash your kernel, reformat your hard drive, blow up your video
card with bad parameters, etc.
No language whose definition allows for some kind of undefined behavior
(in the place of which an extension may be provided) can be called safe.
Without the ability to call native platform functions, a programming
environment is a crippled pile of shit, unsuitable for anything but coding
acadamic examples.
> I don't have statistics, but I presume that this happens less
> frequently than type errors in completely dynamically typed languages
> like Lisp or Python.
Right, you don't have statistics, but you presume.
> (I'm not claiming that Java is better than Lisp or Python, I'm just
> comparing this aspect).
I.e. comparing your lack of statistics about Java to your lack of statistics
about Lisp and python.
Vend wrote:
> C is statically typed but type-unsafe, among other kind of unsafe
> "features" it has.
> C++ is as unsafe as C and, due to its object orientation model, not
> completely statically typed, but the language doesn't insert any
> runtime dynamical type checks, so this is another source of unsafety.
Do you have a C++ example, where object orientation makes it not completely
statically typed? And for runtime dynamical checks in C++, take a look at
http://www.google.com/search?q=c%2B%2B+rtti
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On 29 Ago, 00:37, Frank Buss <····@frank-buss.de> wrote:
> Vend wrote:
> > C is statically typed but type-unsafe, among other kind of unsafe
> > "features" it has.
> > C++ is as unsafe as C and, due to its object orientation model, not
> > completely statically typed, but the language doesn't insert any
> > runtime dynamical type checks, so this is another source of unsafety.
>
> Do you have a C++ example, where object orientation makes it not completely
> statically typed?
By "statically typed" I mean that the compiler is always able to prove
which types of values a variable, parameter or expression represent.
class Foo {...};
class Bar : public Foo {...};
class Baz : public Foo {...};
...
Foo * a;
if (unpredictableAtCompileTime()) {
a = new Bar();
}
else {
a = new Baz();
}
Which type of object is 'a' pointing to?
> And for runtime dynamical checks in C++, take a look athttp://www.google.com/search?q=c%2B%2B+rtti
Ok, but it's an optional feature.
> --
> Frank Buss, ····@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de
Vend <······@virgilio.it> writes:
>
> By "statically typed" I mean that the compiler is always able to prove
> which types of values a variable, parameter or expression represent.
>
> class Foo {...};
> class Bar : public Foo {...};
> class Baz : public Foo {...};
>
> ...
>
> Foo * a;
> if (unpredictableAtCompileTime()) {
> a = new Bar();
> }
> else {
> a = new Baz();
> }
>
> Which type of object is 'a' pointing to?
I fail to see a problem here.
The obvious answer is that 'a' is pointing to an object of type Foo. For
any of the purposes for which one wants to use 'a', that should be all
that one needs to know. In fact, I would presume from this code that
the express intent of the programmer is to treat the object as being of
type Foo, which it in fact is.
So where's the problem? Since we have explicitly declared our intention
to not care which particular subclass is used, why is there any need to
worry about the issue?
You only get into trouble when you try to treat the object as being of a
different type. But doing that is a bad idea regardless of your
language.
--
Thomas A. Russ, USC/Information Sciences Institute
On 29 Ago, 22:36, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Vend <······@virgilio.it> writes:
>
> > By "statically typed" I mean that the compiler is always able to prove
> > which types of values a variable, parameter or expression represent.
>
> > class Foo {...};
> > class Bar : public Foo {...};
> > class Baz : public Foo {...};
>
> > ...
>
> > Foo * a;
> > if (unpredictableAtCompileTime()) {
> > a = new Bar();
> > }
> > else {
> > a = new Baz();
> > }
>
> > Which type of object is 'a' pointing to?
>
> I fail to see a problem here.
Did I say there was a problem?
> The obvious answer is that 'a' is pointing to an object of type Foo.
Right. But Foo is not the most specific type of the object 'a' is
pointing to. The most specific type is not knowable to the compiler,
hence the language is not completely statically typed.
Un(i)typed and dynamically typed languages can be seen as an extreme
case of this situation: all variables are of the same type which can
be seen as a base class of any value type.
> For
> any of the purposes for which one wants to use 'a', that should be all
> that one needs to know. In fact, I would presume from this code that
> the express intent of the programmer is to treat the object as being of
> type Foo, which it in fact is.
>
> So where's the problem? Since we have explicitly declared our intention
> to not care which particular subclass is used, why is there any need to
> worry about the issue?
>
> You only get into trouble when you try to treat the object as being of a
> different type. But doing that is a bad idea regardless of your
> language.
>
> --
> Thomas A. Russ, USC/Information Sciences Institute
Vend <······@virgilio.it> writes:
> On 29 Ago, 22:36, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> > Vend <······@virgilio.it> writes:
> >
> > > By "statically typed" I mean that the compiler is always able to prove
> > > which types of values a variable, parameter or expression represent.
> >
> > > class Foo {...};
> > > class Bar : public Foo {...};
> > > class Baz : public Foo {...};
> >
> > > ...
> >
> > > Foo * a;
> > > if (unpredictableAtCompileTime()) {
> > > a = new Bar();
> > > }
> > > else {
> > > a = new Baz();
> > > }
> >
> > > Which type of object is 'a' pointing to?
> >
> > I fail to see a problem here.
>
> Did I say there was a problem?
So, then what was the point? I guess I'm failing to see it.
> > The obvious answer is that 'a' is pointing to an object of type Foo.
>
> Right. But Foo is not the most specific type of the object 'a' is
> pointing to. The most specific type is not knowable to the compiler,
> hence the language is not completely statically typed.
My general reaction to this, then is "so what?"
Unless not having this completeness leads to a problem, this seems like
a fairly impractical theoretical issue to raise. So what if the most
specific type is not knowable at compile time? What problem or issue
does this cause?
--
Thomas A. Russ, USC/Information Sciences Institute
On 3 Set, 03:19, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Vend <······@virgilio.it> writes:
> > On 29 Ago, 22:36, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> > > Vend <······@virgilio.it> writes:
>
> > > > By "statically typed" I mean that the compiler is always able to prove
> > > > which types of values a variable, parameter or expression represent.
>
> > > > class Foo {...};
> > > > class Bar : public Foo {...};
> > > > class Baz : public Foo {...};
>
> > > > ...
>
> > > > Foo * a;
> > > > if (unpredictableAtCompileTime()) {
> > > > a = new Bar();
> > > > }
> > > > else {
> > > > a = new Baz();
> > > > }
>
> > > > Which type of object is 'a' pointing to?
>
> > > I fail to see a problem here.
>
> > Did I say there was a problem?
>
> So, then what was the point? I guess I'm failing to see it.
Frank Buss asked for an example of type dynamicity in C++.
> > > The obvious answer is that 'a' is pointing to an object of type Foo.
>
> > Right. But Foo is not the most specific type of the object 'a' is
> > pointing to. The most specific type is not knowable to the compiler,
> > hence the language is not completely statically typed.
>
> My general reaction to this, then is "so what?"
>
> Unless not having this completeness leads to a problem, this seems like
> a fairly impractical theoretical issue to raise. So what if the most
> specific type is not knowable at compile time? What problem or issue
> does this cause?
It's not just a theoretical issue. It allows run-time polymorphism.
And run-time type errors too, which can be result in exception being
thrown (in Java) or unspecified behavior (in C++ without RTTI or other
aids).
I'm not saying it's bad.
Vend <······@virgilio.it> writes:
> >
> > > Right. But Foo is not the most specific type of the object 'a' is
> > > pointing to. The most specific type is not knowable to the
> > > compiler, hence the language is not completely statically typed.
> >
> > My general reaction to this, then is "so what?"
> >
> > Unless not having this completeness leads to a problem, this seems
> > like a fairly impractical theoretical issue to raise. So what if
> > the most specific type is not knowable at compile time? What
> > problem or issue does this cause?
>
> It's not just a theoretical issue. It allows run-time polymorphism.
OK. That sounds like a good thing (which you acknowledge below).
> And run-time type errors too, which can be result in exception being
> thrown (in Java) or unspecified behavior (in C++ without RTTI or other
> aids).
I'm having a bit harder time seeing this. What sort of run-time type
errors do you envision?
Presumably the compiler should be able to check whether any operations
(methods) invoked on the object exist. So you wouldn't be able to slip
method calls past the compiler if they didn't have some realization on
the class which is the known parent of any possible instances. So what
kind of type error is then possible?
> I'm not saying it's bad.
--
Thomas A. Russ, USC/Information Sciences Institute
On 3 Set, 17:44, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Vend <······@virgilio.it> writes:
>
> > > > Right. But Foo is not the most specific type of the object 'a' is
> > > > pointing to. The most specific type is not knowable to the
> > > > compiler, hence the language is not completely statically typed.
>
> > > My general reaction to this, then is "so what?"
>
> > > Unless not having this completeness leads to a problem, this seems
> > > like a fairly impractical theoretical issue to raise. So what if
> > > the most specific type is not knowable at compile time? What
> > > problem or issue does this cause?
>
> > It's not just a theoretical issue. It allows run-time polymorphism.
>
> OK. That sounds like a good thing (which you acknowledge below).
>
> > And run-time type errors too, which can be result in exception being
> > thrown (in Java) or unspecified behavior (in C++ without RTTI or other
> > aids).
>
> I'm having a bit harder time seeing this. What sort of run-time type
> errors do you envision?
>
> Presumably the compiler should be able to check whether any operations
> (methods) invoked on the object exist. So you wouldn't be able to slip
> method calls past the compiler if they didn't have some realization on
> the class which is the known parent of any possible instances. So what
> kind of type error is then possible?
The error can happen when downcasting, that is, casting to a pointer
of a subclass type.
If the object isn't of that subclass type, you have a run-time type
error.
In Java this throws a ClassCastException.
In C++ with RTTI enabled and using the dynamic_cast operator you get a
null pointer (or an exception if done on references instead of
pointers).
If RTTI is disabled or you used another cast operator you get
unspecified behavior.
Vend <······@virgilio.it> writes:
> On 3 Set, 17:44, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> > Vend <······@virgilio.it> writes:
> >
> > > > > Right. But Foo is not the most specific type of the object 'a' is
> > > > > pointing to. The most specific type is not knowable to the
> > > > > compiler, hence the language is not completely statically typed.
> >
> > > > My general reaction to this, then is "so what?"
> >
> > > > Unless not having this completeness leads to a problem, this seems
> > > > like a fairly impractical theoretical issue to raise. ��So what if
> > > > the most specific type is not knowable at compile time? ��What
> > > > problem or issue does this cause?
> >
> > > It's not just a theoretical issue. It allows run-time polymorphism.
> >
> > OK. ��That sounds like a good thing (which you acknowledge below).
> >
> > > And run-time type errors too, which can be result in exception being
> > > thrown (in Java) or unspecified behavior (in C++ without RTTI or other
> > > aids).
> >
> > I'm having a bit harder time seeing this. ��What sort of run-time type
> > errors do you envision?
> >
> > Presumably the compiler should be able to check whether any operations
> > (methods) invoked on the object exist. ��So you wouldn't be able to slip
> > method calls past the compiler if they didn't have some realization on
> > the class which is the known parent of any possible instances. ��So what
> > kind of type error is then possible?
>
> The error can happen when downcasting, that is, casting to a pointer
> of a subclass type.
> If the object isn't of that subclass type, you have a run-time type
> error.
So, the problem is really one of downcasting and not really type
analysis. It is the existence of this sort of external manipulation
that is the problem. Perhaps it should just be banned. ;)
> In Java this throws a ClassCastException.
So what Java really needs is something like a smart TYPECASE statement
instead, where you can't downcast unless the type really matches up.
typecase (i){ // insert gratuitous parentheses
Bar: doBarThings(i);
break; // bleah
Baz: doBazthings(i);
break;
}
And then compiler then knows that inside each typecase block, the type
is of the given type. (Yeah, the stupid break requirement makes this
really tough to do properly. The correct syntax and semantics would be
to not allow fall-through, but allow multiple type tags:
typecase (i){
Bar: {
doBarThings(i);
}
Baz, Biz: {
doBazAndBizThings(i);
}
}
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> So what Java really needs is something like a smart TYPECASE statement
> instead, where you can't downcast unless the type really matches up.
>
> typecase (i){ // insert gratuitous parentheses
> Bar: doBarThings(i);
> break; // bleah
> Baz: doBazthings(i);
> break;
> }
You can write it like this:
if (i instanceof Bar) {
((Bar)i).doBarThings();
} else if (i instanceof Baz) {
((Baz)i).doBazthings();
}
But I think this is ugly code, feels like object oriented goto :-) Most of
the time you can avoid such things with a better class design.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> Thomas A. Russ wrote:
>
> > So what Java really needs is something like a smart TYPECASE statement
> > instead, where you can't downcast unless the type really matches up.
> >
> > typecase (i){ // insert gratuitous parentheses
> > Bar: doBarThings(i);
> > break; // bleah
> > Baz: doBazthings(i);
> > break;
> > }
>
> You can write it like this:
>
> if (i instanceof Bar) {
> ((Bar)i).doBarThings();
> } else if (i instanceof Baz) {
> ((Baz)i).doBazthings();
> }
>
> But I think this is ugly code, feels like object oriented goto :-) Most of
> the time you can avoid such things with a better class design.
Oh, I agree with the ugliness. Not to mention the need to make sure
that the casts inside the IF branches actually match the type test.
That is why I suggested some other language construct that would take
care of managing those aspects of the problem.
Now if this were Lisp instead of Java, it would be trivial to write a
macro that would do the transformation for you. [In fact, our Stella
language* does exactly that for typecase statements when it translates
to Java or C++.]
Something like this would be a useful construct for those languages,
similar to the addition of autoboxing of literal constants in recent
Java versions. Eventually, it looks like most of Lisp will end up
there. ;-)
* http://www.isi.edu/isd/LOOM/Stella/
--
Thomas A. Russ, USC/Information Sciences Institute
Frank Buss <··@frank-buss.de> writes:
> Thomas A. Russ wrote:
>
>> So what Java really needs is something like a smart TYPECASE statement
>> instead, where you can't downcast unless the type really matches up.
>>
>> typecase (i){ // insert gratuitous parentheses
>> Bar: doBarThings(i);
>> break; // bleah
>> Baz: doBazthings(i);
>> break;
>> }
>
> You can write it like this:
>
> if (i instanceof Bar) {
> ((Bar)i).doBarThings();
> } else if (i instanceof Baz) {
> ((Baz)i).doBazthings();
> }
>
Keep in mind that, that this will likely cause very unpredictable
behaviour of your program.
If we pass an object that type that doesn't match the the case
statement.
We are assuming that some sort of operation will be performed on object
`i' which presumably change the state of `i', (which is the prove of how
ugly this code is) but currently the case statement skips that.
> > But I think this is ugly code, feels like object oriented goto :-) Most of
> > the time you can avoid such things with a better class design.
> >
> > --
> > Frank Buss, ··@frank-buss.de
> > http://www.frank-buss.de, http://www.it4-systems.de
As above, agree.
Vend wrote:
> On 28 Ago, 23:54, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Vend <······@virgilio.it> writes:
>>> On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
>>> wrote:
>>>> DeverLite <············@gmail.com> writes:
>>>>> [...] Although very flexible, and good at catching errors at compile
>>>>> time, I found the typing system in Haskell sometimes got in the way.
>>>>> Lisp let's you declare types, but if you don't want to you don't have
>>>>> to, and this tends to make it more flexible than Haskell.
>>>> Actually, what the lisp type system means is that in lisp we program
>>>> in generic mode by default.
>>>> When you write:
>>>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>>>> it's statically typed, but it's also SPECIFICALLY typed.
>>>> When you write in lisp:
>>>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>>>> it's already a generic function (not a lisp generic function,
>>>> technically, but what other programming languages call a generic
>>>> function):
>>>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
>>>> --> (24 24.0 24.0L0 15/8)
>>> But the mathematical factorial function is defined only on natural
>>> numbers, hence this behavior is most likely incorrect.
>> Please, explain how something that is outside of the scope encompassed
>> by a mathematical definition can be "incorrect"?
>
> I said *most likely* incorrect.
>
> That behavior is correct if it's what you want to get, but when
> somebody writes or uses a procedure which calculates the factorial
> function he or she probably means it to be used on natural numbers.
The importance of the factorial function in production code is grossly
overestimated. ;)
>> "Blue" is not defined by the mathmatical factorial function
>> definition. Does that make "blue" incorrect?
>>
>>> Moreover, in dynamically typed languages like Lisp there is the risk
>>> of having a statement like this buried deep in your program:
>>> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
>>> ctrl-alt-shift-tab-right-mouse-button))
>>> (setq bomb "goodbye")
>>> (setq bomb 42))
>>> And then somewhere else a (fact bomb) makes your program crash and
>>> your client angry.
>> But strangely enough, lisp programs crash less often than C and C++
>> programs...
>
> C is statically typed but type-unsafe, among other kind of unsafe
> "features" it has.
> C++ is as unsafe as C and, due to its object orientation model, not
> completely statically typed, but the language doesn't insert any
> runtime dynamical type checks, so this is another source of unsafety.
>
> Java has an OO model similar to that of C++ (but simplified) and it's
> type-safe.
> Runtime type errors can occour when attempting to cast the reference
> of a given class type to a reference typed with one of its subclasses.
> I don't have statistics, but I presume that this happens less
> frequently than type errors in completely dynamically typed languages
> like Lisp or Python.
> (I'm not claiming that Java is better than Lisp or Python, I'm just
> comparing this aspect).
Java is a language that serves as a good reference for illustrating how
static type systems can _introduce_ new sources of bugs which don't
exist in dynamically typed languages:
http://p-cos.net/documents/dynatype.pdf
Whether a type system is dynamic or not doesn't tell you a lot. You need
a _good_ type system. For example, one that gives something close to a
half when you divide one by two, or something that doesn't silently wrap
around when you get beyond 32 bits. Few type systems have these
characteristics.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 29 Ago, 01:28, Pascal Costanza <····@p-cos.net> wrote:
> Vend wrote:
> > On 28 Ago, 23:54, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> Vend <······@virgilio.it> writes:
> >>> On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
> >>> wrote:
> >>>> DeverLite <············@gmail.com> writes:
> >>>>> [...] Although very flexible, and good at catching errors at compile
> >>>>> time, I found the typing system inHaskellsometimes got in the way.
> >>>>> Lisp let's you declare types, but if you don't want to you don't have
> >>>>> to, and this tends to make it more flexible thanHaskell.
> >>>> Actually, what the lisp type system means is that in lisp we program
> >>>> in generic mode by default.
> >>>> When you write:
> >>>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
> >>>> it's statically typed, but it's also SPECIFICALLY typed.
> >>>> When you write in lisp:
> >>>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
> >>>> it's already a generic function (not a lisp generic function,
> >>>> technically, but what other programming languages call a generic
> >>>> function):
> >>>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
> >>>> --> (24 24.0 24.0L0 15/8)
> >>> But the mathematical factorial function is defined only on natural
> >>> numbers, hence this behavior is most likely incorrect.
> >> Please, explain how something that is outside of the scope encompassed
> >> by a mathematical definition can be "incorrect"?
>
> > I said *most likely* incorrect.
>
> > That behavior is correct if it's what you want to get, but when
> > somebody writes or uses a procedure which calculates the factorial
> > function he or she probably means it to be used on natural numbers.
>
> The importance of the factorial function in production code is grossly
> overestimated. ;)
>
>
>
> >> "Blue" is not defined by the mathmatical factorial function
> >> definition. Does that make "blue" incorrect?
>
> >>> Moreover, in dynamically typed languages like Lisp there is the risk
> >>> of having a statement like this buried deep in your program:
> >>> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> >>> ctrl-alt-shift-tab-right-mouse-button))
> >>> (setq bomb "goodbye")
> >>> (setq bomb 42))
> >>> And then somewhere else a (fact bomb) makes your program crash and
> >>> your client angry.
> >> But strangely enough, lisp programs crash less often than C and C++
> >> programs...
>
> > C is statically typed but type-unsafe, among other kind of unsafe
> > "features" it has.
> > C++ is as unsafe as C and, due to its object orientation model, not
> > completely statically typed, but the language doesn't insert any
> > runtime dynamical type checks, so this is another source of unsafety.
>
> > Java has an OO model similar to that of C++ (but simplified) and it's
> > type-safe.
> > Runtime type errors can occour when attempting to cast the reference
> > of a given class type to a reference typed with one of its subclasses.
> > I don't have statistics, but I presume that this happens less
> > frequently than type errors in completely dynamically typed languages
> > like Lisp or Python.
> > (I'm not claiming that Java is better than Lisp or Python, I'm just
> > comparing this aspect).
>
> Java is a language that serves as a good reference for illustrating how
> static type systems can _introduce_ new sources of bugs which don't
> exist in dynamically typed languages:http://p-cos.net/documents/dynatype.pdf
Your paper lists three anti-patterns.
The first one, method stubs inserted due the need to define all
abstract methods in non-abstract classes, doesn't seem an anti-patter
to me.
It actually forces the programmer to think about the methods that can
be called on a class.
Sure, it's possible to implement a stub and then forget about it, but
I think that's far less likely than forgetting to implement a method
in a language that doesn't complain about it.
(Anyway, you are right that the stub generated by Eclipse is bad).
The second issue, checked exceptions, is Java specific as far as I
know, and doesn't appear to be particularly related to static vs.
dynamic typing.
The third example is flawed:
First of all you present it as a flaw of static typing while it's
actually due to dynamic typing introduced by polymorphism. If Java was
fully statically typed, all occurrences of 'instanceof' would be
resolved at compile-time.
In fact, that kind of race condition can happen in dynamically typed
languages, which, if the language runtime is thread-safe, would raise
an exception equivalent to ClassCastException, otherwise would cause
unspecified and unsafe behavior.
Second, that pattern is an example of bad programming since in
multithreading environments you should always synchronize before
accessing a shared mutable resource.
> Whether a type system is dynamic or not doesn't tell you a lot. You need
> a _good_ type system. For example, one that gives something close to a
> half when you divide one by two, or something that doesn't silently wrap
> around when you get beyond 32 bits. Few type systems have these
> characteristics.
Agreed.
<snip>
Vend wrote:
> On 29 Ago, 01:28, Pascal Costanza <····@p-cos.net> wrote:
>> Vend wrote:
>>> On 28 Ago, 23:54, ····@informatimago.com (Pascal J. Bourguignon)
>>> wrote:
>>>> Vend <······@virgilio.it> writes:
>>>>> On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
>>>>> wrote:
>>>>>> DeverLite <············@gmail.com> writes:
>>>>>>> [...] Although very flexible, and good at catching errors at compile
>>>>>>> time, I found the typing system inHaskellsometimes got in the way.
>>>>>>> Lisp let's you declare types, but if you don't want to you don't have
>>>>>>> to, and this tends to make it more flexible thanHaskell.
>>>>>> Actually, what the lisp type system means is that in lisp we program
>>>>>> in generic mode by default.
>>>>>> When you write:
>>>>>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>>>>>> it's statically typed, but it's also SPECIFICALLY typed.
>>>>>> When you write in lisp:
>>>>>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>>>>>> it's already a generic function (not a lisp generic function,
>>>>>> technically, but what other programming languages call a generic
>>>>>> function):
>>>>>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
>>>>>> --> (24 24.0 24.0L0 15/8)
>>>>> But the mathematical factorial function is defined only on natural
>>>>> numbers, hence this behavior is most likely incorrect.
>>>> Please, explain how something that is outside of the scope encompassed
>>>> by a mathematical definition can be "incorrect"?
>>> I said *most likely* incorrect.
>>> That behavior is correct if it's what you want to get, but when
>>> somebody writes or uses a procedure which calculates the factorial
>>> function he or she probably means it to be used on natural numbers.
>> The importance of the factorial function in production code is grossly
>> overestimated. ;)
>>
>>
>>
>>>> "Blue" is not defined by the mathmatical factorial function
>>>> definition. Does that make "blue" incorrect?
>>>>> Moreover, in dynamically typed languages like Lisp there is the risk
>>>>> of having a statement like this buried deep in your program:
>>>>> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
>>>>> ctrl-alt-shift-tab-right-mouse-button))
>>>>> (setq bomb "goodbye")
>>>>> (setq bomb 42))
>>>>> And then somewhere else a (fact bomb) makes your program crash and
>>>>> your client angry.
>>>> But strangely enough, lisp programs crash less often than C and C++
>>>> programs...
>>> C is statically typed but type-unsafe, among other kind of unsafe
>>> "features" it has.
>>> C++ is as unsafe as C and, due to its object orientation model, not
>>> completely statically typed, but the language doesn't insert any
>>> runtime dynamical type checks, so this is another source of unsafety.
>>> Java has an OO model similar to that of C++ (but simplified) and it's
>>> type-safe.
>>> Runtime type errors can occour when attempting to cast the reference
>>> of a given class type to a reference typed with one of its subclasses.
>>> I don't have statistics, but I presume that this happens less
>>> frequently than type errors in completely dynamically typed languages
>>> like Lisp or Python.
>>> (I'm not claiming that Java is better than Lisp or Python, I'm just
>>> comparing this aspect).
>> Java is a language that serves as a good reference for illustrating how
>> static type systems can _introduce_ new sources of bugs which don't
>> exist in dynamically typed languages:http://p-cos.net/documents/dynatype.pdf
>
> Your paper lists three anti-patterns.
>
> The first one, method stubs inserted due the need to define all
> abstract methods in non-abstract classes, doesn't seem an anti-patter
> to me.
> It actually forces the programmer to think about the methods that can
> be called on a class.
>
> Sure, it's possible to implement a stub and then forget about it, but
> I think that's far less likely than forgetting to implement a method
> in a language that doesn't complain about it.
That's what you think. I think something else. Now who's right? Hint:
We're all only guessing.
> (Anyway, you are right that the stub generated by Eclipse is bad).
...and the static type system is happy after what Eclipse generated. So
the combination of a static type system and a development environment
lures programmers into thinking he's safe, and nobody forced anyone to
think about anything.
> The second issue, checked exceptions, is Java specific as far as I
> know, and doesn't appear to be particularly related to static vs.
> dynamic typing.
A static type system classifies expressions according to one or more
static types. Java's exception system provides a classification into
whether an expression throws a checked exception or not. Hence, it's a
static type system. (Including the fact that if the type checker cannot
classify an expression into one of the two categories, it will reject
the corresponding program.)
This may not be a good a type system, but it's a static type system
nonetheless, a widely used one, and at least once propagated as a very
good idea to include in a programming language by static thinkers.
> The third example is flawed:
>
> First of all you present it as a flaw of static typing while it's
> actually due to dynamic typing introduced by polymorphism. If Java was
> fully statically typed, all occurrences of 'instanceof' would be
> resolved at compile-time.
> In fact, that kind of race condition can happen in dynamically typed
> languages, which, if the language runtime is thread-safe, would raise
> an exception equivalent to ClassCastException, otherwise would cause
> unspecified and unsafe behavior.
>
> Second, that pattern is an example of bad programming since in
> multithreading environments you should always synchronize before
> accessing a shared mutable resource.
It's funny. Everybody agrees with at least one of the pattern and
disagrees with at least one other pattern. But it's always different
ones. (And this is independent whether they are supporters of static or
dynamic languages.)
Go figure.
As I said, we're all just guessing. Don't try to sell this as rational
thought. That's all I'm asking for...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 29 Ago, 18:06, Pascal Costanza <····@p-cos.net> wrote:
> Vend wrote:
> > On 29 Ago, 01:28, Pascal Costanza <····@p-cos.net> wrote:
> >> Vend wrote:
> >>> On 28 Ago, 23:54, ····@informatimago.com (Pascal J. Bourguignon)
> >>> wrote:
> >>>> Vend <······@virgilio.it> writes:
> >>>>> On 20 Ago, 02:07, ····@informatimago.com (Pascal J. Bourguignon)
> >>>>> wrote:
> >>>>>> DeverLite <············@gmail.com> writes:
> >>>>>>> [...] Although very flexible, and good at catching errors at compile
> >>>>>>> time, I found the typing system inHaskellsometimes got in the way.
> >>>>>>> Lisp let's you declare types, but if you don't want to you don't have
> >>>>>>> to, and this tends to make it more flexible thanHaskell.
> >>>>>> Actually, what the lisp type system means is that in lisp we program
> >>>>>> in generic mode by default.
> >>>>>> When you write:
> >>>>>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
> >>>>>> it's statically typed, but it's also SPECIFICALLY typed.
> >>>>>> When you write in lisp:
> >>>>>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
> >>>>>> it's already a generic function (not a lisp generic function,
> >>>>>> technically, but what other programming languages call a generic
> >>>>>> function):
> >>>>>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
> >>>>>> --> (24 24.0 24.0L0 15/8)
> >>>>> But the mathematical factorial function is defined only on natural
> >>>>> numbers, hence this behavior is most likely incorrect.
> >>>> Please, explain how something that is outside of the scope encompassed
> >>>> by a mathematical definition can be "incorrect"?
> >>> I said *most likely* incorrect.
> >>> That behavior is correct if it's what you want to get, but when
> >>> somebody writes or uses a procedure which calculates the factorial
> >>> function he or she probably means it to be used on natural numbers.
> >> The importance of the factorial function in production code is grossly
> >> overestimated. ;)
>
> >>>> "Blue" is not defined by the mathmatical factorial function
> >>>> definition. Does that make "blue" incorrect?
> >>>>> Moreover, in dynamically typed languages like Lisp there is the risk
> >>>>> of having a statement like this buried deep in your program:
> >>>>> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> >>>>> ctrl-alt-shift-tab-right-mouse-button))
> >>>>> (setq bomb "goodbye")
> >>>>> (setq bomb 42))
> >>>>> And then somewhere else a (fact bomb) makes your program crash and
> >>>>> your client angry.
> >>>> But strangely enough, lisp programs crash less often than C and C++
> >>>> programs...
> >>> C is statically typed but type-unsafe, among other kind of unsafe
> >>> "features" it has.
> >>> C++ is as unsafe as C and, due to its object orientation model, not
> >>> completely statically typed, but the language doesn't insert any
> >>> runtime dynamical type checks, so this is another source of unsafety.
> >>> Java has an OO model similar to that of C++ (but simplified) and it's
> >>> type-safe.
> >>> Runtime type errors can occour when attempting to cast the reference
> >>> of a given class type to a reference typed with one of its subclasses.
> >>> I don't have statistics, but I presume that this happens less
> >>> frequently than type errors in completely dynamically typed languages
> >>> like Lisp or Python.
> >>> (I'm not claiming that Java is better than Lisp or Python, I'm just
> >>> comparing this aspect).
> >> Java is a language that serves as a good reference for illustrating how
> >> static type systems can _introduce_ new sources of bugs which don't
> >> exist in dynamically typed languages:http://p-cos.net/documents/dynatype.pdf
>
> > Your paper lists three anti-patterns.
>
> > The first one, method stubs inserted due the need to define all
> > abstract methods in non-abstract classes, doesn't seem an anti-patter
> > to me.
> > It actually forces the programmer to think about the methods that can
> > be called on a class.
>
> > Sure, it's possible to implement a stub and then forget about it, but
> > I think that's far less likely than forgetting to implement a method
> > in a language that doesn't complain about it.
>
> That's what you think. I think something else.
Do you think that's easier to forget to implement a method after
writing a stub for it rather than after writing nothing about it?
> Now who's right? Hint:
> We're all only guessing.
So the discussion we had up to now is all meaningless?
> > (Anyway, you are right that the stub generated by Eclipse is bad).
>
> ...and the static type system is happy after what Eclipse generated. So
> the combination of a static type system and a development environment
> lures programmers into thinking he's safe, and nobody forced anyone to
> think about anything.
Shame on Eclipse.
> > The second issue, checked exceptions, is Java specific as far as I
> > know, and doesn't appear to be particularly related to static vs.
> > dynamic typing.
>
> A static type system classifies expressions according to one or more
> static types. Java's exception system provides a classification into
> whether an expression throws a checked exception or not. Hence, it's a
> static type system. (Including the fact that if the type checker cannot
> classify an expression into one of the two categories, it will reject
> the corresponding program.)
Yes, but the existence of checked exceptions is Java-specific, as far
as I know.
> This may not be a good a type system, but it's a static type system
> nonetheless, a widely used one, and at least once propagated as a very
> good idea to include in a programming language by static thinkers.
>
> > The third example is flawed:
>
> > First of all you present it as a flaw of static typing while it's
> > actually due to dynamic typing introduced by polymorphism. If Java was
> > fully statically typed, all occurrences of 'instanceof' would be
> > resolved at compile-time.
> > In fact, that kind of race condition can happen in dynamically typed
> > languages, which, if the language runtime is thread-safe, would raise
> > an exception equivalent to ClassCastException, otherwise would cause
> > unspecified and unsafe behavior.
>
> > Second, that pattern is an example of bad programming since in
> > multithreading environments you should always synchronize before
> > accessing a shared mutable resource.
>
> It's funny. Everybody agrees with at least one of the pattern and
> disagrees with at least one other pattern. But it's always different
> ones. (And this is independent whether they are supporters of static or
> dynamic languages.)
>
> Go figure.
>
> As I said, we're all just guessing. Don't try to sell this as rational
> thought. That's all I'm asking for...
There are random guesses and there are reasonable hypotheses. And then
there are facts.
My claim about your first pattern is a reasonable hypothesis in my
opinion, the second is more a question of semantics and the third is a
fact.
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
Vend wrote:
> On 29 Ago, 18:06, Pascal Costanza <····@p-cos.net> wrote:
>> Vend wrote:
>>> It actually forces the programmer to think about the methods that can
>>> be called on a class.
>>> Sure, it's possible to implement a stub and then forget about it, but
>>> I think that's far less likely than forgetting to implement a method
>>> in a language that doesn't complain about it.
>> That's what you think. I think something else.
>
> Do you think that's easier to forget to implement a method after
> writing a stub for it rather than after writing nothing about it?
In a dynamically typed language, you get runtime exception for a missing
method/function as soon as there is an attempt to invoke it at runtime,
not sooner, not later. As soon as you get that exception, you know that
there is something that still needs to be implemented. You can even do
this at that stage, when the default exception handler is waiting for
interactive resolution. As soon as the method / function is defined, you
can just continue execution from the place where the exception occurred.
If you are forced to implement a stub by the static type system, it's
likely that you get the stub wrong (as my paper shows), and the
situation will be much worse. The only correct stub to write is to
implement the functionality a dynamically typed language already
provides by default anyway.
You cannot force programmers to do anything. Programming languages
should support programmers, not stand in their way. That's what I think.
>> Now who's right? Hint:
>> We're all only guessing.
>
> So the discussion we had up to now is all meaningless?
No, it's not meaningless. But you have to realize that it's only an
exchange of opinions, not of hard facts.
There may be "subjectively hard" facts, like which programming style
suits your personality better or not. It may very well be that (certain)
statically typed languages are easier for you to handle than (certain)
dynamically typed languages. But that doesn't say anything about static
typing and dynamic typing in general.
The errors static thinkers assume to pop all the time in dynamic
languages don't exist in practice, at least when programmers use those
languages to who the corresponding programming style fits well. That's
another ("subjectively hard") fact. Better deal with it.
>>> (Anyway, you are right that the stub generated by Eclipse is bad).
>> ...and the static type system is happy after what Eclipse generated. So
>> the combination of a static type system and a development environment
>> lures programmers into thinking he's safe, and nobody forced anyone to
>> think about anything.
>
> Shame on Eclipse.
No, this is not Eclipse's fault. It's the fault of the overall eco
system surrounding Java, including the fact that is has a relatively bad
type system.
>>> The second issue, checked exceptions, is Java specific as far as I
>>> know, and doesn't appear to be particularly related to static vs.
>>> dynamic typing.
>> A static type system classifies expressions according to one or more
>> static types. Java's exception system provides a classification into
>> whether an expression throws a checked exception or not. Hence, it's a
>> static type system. (Including the fact that if the type checker cannot
>> classify an expression into one of the two categories, it will reject
>> the corresponding program.)
>
> Yes, but the existence of checked exceptions is Java-specific, as far
> as I know.
As I said, it's not so much important whether a type system is static or
not, but it's rather important whether it's good or not.
>>> The third example is flawed:
>>> First of all you present it as a flaw of static typing while it's
>>> actually due to dynamic typing introduced by polymorphism. If Java was
>>> fully statically typed, all occurrences of 'instanceof' would be
>>> resolved at compile-time.
>>> In fact, that kind of race condition can happen in dynamically typed
>>> languages, which, if the language runtime is thread-safe, would raise
>>> an exception equivalent to ClassCastException, otherwise would cause
>>> unspecified and unsafe behavior.
>>> Second, that pattern is an example of bad programming since in
>>> multithreading environments you should always synchronize before
>>> accessing a shared mutable resource.
>> It's funny. Everybody agrees with at least one of the pattern and
>> disagrees with at least one other pattern. But it's always different
>> ones. (And this is independent whether they are supporters of static or
>> dynamic languages.)
>>
>> Go figure.
>>
>> As I said, we're all just guessing. Don't try to sell this as rational
>> thought. That's all I'm asking for...
>
> There are random guesses and there are reasonable hypotheses. And then
> there are facts.
>
> My claim about your first pattern is a reasonable hypothesis in my
> opinion, the second is more a question of semantics and the third is a
> fact.
Matthias Felleisen stated that the third example is the only one which
is actually indeed about the static type system. (He dismissed the other
two.)
I think the fact that people cannot even agree which of the examples are
valid ones or not proves the point of the paper: Static type systems
don't guarantee anything.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 31 Ago, 22:03, Pascal Costanza <····@p-cos.net> wrote:
> Vend wrote:
> > On 29 Ago, 18:06, Pascal Costanza <····@p-cos.net> wrote:
> >> Vend wrote:
> >>> It actually forces the programmer to think about the methods that can
> >>> be called on a class.
> >>> Sure, it's possible to implement a stub and then forget about it, but
> >>> I think that's far less likely than forgetting to implement a method
> >>> in a language that doesn't complain about it.
> >> That's what you think. I think something else.
>
> > Do you think that's easier to forget to implement a method after
> > writing a stub for it rather than after writing nothing about it?
>
> In a dynamically typed language, you get runtime exception for a missing
> method/function as soon as there is an attempt to invoke it at runtime,
> not sooner, not later.
Which can happen on the production system.
> As soon as you get that exception, you know that
> there is something that still needs to be implemented. You can even do
> this at that stage, when the default exception handler is waiting for
> interactive resolution. As soon as the method / function is defined, you
> can just continue execution from the place where the exception occurred.
I suppose one should try to prevent the software from failing as much
as it's possible rather than waiting it to fail before fixing it.
> If you are forced to implement a stub by the static type system, it's
> likely that you get the stub wrong (as my paper shows), and the
> situation will be much worse.
There are always ways to get things wrong, but at least when you
implement a stub you have to think about that method.
If the method is just in the documentation there are higher chances of
forgetting about it, not to mention incomplete or obsolete
documentations.
Moreover, you can always insert "TODO" comments or, in languages which
support them, assertions or marcos in your stubs to allow an automatic
check to catch all the non-implemented stubs.
> The only correct stub to write is to
> implement the functionality a dynamically typed language already
> provides by default anyway.
Yes, but an explicit stub has the benefit of acting as a memo for
anybody who writes or reads it, and it's easy to check for it's
presence even in a large project (just search the code for the text
"TODO" or the exception name, or insert an assertion or marco that
refuses to compile when a switch is turned on).
The default behavior of dynamically typed languages is, in this case
and in general, to fail as late as possible, which can be too late.
> You cannot force programmers to do anything. Programming languages
> should support programmers, not stand in their way. That's what I think.
Ok. We seem to have different concepts of standing in the way.
> >> Now who's right? Hint:
> >> We're all only guessing.
>
> > So the discussion we had up to now is all meaningless?
>
> No, it's not meaningless. But you have to realize that it's only an
> exchange of opinions, not of hard facts.
>
> There may be "subjectively hard" facts, like which programming style
> suits your personality better or not. It may very well be that (certain)
> statically typed languages are easier for you to handle than (certain)
> dynamically typed languages. But that doesn't say anything about static
> typing and dynamic typing in general.
>
> The errors static thinkers assume to pop all the time in dynamic
> languages don't exist in practice, at least when programmers use those
> languages to who the corresponding programming style fits well. That's
> another ("subjectively hard") fact. Better deal with it.
While it's an objectively hard fact that such errors don't exist in
static typed languages, nor in theory neither in practice.
So what's the benefit of a dynamical type system?
> >>> (Anyway, you are right that the stub generated by Eclipse is bad).
> >> ...and the static type system is happy after what Eclipse generated. So
> >> the combination of a static type system and a development environment
> >> lures programmers into thinking he's safe, and nobody forced anyone to
> >> think about anything.
>
> > Shame on Eclipse.
>
> No, this is not Eclipse's fault.
Yes, it is. Generating an empty stub seems to me the best way of doing
it.
Generating a stub that throws an exception (simulating the behavior of
a dynamical language) would also be acceptable.
But generating a stub that returns a default value is asking for bugs.
> It's the fault of the overall eco
> system surrounding Java, including the fact that is has a relatively bad
> type system.
Sure, Java has many flaws and this has prompted the rise of IDEs that
attempt to compensate by generating large amounts of bug-prone
boilerplate code.
> >>> The second issue, checked exceptions, is Java specific as far as I
> >>> know, and doesn't appear to be particularly related to static vs.
> >>> dynamic typing.
> >> A static type system classifies expressions according to one or more
> >> static types. Java's exception system provides a classification into
> >> whether an expression throws a checked exception or not. Hence, it's a
> >> static type system. (Including the fact that if the type checker cannot
> >> classify an expression into one of the two categories, it will reject
> >> the corresponding program.)
>
> > Yes, but the existence of checked exceptions is Java-specific, as far
> > as I know.
>
> As I said, it's not so much important whether a type system is static or
> not, but it's rather important whether it's good or not.
Exception management is only marginally related to the type system.
> >>> The third example is flawed:
> >>> First of all you present it as a flaw of static typing while it's
> >>> actually due to dynamic typing introduced by polymorphism. If Java was
> >>> fully statically typed, all occurrences of 'instanceof' would be
> >>> resolved at compile-time.
> >>> In fact, that kind of race condition can happen in dynamically typed
> >>> languages, which, if the language runtime is thread-safe, would raise
> >>> an exception equivalent to ClassCastException, otherwise would cause
> >>> unspecified and unsafe behavior.
> >>> Second, that pattern is an example of bad programming since in
> >>> multithreading environments you should always synchronize before
> >>> accessing a shared mutable resource.
> >> It's funny. Everybody agrees with at least one of the pattern and
> >> disagrees with at least one other pattern. But it's always different
> >> ones. (And this is independent whether they are supporters of static or
> >> dynamic languages.)
>
> >> Go figure.
>
> >> As I said, we're all just guessing. Don't try to sell this as rational
> >> thought. That's all I'm asking for...
>
> > There are random guesses and there are reasonable hypotheses. And then
> > there are facts.
>
> > My claim about your first pattern is a reasonable hypothesis in my
> > opinion, the second is more a question of semantics and the third is a
> > fact.
>
> Matthias Felleisen stated that the third example is the only one which
> is actually indeed about the static type system. (He dismissed the other
> two.)
I think the first one is partially related (is more an issue of the
specific Java type system than a general feature of static type
systems), the second one is mostly unrelated.
The third one is related to the type system but it's flawed. (It's an
effect on the dynamical aspects of Java type system in a badly
designed multi-threading scenario).
> I think the fact that people cannot even agree which of the examples are
> valid ones or not proves the point of the paper: Static type systems
> don't guarantee anything.
It could be that people have different definitions of static and
dynamic type system.
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
Vend wrote:
> On 31 Ago, 22:03, Pascal Costanza <····@p-cos.net> wrote:
>> Vend wrote:
>>> On 29 Ago, 18:06, Pascal Costanza <····@p-cos.net> wrote:
>>>> Vend wrote:
>>>>> It actually forces the programmer to think about the methods that can
>>>>> be called on a class.
>>>>> Sure, it's possible to implement a stub and then forget about it, but
>>>>> I think that's far less likely than forgetting to implement a method
>>>>> in a language that doesn't complain about it.
>>>> That's what you think. I think something else.
>>> Do you think that's easier to forget to implement a method after
>>> writing a stub for it rather than after writing nothing about it?
>> In a dynamically typed language, you get runtime exception for a missing
>> method/function as soon as there is an attempt to invoke it at runtime,
>> not sooner, not later.
>
> Which can happen on the production system.
...unless you have a fairly complete test suite, which you should have
anyway.
>> As soon as you get that exception, you know that
>> there is something that still needs to be implemented. You can even do
>> this at that stage, when the default exception handler is waiting for
>> interactive resolution. As soon as the method / function is defined, you
>> can just continue execution from the place where the exception occurred.
>
> I suppose one should try to prevent the software from failing as much
> as it's possible rather than waiting it to fail before fixing it.
That depends on the situation: http://www.paulgraham.com/lwba.html
(That's a major problem with you static thinkers, you have a far too
narrow view on what's possible, and the advantages and disadvantages of
different possible approaches.)
But be that as it may, static type systems don't really help here
anyway. Static type systems catch static type errors. Whether that has
_anything_ to do with actual failures or not depends on a lot of factors
unrelated to the type system.
>> If you are forced to implement a stub by the static type system, it's
>> likely that you get the stub wrong (as my paper shows), and the
>> situation will be much worse.
>
> There are always ways to get things wrong, but at least when you
> implement a stub you have to think about that method.
> If the method is just in the documentation there are higher chances of
> forgetting about it, not to mention incomplete or obsolete
> documentations.
Why are you continuously ignoring the fact that the _right_ solution for
a method stub is what dynamically typed languages provide anyway.
Why do you insist on annoying programmers (aka "force them to think")?
> Moreover, you can always insert "TODO" comments or, in languages which
> support them, assertions or marcos in your stubs to allow an automatic
> check to catch all the non-implemented stubs.
You can probably also drill a hole in your knee and pour milk through it.
In a good Lisp IDE, it's a piece of cake to get an overview of all the
functions that are called but aren't implemented. So why should I be
bothered doing all that crap?
> The default behavior of dynamically typed languages is, in this case
> and in general, to fail as late as possible, which can be too late.
No, it fails at exactly the right point in time. Incorrect stubs, forced
by stupid static type systems, will make the code fail later than necessary.
>> You cannot force programmers to do anything. Programming languages
>> should support programmers, not stand in their way. That's what I think.
>
> Ok. We seem to have different concepts of standing in the way.
True.
>> The errors static thinkers assume to pop all the time in dynamic
>> languages don't exist in practice, at least when programmers use those
>> languages to who the corresponding programming style fits well. That's
>> another ("subjectively hard") fact. Better deal with it.
>
> While it's an objectively hard fact that such errors don't exist in
> static typed languages, nor in theory neither in practice.
> So what's the benefit of a dynamical type system?
Two answers: The errors static type systems and dynamic type systems
catch overlap, but are not the same.
The benefit of a dynamic type system is to ensure that operations that
are not defined for certain kinds of data are not blindly executed on
those data, but throw corresponding exceptions. (What did you think?)
>>>>> (Anyway, you are right that the stub generated by Eclipse is bad).
>>>> ...and the static type system is happy after what Eclipse generated. So
>>>> the combination of a static type system and a development environment
>>>> lures programmers into thinking he's safe, and nobody forced anyone to
>>>> think about anything.
>>> Shame on Eclipse.
>> No, this is not Eclipse's fault.
>
> Yes, it is. Generating an empty stub seems to me the best way of doing
> it.
> Generating a stub that throws an exception (simulating the behavior of
> a dynamical language) would also be acceptable.
> But generating a stub that returns a default value is asking for bugs.
...but this is exactly what you get because of the underlying static
type system!
Hint: The Eclipse developers were "forced" to think about this because
of the static type system. There you see what you get from being
"forced" to think about something.
To repeat: You cannot force programmers to do anything.
>> It's the fault of the overall eco
>> system surrounding Java, including the fact that is has a relatively bad
>> type system.
>
> Sure, Java has many flaws and this has prompted the rise of IDEs that
> attempt to compensate by generating large amounts of bug-prone
> boilerplate code.
We agree here.
>>>>> The second issue, checked exceptions, is Java specific as far as I
>>>>> know, and doesn't appear to be particularly related to static vs.
>>>>> dynamic typing.
>>>> A static type system classifies expressions according to one or more
>>>> static types. Java's exception system provides a classification into
>>>> whether an expression throws a checked exception or not. Hence, it's a
>>>> static type system. (Including the fact that if the type checker cannot
>>>> classify an expression into one of the two categories, it will reject
>>>> the corresponding program.)
>>> Yes, but the existence of checked exceptions is Java-specific, as far
>>> as I know.
>> As I said, it's not so much important whether a type system is static or
>> not, but it's rather important whether it's good or not.
>
> Exception management is only marginally related to the type system.
You're wrong. Java's notion of checked exceptions _constitutes_ a type
system.
>> I think the fact that people cannot even agree which of the examples are
>> valid ones or not proves the point of the paper: Static type systems
>> don't guarantee anything.
>
> It could be that people have different definitions of static and
> dynamic type system.
Maybe. Which makes things even worse.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 1 Set, 00:36, Pascal Costanza <····@p-cos.net> wrote:
> Vend wrote:
> > On 31 Ago, 22:03, Pascal Costanza <····@p-cos.net> wrote:
> >> Vend wrote:
> >>> On 29 Ago, 18:06, Pascal Costanza <····@p-cos.net> wrote:
> >>>> Vend wrote:
> >>>>> It actually forces the programmer to think about the methods that can
> >>>>> be called on a class.
> >>>>> Sure, it's possible to implement a stub and then forget about it, but
> >>>>> I think that's far less likely than forgetting to implement a method
> >>>>> in a language that doesn't complain about it.
> >>>> That's what you think. I think something else.
> >>> Do you think that's easier to forget to implement a method after
> >>> writing a stub for it rather than after writing nothing about it?
> >> In a dynamically typed language, you get runtime exception for a missing
> >> method/function as soon as there is an attempt to invoke it at runtime,
> >> not sooner, not later.
>
> > Which can happen on the production system.
>
> ...unless you have a fairly complete test suite, which you should have
> anyway.
Which is no excuse for not catching errors at compile-time when
possible.
> >> As soon as you get that exception, you know that
> >> there is something that still needs to be implemented. You can even do
> >> this at that stage, when the default exception handler is waiting for
> >> interactive resolution. As soon as the method / function is defined, you
> >> can just continue execution from the place where the exception occurred.
>
> > I suppose one should try to prevent the software from failing as much
> > as it's possible rather than waiting it to fail before fixing it.
>
> That depends on the situation:http://www.paulgraham.com/lwba.html
He says that he uses the REPL to quickly debug his programs, and that
he develops by adding features incrementally.
This is different than waiting the application to fail before fixing
it.
> (That's a major problem with you static thinkers, you have a far too
> narrow view on what's possible, and the advantages and disadvantages of
> different possible approaches.)
I don't think he mentions any advantage of Lisp type dynamicity.
> But be that as it may, static type systems don't really help here
> anyway. Static type systems catch static type errors. Whether that has
> _anything_ to do with actual failures or not depends on a lot of factors
> unrelated to the type system.
Is it possible for a static type error not to be a failure?
I suppose one could construct examples like:
int x;
if (neverTrue()) {
x = "Hello";
}
where a static type error wouldn't cause any failure if left
unchecked, but I don't see any reason somebody would have to compile
such program.
> >> If you are forced to implement a stub by the static type system, it's
> >> likely that you get the stub wrong (as my paper shows), and the
> >> situation will be much worse.
>
> > There are always ways to get things wrong, but at least when you
> > implement a stub you have to think about that method.
> > If the method is just in the documentation there are higher chances of
> > forgetting about it, not to mention incomplete or obsolete
> > documentations.
>
> Why are you continuously ignoring the fact that the _right_ solution for
> a method stub is what dynamically typed languages provide anyway.
>
> Why do you insist on annoying programmers (aka "force them to think")?
So that they get the feature (the run-time exception) only if they ask
for it, rather than getting it when they don't need it and it's a
potential cause of failure.
> > Moreover, you can always insert "TODO" comments or, in languages which
> > support them, assertions or marcos in your stubs to allow an automatic
> > check to catch all the non-implemented stubs.
>
> You can probably also drill a hole in your knee and pour milk through it.
>
> In a good Lisp IDE, it's a piece of cake to get an overview of all the
> functions that are called but aren't implemented.
I don't think this can be be done completely, since in the general
case the IDE or the compiler can't prove whether the program will call
a given function with an argument of a given type.
You get a kind of static type checking implemented in the IDE on a
best effort basis while it's implemented precisely in the compiler of
a static typed language.
> So why should I be
> bothered doing all that crap?
>
> > The default behavior of dynamically typed languages is, in this case
> > and in general, to fail as late as possible, which can be too late.
>
> No, it fails at exactly the right point in time. Incorrect stubs, forced
> by stupid static type systems, will make the code fail later than necessary.
>
> >> You cannot force programmers to do anything. Programming languages
> >> should support programmers, not stand in their way. That's what I think.
>
> > Ok. We seem to have different concepts of standing in the way.
>
> True.
>
> >> The errors static thinkers assume to pop all the time in dynamic
> >> languages don't exist in practice, at least when programmers use those
> >> languages to who the corresponding programming style fits well. That's
> >> another ("subjectively hard") fact. Better deal with it.
>
> > While it's an objectively hard fact that such errors don't exist in
> > static typed languages, nor in theory neither in practice.
> > So what's the benefit of a dynamical type system?
>
> Two answers: The errors static type systems and dynamic type systems
> catch overlap, but are not the same.
Can you provide an example please?
> The benefit of a dynamic type system is to ensure that operations that
> are not defined for certain kinds of data are not blindly executed on
> those data, but throw corresponding exceptions. (What did you think?)
That's type safety, which is mostly orthogonal to type-dynamicity.
Haskell is static typed and type-safe.
Java is mostly static typed and type-safe.
C and C++ are mostly statc typed and type-unsafe.
Lisps and their derivatives (Python, Ruby, etc.) are dynamic typed and
type-safe, although some Lisp implementations allow you to turn off
run-time type checks, making the language dynamic typed and type-
unsafe.
> >>>>> (Anyway, you are right that the stub generated by Eclipse is bad).
> >>>> ...and the static type system is happy after what Eclipse generated. So
> >>>> the combination of a static type system and a development environment
> >>>> lures programmers into thinking he's safe, and nobody forced anyone to
> >>>> think about anything.
> >>> Shame on Eclipse.
> >> No, this is not Eclipse's fault.
>
> > Yes, it is. Generating an empty stub seems to me the best way of doing
> > it.
> > Generating a stub that throws an exception (simulating the behavior of
> > a dynamical language) would also be acceptable.
> > But generating a stub that returns a default value is asking for bugs.
>
> ...but this is exactly what you get because of the underlying static
> type system!
>
> Hint: The Eclipse developers were "forced" to think about this because
> of the static type system. There you see what you get from being
> "forced" to think about something.
They thought the wrong solution. No language can ensure correctness.
> To repeat: You cannot force programmers to do anything.
>
> >> It's the fault of the overall eco
> >> system surrounding Java, including the fact that is has a relatively bad
> >> type system.
>
> > Sure, Java has many flaws and this has prompted the rise of IDEs that
> > attempt to compensate by generating large amounts of bug-prone
> > boilerplate code.
>
> We agree here.
>
> >>>>> The second issue, checked exceptions, is Java specific as far as I
> >>>>> know, and doesn't appear to be particularly related to static vs.
> >>>>> dynamic typing.
> >>>> A static type system classifies expressions according to one or more
> >>>> static types. Java's exception system provides a classification into
> >>>> whether an expression throws a checked exception or not. Hence, it's a
> >>>> static type system. (Including the fact that if the type checker cannot
> >>>> classify an expression into one of the two categories, it will reject
> >>>> the corresponding program.)
> >>> Yes, but the existence of checked exceptions is Java-specific, as far
> >>> as I know.
> >> As I said, it's not so much important whether a type system is static or
> >> not, but it's rather important whether it's good or not.
>
> > Exception management is only marginally related to the type system.
>
> You're wrong. Java's notion of checked exceptions _constitutes_ a type
> system.
Checked exception put contstraints on the control flow, not on the
values that variables can contain (except for the variables which
contain the objects which represent the exceptions themselves, of
course).
So I wouldn't consider them part of the type system.
> >> I think the fact that people cannot even agree which of the examples are
> >> valid ones or not proves the point of the paper: Static type systems
> >> don't guarantee anything.
>
> > It could be that people have different definitions of static and
> > dynamic type system.
>
> Maybe. Which makes things even worse.
>
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
Vend <······@virgilio.it> writes:
> On 1 Set, 00:36, Pascal Costanza <····@p-cos.net> wrote:
>> That depends on the situation:http://www.paulgraham.com/lwba.html
>
> He says that he uses the REPL to quickly debug his programs, and that
> he develops by adding features incrementally.
> This is different than waiting the application to fail before fixing
> it.
Not at all:
Start with some basic main:
C/USER[25]> (defun main ()
(loop
(display-menu)
(ecase (get-choice)
((q) (exit-from-main))
((f) (open-file)))))
MAIN
the run it:
C/USER[26]> (main)
*** - EVAL: undefined function DISPLAY-MENU
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead of (FDEFINITION 'DISPLAY-MENU).
RETRY :R2 Retry
STORE-VALUE :R3 You may input a new value for (FDEFINITION 'DISPLAY-MENU).
ABORT :R4 ABORT
C/Break 1 USER[27]> (defun display-menu () (dolist (a *menu*) (format t "~A) ~A~%" (first a) (second a))))
DISPLAY-MENU
C/Break 1 USER[27]> :r2
*** - EVAL: variable *MENU* has no value
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead of *MENU*.
STORE-VALUE :R2 You may input a new value for *MENU*.
ABORT :R3 ABORT
C/Break 1 USER[28]> (defparameter *menu* '((q "quit") (f "open a file")))
*MENU*
C/Break 1 USER[28]> :r1
Use instead of *MENU*: #.*menu*
Q) quit
F) open a file
*** - EVAL: undefined function GET-CHOICE
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead of (FDEFINITION 'GET-CHOICE).
RETRY :R2 Retry
STORE-VALUE :R3 You may input a new value for (FDEFINITION 'GET-CHOICE).
ABORT :R4 ABORT
C/Break 1 USER[29]> (defun get-choice () (read))
GET-CHOICE
C/Break 1 USER[29]> :r2
q
*** - EVAL: undefined function EXIT-FROM-MAIN
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead of (FDEFINITION 'EXIT-FROM-MAIN).
RETRY :R2 Retry
STORE-VALUE :R3 You may input a new value for (FDEFINITION 'EXIT-FROM-MAIN).
ABORT :R4 ABORT
C/Break 1 USER[30]> :r4
C/USER[31]> (defun main ()
(macrolet ((exit-from-main () (return-from main (values))))
(loop
(display-menu)
(ecase (get-choice)
((q) (exit-from-main))
((f) (open-file))))))
*** - RETURN-FROM: no block named MAIN is currently visible
The following restarts are available:
ABORT :R1 ABORT
C/Break 1 USER[32]> :a
C/USER[33]> (defun main ()
(macrolet ((exit-from-main () `(return-from main (values))))
(loop
(display-menu)
(ecase (get-choice)
((q) (exit-from-main))
((f) (open-file))))))
MAIN
and you already have something working:
C/USER[34]> (main)
Q) quit
F) open a file
q
C/USER[35]> (main)
Q) quit
F) open a file
f
*** - EVAL: undefined function OPEN-FILE
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead of (FDEFINITION 'OPEN-FILE).
RETRY :R2 Retry
STORE-VALUE :R3 You may input a new value for (FDEFINITION 'OPEN-FILE).
ABORT :R4 ABORT
C/Break 1 USER[36]>
and so on.
>> (That's a major problem with you static thinkers, you have a far too
>> narrow view on what's possible, and the advantages and disadvantages of
>> different possible approaches.)
>
> I don't think he mentions any advantage of Lisp type dynamicity.
But we do.
>> In a good Lisp IDE, it's a piece of cake to get an overview of all the
>> functions that are called but aren't implemented.
>
> I don't think this can be be done completely, since in the general
> case the IDE or the compiler can't prove whether the program will call
> a given function with an argument of a given type.
But that's exactly our point!
> You get a kind of static type checking implemented in the IDE on a
> best effort basis while it's implemented precisely in the compiler of
> a static typed language.
It cannot do anything more than what the IDE can do.
>> So why should I be
>> bothered doing all that crap?
> They thought the wrong solution. No language can ensure correctness.
So why even try statically, when this is deleterious to programmer flow?
>> To repeat: You cannot force programmers to do anything.
--
__Pascal Bourguignon__
Vend wrote:
> On 1 Set, 00:36, Pascal Costanza <····@p-cos.net> wrote:
>> Vend wrote:
>>> On 31 Ago, 22:03, Pascal Costanza <····@p-cos.net> wrote:
>>>> Vend wrote:
>>>>> On 29 Ago, 18:06, Pascal Costanza <····@p-cos.net> wrote:
>>>>>> Vend wrote:
>>>>>>> It actually forces the programmer to think about the methods that can
>>>>>>> be called on a class.
>>>>>>> Sure, it's possible to implement a stub and then forget about it, but
>>>>>>> I think that's far less likely than forgetting to implement a method
>>>>>>> in a language that doesn't complain about it.
>>>>>> That's what you think. I think something else.
>>>>> Do you think that's easier to forget to implement a method after
>>>>> writing a stub for it rather than after writing nothing about it?
>>>> In a dynamically typed language, you get runtime exception for a missing
>>>> method/function as soon as there is an attempt to invoke it at runtime,
>>>> not sooner, not later.
>>> Which can happen on the production system.
>> ...unless you have a fairly complete test suite, which you should have
>> anyway.
>
> Which is no excuse for not catching errors at compile-time when
> possible.
...unless there is a price to pay which some may consider too high.
>>>> As soon as you get that exception, you know that
>>>> there is something that still needs to be implemented. You can even do
>>>> this at that stage, when the default exception handler is waiting for
>>>> interactive resolution. As soon as the method / function is defined, you
>>>> can just continue execution from the place where the exception occurred.
>>> I suppose one should try to prevent the software from failing as much
>>> as it's possible rather than waiting it to fail before fixing it.
>> That depends on the situation:http://www.paulgraham.com/lwba.html
>
> He says that he uses the REPL to quickly debug his programs, and that
> he develops by adding features incrementally.
> This is different than waiting the application to fail before fixing
> it.
It's very similar.
>> (That's a major problem with you static thinkers, you have a far too
>> narrow view on what's possible, and the advantages and disadvantages of
>> different possible approaches.)
>
> I don't think he mentions any advantage of Lisp type dynamicity.
The kind of dynamic upgrades he describes aren't really possible with
statically typed languages.
>> But be that as it may, static type systems don't really help here
>> anyway. Static type systems catch static type errors. Whether that has
>> _anything_ to do with actual failures or not depends on a lot of factors
>> unrelated to the type system.
>
> Is it possible for a static type error not to be a failure?
Yes, absolutely.
class C { }
class D extends C {
void m() {System.out.println("foo");}
}
public class E {
public static void main(String[] args) {
C obj = new D();
obj.m();
}
}
This program would never fail given a reasonable dynamic type system
(say Smalltalk), but Java's static type checker will reject it.
This is not so unusual, and you have to come up with a couple of silly
workarounds to work against such restrictions. (Not in this simple case,
but in more involved cases.)
> I suppose one could construct examples like:
>
> int x;
> if (neverTrue()) {
> x = "Hello";
> }
>
> where a static type error wouldn't cause any failure if left
> unchecked, but I don't see any reason somebody would have to compile
> such program.
Yes, it's clear that your view on things is quite narrow.
>>>> If you are forced to implement a stub by the static type system, it's
>>>> likely that you get the stub wrong (as my paper shows), and the
>>>> situation will be much worse.
>>> There are always ways to get things wrong, but at least when you
>>> implement a stub you have to think about that method.
>>> If the method is just in the documentation there are higher chances of
>>> forgetting about it, not to mention incomplete or obsolete
>>> documentations.
>> Why are you continuously ignoring the fact that the _right_ solution for
>> a method stub is what dynamically typed languages provide anyway.
>>
>> Why do you insist on annoying programmers (aka "force them to think")?
>
> So that they get the feature (the run-time exception) only if they ask
> for it, rather than getting it when they don't need it and it's a
> potential cause of failure.
What if they have a different preference, or the requirements of the
system they have to implement _demand_ different defaults in this
regard? (like in Paul Graham's example, but there are more)
>>> Moreover, you can always insert "TODO" comments or, in languages which
>>> support them, assertions or marcos in your stubs to allow an automatic
>>> check to catch all the non-implemented stubs.
>> You can probably also drill a hole in your knee and pour milk through it.
>>
>> In a good Lisp IDE, it's a piece of cake to get an overview of all the
>> functions that are called but aren't implemented.
>
> I don't think this can be be done completely, since in the general
> case the IDE or the compiler can't prove whether the program will call
> a given function with an argument of a given type.
>
> You get a kind of static type checking implemented in the IDE on a
> best effort basis while it's implemented precisely in the compiler of
> a static typed language.
If there were a 1:1 correspondence between static errors and _actual_
failures, this would indeed be interesting. But there is no such
correspondence. That's the essential flaw in your reasoning.
>> Two answers: The errors static type systems and dynamic type systems
>> catch overlap, but are not the same.
>
> Can you provide an example please?
Sure. We actually need two examples, (a) one where an actual runtime
failure is not caught by a static type system, and (b) one where a
static type error is not an actual failure.
(a) Division by zero is not caught by any static type system I am aware of.
(b) See the Java example above: a static type error which doesn't
correspond to an actual failure.
Q.E.D.
(BTW, the fact that you will always have such examples, no matter what
your static type system looks like, is a direct consequence of Rice's
theorem.)
You will now respond that the intersection of static type errors and
actual runtime failures is sufficiently large to warrant the use of
static type errors, but what you fail to realize is that this is
guessing and that (a) there cannot be a mathematical proof that this is
indeed the case and that (b) there is no sufficient empirical data to
back this claim apart from (insufficient) anecdotal evidence.
I don't claim that supporters of dynamically typed languages can do
better here. We can also provide only anecdotal evidence (like Paul
Graham's case), and not much more. But what's important here is that we
are on equal levels. To repeat: We are all just guessing.
The fact that you can have a mathematical proof of type soundness for
(some) static type systems lures you into a false sense of security
because it gives you the illusion that you have a water-tight foolproof
system at hand. But you don't: The strong overlap between static type
errors and actual runtime failures is just an assumption, not more, not
less.
>> The benefit of a dynamic type system is to ensure that operations that
>> are not defined for certain kinds of data are not blindly executed on
>> those data, but throw corresponding exceptions. (What did you think?)
>
> That's type safety, which is mostly orthogonal to type-dynamicity.
Well, it's a benefit that's shared by static and dynamic type systems then.
An additional benefit of dynamic type systems, unlike what you get in
static type systems, is that you don't have to work around limitations
of a static type checker which would have to reject certain programs
without any actual runtime failures. You have to invest time and energy
into these workarounds, and for some people and/or under some
circumstances, this is basically just wasted effort.
This includes, but is not limited to, the fact that you can run
incomplete programs to better understand what they are doing during
development, which you typically cannot do so easily, or only with
strong limitations, in typical statically typed languages.
>>>>>>> (Anyway, you are right that the stub generated by Eclipse is bad).
>>>>>> ...and the static type system is happy after what Eclipse generated. So
>>>>>> the combination of a static type system and a development environment
>>>>>> lures programmers into thinking he's safe, and nobody forced anyone to
>>>>>> think about anything.
>>>>> Shame on Eclipse.
>>>> No, this is not Eclipse's fault.
>>> Yes, it is. Generating an empty stub seems to me the best way of doing
>>> it.
>>> Generating a stub that throws an exception (simulating the behavior of
>>> a dynamical language) would also be acceptable.
>>> But generating a stub that returns a default value is asking for bugs.
>> ...but this is exactly what you get because of the underlying static
>> type system!
>>
>> Hint: The Eclipse developers were "forced" to think about this because
>> of the static type system. There you see what you get from being
>> "forced" to think about something.
>
> They thought the wrong solution. No language can ensure correctness.
We're in heavy agreement here. Ergo, there is no use in forcing
programmers to do anything, because it's quite clear that no amount of
force can ensure correctness.
>>> Exception management is only marginally related to the type system.
>> You're wrong. Java's notion of checked exceptions _constitutes_ a type
>> system.
>
> Checked exception put contstraints on the control flow, not on the
> values that variables can contain (except for the variables which
> contain the objects which represent the exceptions themselves, of
> course).
> So I wouldn't consider them part of the type system.
Well, I can only repeat that you're wrong here.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Sep 3, 12:15 am, Pascal Costanza <····@p-cos.net> wrote:
> Vend wrote:
> > On 1 Set, 00:36, Pascal Costanza <····@p-cos.net> wrote:
> >> Vend wrote:
> >>> On 31 Ago, 22:03, Pascal Costanza <····@p-cos.net> wrote:
> >>>> Vend wrote:
> >>>>> On 29 Ago, 18:06, Pascal Costanza <····@p-cos.net> wrote:
> >>>>>> Vend wrote:
> >>>>>>> It actually forces the programmer to think about the methods that can
> >>>>>>> be called on a class.
> >>>>>>> Sure, it's possible to implement a stub and then forget about it, but
> >>>>>>> I think that's far less likely than forgetting to implement a method
> >>>>>>> in a language that doesn't complain about it.
> >>>>>> That's what you think. I think something else.
> >>>>> Do you think that's easier to forget to implement a method after
> >>>>> writing a stub for it rather than after writing nothing about it?
> >>>> In a dynamically typed language, you get runtime exception for a missing
> >>>> method/function as soon as there is an attempt to invoke it at runtime,
> >>>> not sooner, not later.
> >>> Which can happen on the production system.
> >> ...unless you have a fairly complete test suite, which you should have
> >> anyway.
>
> > Which is no excuse for not catching errors at compile-time when
> > possible.
>
> ...unless there is a price to pay which some may consider too high.
>
> >>>> As soon as you get that exception, you know that
> >>>> there is something that still needs to be implemented. You can even do
> >>>> this at that stage, when the default exception handler is waiting for
> >>>> interactive resolution. As soon as the method / function is defined, you
> >>>> can just continue execution from the place where the exception occurred.
> >>> I suppose one should try to prevent the software from failing as much
> >>> as it's possible rather than waiting it to fail before fixing it.
> >> That depends on the situation:http://www.paulgraham.com/lwba.html
>
> > He says that he uses the REPL to quickly debug his programs, and that
> > he develops by adding features incrementally.
> > This is different than waiting the application to fail before fixing
> > it.
>
> It's very similar.
>
> >> (That's a major problem with you static thinkers, you have a far too
> >> narrow view on what's possible, and the advantages and disadvantages of
> >> different possible approaches.)
>
> > I don't think he mentions any advantage of Lisp type dynamicity.
>
> The kind of dynamic upgrades he describes aren't really possible with
> statically typed languages.
>
> >> But be that as it may, static type systems don't really help here
> >> anyway. Static type systems catch static type errors. Whether that has
> >> _anything_ to do with actual failures or not depends on a lot of factors
> >> unrelated to the type system.
>
> > Is it possible for a static type error not to be a failure?
>
> Yes, absolutely.
>
> class C { }
>
> class D extends C {
> void m() {System.out.println("foo");}
>
> }
>
> public class E {
> public static void main(String[] args) {
> C obj = new D();
> obj.m();
> }
>
> }
>
> This program would never fail given a reasonable dynamic type system
> (say Smalltalk), but Java's static type checker will reject it.
>
> This is not so unusual, and you have to come up with a couple of silly
> workarounds to work against such restrictions. (Not in this simple case,
> but in more involved cases.)
>
> > I suppose one could construct examples like:
>
> > int x;
> > if (neverTrue()) {
> > x = "Hello";
> > }
>
> > where a static type error wouldn't cause any failure if left
> > unchecked, but I don't see any reason somebody would have to compile
> > such program.
>
> Yes, it's clear that your view on things is quite narrow.
>
>
>
> >>>> If you are forced to implement a stub by the static type system, it's
> >>>> likely that you get the stub wrong (as my paper shows), and the
> >>>> situation will be much worse.
> >>> There are always ways to get things wrong, but at least when you
> >>> implement a stub you have to think about that method.
> >>> If the method is just in the documentation there are higher chances of
> >>> forgetting about it, not to mention incomplete or obsolete
> >>> documentations.
> >> Why are you continuously ignoring the fact that the _right_ solution for
> >> a method stub is what dynamically typed languages provide anyway.
>
> >> Why do you insist on annoying programmers (aka "force them to think")?
>
> > So that they get the feature (the run-time exception) only if they ask
> > for it, rather than getting it when they don't need it and it's a
> > potential cause of failure.
>
> What if they have a different preference, or the requirements of the
> system they have to implement _demand_ different defaults in this
> regard? (like in Paul Graham's example, but there are more)
>
> >>> Moreover, you can always insert "TODO" comments or, in languages which
> >>> support them, assertions or marcos in your stubs to allow an automatic
> >>> check to catch all the non-implemented stubs.
> >> You can probably also drill a hole in your knee and pour milk through it.
>
> >> In a good Lisp IDE, it's a piece of cake to get an overview of all the
> >> functions that are called but aren't implemented.
>
> > I don't think this can be be done completely, since in the general
> > case the IDE or the compiler can't prove whether the program will call
> > a given function with an argument of a given type.
>
> > You get a kind of static type checking implemented in the IDE on a
> > best effort basis while it's implemented precisely in the compiler of
> > a static typed language.
>
> If there were a 1:1 correspondence between static errors and _actual_
> failures, this would indeed be interesting. But there is no such
> correspondence. That's the essential flaw in your reasoning.
>
> >> Two answers: The errors static type systems and dynamic type systems
> >> catch overlap, but are not the same.
>
> > Can you provide an example please?
>
> Sure. We actually need two examples, (a) one where an actual runtime
> failure is not caught by a static type system, and (b) one where a
> static type error is not an actual failure.
>
> (a) Division by zero is not caught by any static type system I am aware of.
Or (a)
let rec fact n =
match n with
0 -> 1
| n -> n * fatt (n - 1)
;;
where OCaml 3.10.0 exhibits very C-like behavior (the same type - pun
intended - of behavior that caused Ariane) :)
Cheers
--
Marco
From: Tobias C. Rittweiler
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <87r6829l6t.fsf@freebits.de>
Pascal Costanza <··@p-cos.net> writes:
> ...unless you have a fairly complete test suite, which you should have
> anyway.
A fairly complete test suite tends to take a fairly long time. A modern
static type system can hence be very valuable during refactoring. (OTOH,
static type errors can sometimes be cryptic, and in such a case, I'd
really like to just run the darn code and land in a debugger.)
-T.
On Sep 3, 1:34 am, "Tobias C. Rittweiler" <····@freebits.de.invalid>
wrote:
> Pascal Costanza <····@p-cos.net> writes:
> > ...unless you have a fairly complete test suite, which you should have
> > anyway.
>
> A fairly complete test suite tends to take a fairly long time.
FWIW, there is research on coverage metrics and coverage analyses for
test suites which help to optimize them, prune redundant tests, and
exposes areas which are not tested well.
If a test suite takes too long, it's perhaps time to check those out.
M/
Tobias C. Rittweiler wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> ...unless you have a fairly complete test suite, which you should have
>> anyway.
>
> A fairly complete test suite tends to take a fairly long time. A modern
> static type system can hence be very valuable during refactoring. (OTOH,
> static type errors can sometimes be cryptic, and in such a case, I'd
> really like to just run the darn code and land in a debugger.)
Yes, refactoring seems to be one of the cases where statically typed
languages have some advantages over dynamically typed languages.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Tobias C. Rittweiler wrote:
>> Pascal Costanza <··@p-cos.net> writes:
>>
>>> ...unless you have a fairly complete test suite, which you should have
>>> anyway.
>> A fairly complete test suite tends to take a fairly long time. A
>> modern
>> static type system can hence be very valuable during refactoring. (OTOH,
>> static type errors can sometimes be cryptic, and in such a case, I'd
>> really like to just run the darn code and land in a debugger.)
>
> Yes, refactoring seems to be one of the cases where statically typed
> languages have some advantages over dynamically typed languages.
I'm not so sure.
To me, it looks like it's easier to refactor lisp code than C++ code.
C++ code feels like dry concrete, while lisp code always feels like
smooth clay.
Objective-C (which is almost as dynamic as Smalltalk, for its OO part)
also is easy to refactor.
What about Haskell?
--
__Pascal Bourguignon__
From: Tobias C. Rittweiler
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <87ej41sgm6.fsf@freebits.de>
···@informatimago.com (Pascal J. Bourguignon) writes:
> What about Haskell?
Refactoring makes fun---as long as you can relate the type errors to
your code, that is. Debugging on the other hand...
-T.
In article <··············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Tobias C. Rittweiler wrote:
> > Pascal Costanza <··@p-cos.net> writes:
> >
> >> ...unless you have a fairly complete test suite, which you should have
> >> anyway.
> >
> > A fairly complete test suite tends to take a fairly long time. A modern
> > static type system can hence be very valuable during refactoring. (OTOH,
> > static type errors can sometimes be cryptic, and in such a case, I'd
> > really like to just run the darn code and land in a debugger.)
>
> Yes, refactoring seems to be one of the cases where statically typed
> languages have some advantages over dynamically typed languages.
Well, Common Lisp adds to that the textual code in general is
not really parseable (unless one uses a full Common Lisp
will its reader - even then it can be difficult). So many textual
transformations are approximations or possibly wrong.
There are some 'primitive' transformations that can be
done at editor level. But if the code uses for example
an infix read macro, then parsing that is kind of
hopeless, unless the read macro itself is used to read
that expression - getting back the original syntactic
form after transformation is then hopeless, too.
The whole macro and read macro facilities makes refactoring
very very tough. Genera has some machinery for
transforming Lisp textual source code. I have also seen translators
from one Lisp dialect to another Lisp dialect - the
results are less than perfect.
There is a price to pay for all the power of code
readers (read macros) and code transformation
(macros).
OTOH, there is less need for refactoring. If a lot
of code gets generated (by macros), then one often just
needs to change the code generator and the refactoring
is done. Though, overuse of code generators can also make
the programming process worse.
Some 'refactoring' is built directly into the language.
Methods are defined outside of classes and the effective
method is (re-) computed at runtime. There is a descriptive
definition of the methods purpose (:around, ..., primary,
or self defined, ...) and depending on the available
methods (and the method combination) the effective method
will be generated. One changes the class hierarchy at runtime
-> the effective code will be recomputed, at runtime.
>
> Pascal
--
http://lispm.dyndns.org/
Rainer Joswig wrote:
> Some 'refactoring' is built directly into the language.
> Methods are defined outside of classes and the effective
> method is (re-) computed at runtime. There is a descriptive
> definition of the methods purpose (:around, ..., primary,
> or self defined, ...) and depending on the available
> methods (and the method combination) the effective method
> will be generated. One changes the class hierarchy at runtime
> -> the effective code will be recomputed, at runtime.
True, good point. I think keyword arguments also deserve a mention here,
because they allow to change function signatures without having to
update all call sites.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Vend wrote:
> > On 31 Ago, 22:03, Pascal Costanza <····@p-cos.net> wrote:
> >> Vend wrote:
> >>> On 29 Ago, 18:06, Pascal Costanza <····@p-cos.net> wrote:
> >>>> Vend wrote:
> >>>>> It actually forces the programmer to think about the methods that can
> >>>>> be called on a class.
> >>>>> Sure, it's possible to implement a stub and then forget about it, but
> >>>>> I think that's far less likely than forgetting to implement a method
> >>>>> in a language that doesn't complain about it.
> >>>> That's what you think. I think something else.
> >>> Do you think that's easier to forget to implement a method after
> >>> writing a stub for it rather than after writing nothing about it?
> >> In a dynamically typed language, you get runtime exception for a missing
> >> method/function as soon as there is an attempt to invoke it at runtime,
> >> not sooner, not later.
> >
> > Which can happen on the production system.
>
> ...unless you have a fairly complete test suite, which you should have
> anyway.
>
> >> As soon as you get that exception, you know that
> >> there is something that still needs to be implemented. You can even do
> >> this at that stage, when the default exception handler is waiting for
> >> interactive resolution. As soon as the method / function is defined, you
> >> can just continue execution from the place where the exception occurred.
> >
> > I suppose one should try to prevent the software from failing as much
> > as it's possible rather than waiting it to fail before fixing it.
>
> That depends on the situation: http://www.paulgraham.com/lwba.html
> (That's a major problem with you static thinkers, you have a far too
> narrow view on what's possible, and the advantages and disadvantages of
> different possible approaches.)
>
> But be that as it may, static type systems don't really help here
> anyway. Static type systems catch static type errors. Whether that has
> _anything_ to do with actual failures or not depends on a lot of factors
> unrelated to the type system.
>
> >> If you are forced to implement a stub by the static type system, it's
> >> likely that you get the stub wrong (as my paper shows), and the
> >> situation will be much worse.
> >
> > There are always ways to get things wrong, but at least when you
> > implement a stub you have to think about that method.
> > If the method is just in the documentation there are higher chances of
> > forgetting about it, not to mention incomplete or obsolete
> > documentations.
>
> Why are you continuously ignoring the fact that the _right_ solution for
> a method stub is what dynamically typed languages provide anyway.
>
> Why do you insist on annoying programmers (aka "force them to think")?
>
> > Moreover, you can always insert "TODO" comments or, in languages which
> > support them, assertions or marcos in your stubs to allow an automatic
> > check to catch all the non-implemented stubs.
>
> You can probably also drill a hole in your knee and pour milk through it.
>
> In a good Lisp IDE, it's a piece of cake to get an overview of all the
> functions that are called but aren't implemented. So why should I be
> bothered doing all that crap?
>
> > The default behavior of dynamically typed languages is, in this case
> > and in general, to fail as late as possible, which can be too late.
>
> No, it fails at exactly the right point in time. Incorrect stubs, forced
> by stupid static type systems, will make the code fail later than necessary.
>
> >> You cannot force programmers to do anything. Programming languages
> >> should support programmers, not stand in their way. That's what I think.
> >
> > Ok. We seem to have different concepts of standing in the way.
>
> True.
>
> >> The errors static thinkers assume to pop all the time in dynamic
> >> languages don't exist in practice, at least when programmers use those
> >> languages to who the corresponding programming style fits well. That's
> >> another ("subjectively hard") fact. Better deal with it.
> >
> > While it's an objectively hard fact that such errors don't exist in
> > static typed languages, nor in theory neither in practice.
> > So what's the benefit of a dynamical type system?
>
> Two answers: The errors static type systems and dynamic type systems
> catch overlap, but are not the same.
>
> The benefit of a dynamic type system is to ensure that operations that
> are not defined for certain kinds of data are not blindly executed on
> those data, but throw corresponding exceptions. (What did you think?)
>
> >>>>> (Anyway, you are right that the stub generated by Eclipse is bad).
> >>>> ...and the static type system is happy after what Eclipse generated. So
> >>>> the combination of a static type system and a development environment
> >>>> lures programmers into thinking he's safe, and nobody forced anyone to
> >>>> think about anything.
> >>> Shame on Eclipse.
> >> No, this is not Eclipse's fault.
> >
> > Yes, it is. Generating an empty stub seems to me the best way of doing
> > it.
> > Generating a stub that throws an exception (simulating the behavior of
> > a dynamical language) would also be acceptable.
> > But generating a stub that returns a default value is asking for bugs.
>
> ...but this is exactly what you get because of the underlying static
> type system!
>
> Hint: The Eclipse developers were "forced" to think about this because
> of the static type system. There you see what you get from being
> "forced" to think about something.
>
> To repeat: You cannot force programmers to do anything.
> >> I think the fact that people cannot even agree which of the examples are
> >> valid ones or not proves the point of the paper: Static type systems
> >> don't guarantee anything.
> >
> > It could be that people have different definitions of static and
> > dynamic type system.
>
> Maybe. Which makes things even worse.
>
>
> Pascal
Bravo Pascal I can't agree more. I would include it in my collection
of quotes.
>
> --
> My website: http://p-cos.net
> Common Lisp Document Repository: http://cdr.eurolisp.org
> Closer to MOP & ContextL: http://common-lisp.net/project/closer/
> Pascal Costanza wrote:
> > Vend wrote:
> > The default behavior of dynamically typed languages is, in this case
> > and in general, to fail as late as possible, which can be too late.
> No, it fails at exactly the right point in time.
A Wizard is never late. Nor is he early, he arrives precisely when he
means to.
slobodan
Vend <······@virgilio.it> writes:
> On 31 Ago, 22:03, Pascal Costanza <····@p-cos.net> wrote:
> > The errors static thinkers assume to pop all the time in dynamic
> > languages don't exist in practice, at least when programmers use those
> > languages to who the corresponding programming style fits well. That's
> > another ("subjectively hard") fact. Better deal with it.
>
> While it's an objectively hard fact that such errors don't exist in
> static typed languages, nor in theory neither in practice.
> So what's the benefit of a dynamical type system?
Well, I thought that you posted an excellent example, through the use of
down-casting, of how exactly such errors crop up in practice in
(largely) statically typed programming languages.
As for the benefits of a dynamic type system, here are some off the top
of my head:
1. Think about why downcasting or casting at all is allowed in
languages. If such dynamic type manipulations weren't useful, why
would so many languages have them?
2. It makes it much easier to work with heterogeneous collections of
objects.
3. It makes it much easier to operate on the meta-level of programming,
since the type information is manifest.
4. It is easier to extend the code without having to re-write large
sections of it just to satisfy the type restrictions imposed by the
compiler.
--
Thomas A. Russ, USC/Information Sciences Institute
Pascal Costanza wrote:
> In a dynamically typed language, you get runtime exception for a missing
> method/function as soon as there is an attempt to invoke it at runtime,
> not sooner, not later.
Good compilers, like LispWorks, gives a warning at compile time, if you try
to call a function which is undefined.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> Pascal Costanza wrote:
>
>> In a dynamically typed language, you get runtime exception for a missing
>> method/function as soon as there is an attempt to invoke it at runtime,
>> not sooner, not later.
>
> Good compilers, like LispWorks, gives a warning at compile time, if you try
> to call a function which is undefined.
True, forgot to mention that. (But they don't disallow programmers to
execute the code in such a case...)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <································@40tude.net>,
Frank Buss <··@frank-buss.de> wrote:
> Pascal Costanza wrote:
>
> > In a dynamically typed language, you get runtime exception for a missing
> > method/function as soon as there is an attempt to invoke it at runtime,
> > not sooner, not later.
>
> Good compilers, like LispWorks, gives a warning at compile time, if you try
> to call a function which is undefined.
It is actually a bit more what a Lisp compiler does (or should do):
it will give a warning if there is some function referenced
in the source, if the function is not defined and not
in the sources. When a compiler compiles a file, for the Lisp
system the functions in the file and referenced in the file
may still be undefined after or
during compilation. So the compiler should only warn
if the compiler does not see a function definition in
the whole compilation unit (and it has no definition
at compile time).
--
http://lispm.dyndns.org/
P� Thu, 28 Aug 2008 17:33:25 +0200, skrev Vend <······@virgilio.it>:
>>
>> When you write in lisp:
>>
>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>>
But why would you write it like that?
I would write
(defun fact (n)
(check-type n (integer 0 *))
(when (< n 2) (return-from fact 1))
(iter (for i from 2 to n) (multiplying n)))
The function you wrote is underspesified.
It assumes that x can be a negative number for instance and thus does not
comply with the mathematical definition.
Also it is inefficient.
(I assume you ment (- x 1). 1- only works for integers and would signal a
error.)
For that matter you could write
float fact (float n)
{
return n * fact(n - 1);
}
--------------
John Thingstad
"John Thingstad" <·······@online.no> writes:
> P� Thu, 28 Aug 2008 17:33:25 +0200, skrev Vend <······@virgilio.it>:
>
>>>
>>> When you write in lisp:
>>>
>>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>>>
>
> But why would you write it like that?
> I would write
>
> (defun fact (n)
> (check-type n (integer 0 *))
> (when (< n 2) (return-from fact 1))
> (iter (for i from 2 to n) (multiplying n)))
>
> The function you wrote is underspesified.
Yes, it was my point, it doesn't need any overspecification of the
types, and avoiding such overspecification, it is quite a generic
function, something you would have to write with much heavier
machinery in languages such as C++.
> It assumes that x can be a negative number for instance and thus does
> not comply with the mathematical definition.
It's just an example, and doesn't mean to match any mathematical
definition.
By the same token the apparent use of CL operators such as + and <= is
just a basic example, which restricts the genericity since users
cannot redefine CL operators, but which give already enough genericity
(amongst the different kind of numbers) that I hoped my point would be
clear.
A similar function using only user defined operators would be even
more generic, since all these user defined operators could be
_redefined_ or defined as generic functions in the first place.
I have not mentionned in which package, and with which used package
this fact form was read in, it could as well be in a package where all
the operators are shadowed from the CL package, and are actually user
defined generic functions.
Perhaps this could be qualified of meta-genericity; you could try to
process:
> float fact (float n)
> {
> return n * fact(n - 1);
> }
with any kind of #define macros, you would never be able to apply that
to polynoms, to colors or to chords. But it would be trivial with
the lisp form..
> Also it is inefficient.
Granted, but this is not what is discussed here.
> (I assume you ment (- x 1). 1- only works for integers and would
> signal a error.)
(mapcar '1- '( 3 3/2 3.0 #C(3 3))) --> (2 1/2 2.0 #C(2 3))
> For that matter you could write
>
> float fact (float n)
> {
> return n * fact(n - 1);
> }
and again, the _meaning_ of that C fact, is EXTREMELY different from
the _meaning_ of this Lisp fact:
(defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You question the worthiness of my code? I should kill you where you
stand!"
On Aug 19, 1:31 pm, ssecorp <············@gmail.com> wrote:
> What are you LISPers opinion of Haskell?
>
I recently did some Haskell (and Erlang) hacking, too. Although I like
both languages and they both have their niches, the biggest feature
that takes me back to Common Lisp every time is macros. Whenever I use
another language (does not matter what it is), deep down I wish the
language had macros like Common Lisp.
--
Ralph
On Aug 19, 10:11 pm, Ralph Allan Rice <··········@gmail.com> wrote:
> On Aug 19, 1:31 pm, ssecorp <············@gmail.com> wrote:
>
> > What are you LISPers opinion of Haskell?
>
> I recently did some Haskell (and Erlang) hacking, too. Although I like
> both languages and they both have their niches, the biggest feature
> that takes me back to Common Lisp every time is macros. Whenever I use
> another language (does not matter what it is), deep down I wish the
> language had macros like Common Lisp.
You could try Liskell: http://liskell.org/
I haven't tried it, but it looks interesting.
-- Scott
On Aug 20, 2:55 am, Scott Burson <········@gmail.com> wrote:
> You could try Liskell:http://liskell.org/
>
> I haven't tried it, but it looks interesting.
Whoa! Looks mighty fine to me! :D
http://liskell.org/fifteen-minute-tour
The syntax and semantics look like a nice mix of Scheme and Haskell.
I the ease of defining ADTs:
(defdata Point3DType
(Point3D Rational Rational Rational))
and pattern matching on function definition without destructuring-bind
or other verbose macro workaround:
(define (distance3D (Point3D x y z))
(sqrt (+ (^ x 2)
(+ (^ y 2) (^ z 2)))))
or function definitions in let with the same syntax sugar as in define
(no lambda):
(define (scalar-multiply s point)
(let (((Point3D x y z) point)
((p x) (* s x)))
(Point3D (p x) (p y) (p z))))
Perhaps it also comes full with lazy semantics? A project to watch
closely.
Who knows, perhaps it attracts even more interest than Haskell or Lisp
alone... now Arc has some tough competition! :P
On Aug 20, 1:43 pm, namekuseijin <············@gmail.com> wrote:
> On Aug 20, 2:55 am, Scott Burson <········@gmail.com> wrote:
>
> > You could try Liskell:http://liskell.org/
>
> > I haven't tried it, but it looks interesting.
>
> Whoa! Looks mighty fine to me! :D
>
> http://liskell.org/fifteen-minute-tour
>
> The syntax and semantics look like a nice mix of Scheme and Haskell.
> I the ease of defining ADTs:
>
> (defdata Point3DType
> (Point3D Rational Rational Rational))
>
> and pattern matching on function definition without destructuring-bind
> or other verbose macro workaround:
> (define (distance3D (Point3D x y z))
> (sqrt (+ (^ x 2)
> (+ (^ y 2) (^ z 2)))))
>
> or function definitions in let with the same syntax sugar as in define
> (no lambda):
> (define (scalar-multiply s point)
> (let (((Point3D x y z) point)
> ((p x) (* s x)))
> (Point3D (p x) (p y) (p z))))
>
> Perhaps it also comes full with lazy semantics? A project to watch
> closely.
You mean CLAZY? (Shameless plug: common-lisp.net/project/clazy). Not
that the hack is particularly clever, but it shows you how you can do
these things *in* portable Common Lisp.
Cheers
--
Marco
On Aug 20, 10:43 am, namekuseijin <············@gmail.com> wrote:
> On Aug 20, 2:55 am, Scott Burson <········@gmail.com> wrote:
>
> > You could try Liskell:http://liskell.org/
>
> > I haven't tried it, but it looks interesting.
>
> Whoa! Looks mighty fine to me! :D
>
> http://liskell.org/fifteen-minute-tour
>
> The syntax and semantics look like a nice mix of Scheme and Haskell.
> I the ease of defining ADTs:
>
> (defdata Point3DType
> (Point3D Rational Rational Rational))
>
> and pattern matching on function definition without destructuring-bind
> or other verbose macro workaround:
> (define (distance3D (Point3D x y z))
> (sqrt (+ (^ x 2)
> (+ (^ y 2) (^ z 2)))))
>
> or function definitions in let with the same syntax sugar as in define
> (no lambda):
> (define (scalar-multiply s point)
> (let (((Point3D x y z) point)
> ((p x) (* s x)))
> (Point3D (p x) (p y) (p z))))
>
> Perhaps it also comes full with lazy semantics? A project to watch
> closely.
>
> Who knows, perhaps it attracts even more interest than Haskell or Lisp
> alone... now Arc has some tough competition! :P
Arc is one of the despicable worthless shit there is.
Arc is the type of shit that when some person becomes famous for his
achivement in some area, who began to sell all sort of shit and
visions just because he can, and people will buy it.
So, please don't mention arc. Mention Qi, NewLisp, Liskell instead.
These are far more effort, dedication, earnestness, as well much more
technical merits or social benefits, than dignitary's fame selling
shits.
Qi is great because it adds advanced functional features to lisp yet
remain compatible with Common Lisp.
Liskell is worth looking into because it is a experiment exploiting
the the nested syntax, meanwhile brings in the semantics of a well
developed functional lang.
Qi and Liskell are very welcome, and non-trivial, addition to lisp
communities that can help lispers get new insights.
NewLisp is great because it is a earnest effort in modernizing lisp,
breaking away the ~3 decades of traditions and thought patterns that
are rooted in Common Lisp and Scheme. NewLisp's community is entirely
distinct from CommonLisp/SchemeLisp, attracting much newer generation
of hobbist and non-professional programers. NewLisp isn't one of the
fashionable new lang created for the sake of new lang. It has been
around more than a decade.
http://en.wikipedia.org/wiki/NewLisp
http://en.wikipedia.org/wiki/Qi_(programming_language)
I support Qi, NewLisp, Liskell. Please mention these in your
socializing chats.
Paul Graham, the author of Arc, of course have every right to create
his lang just like anyone else, and even for the sole purpose of
selling his name just because he can. And perhaps due to his past
contribution in the lisp community, Arc might be successful and
getting a lot users purely due to Paul's fame. However, please
consider the real value of a new lang, from technical to social, and
not as opposed to who's more famous. (for example, technical
considerations can be such as what new functionality it brings, such
as Qi, or what insight it might bring, such as Liskell. Social
consideration can be such as whether it bring the ideas of lisp to
entirely new segments of society, such as NewLisp.)
See also:
What Languages to Hate
http://xahlee.org/UnixResource_dir/writ/language_to_hate.html
plain text version follows:
----------------------------------
What Languages to Hate
Xah Lee, 2002-07-18
Dear lisp comrades and other concerned parties,
First, all languages have equal rights. Do not belittle other
languages just because YOUR favorite language is a bit better in this
aspect or that. Different people have different ideas and manners of
perception. Ideas compete and thrive in all unexpected fashions.
Societies improve, inventions progress. Lisp may be a first in this or
that, or faster or flexibler, or higher level than other languages old
and new, but then there are other languages the like of Mathematica &
Haskell & Dylan et al which ridicule lisps in the same way lisp
ridicule other languages.
Just because YOU are used to more functional programing or love lots
of parenthesis doesn't mean they are the only and best concepts. The
so-called Object Oriented programing of Java fame, or the visual
programing of Visual Basic fame, or the logic programing of Prolog
fame, or the format-stable syntax of Python fame, or the “one line of
Mathematica equals ten to one thousand lines of lisp” of _A New Kind
Of Science_ fame... all are parts of healthy competing concepts,
paradigms, or directions of growth.
The way some of you deride other languages is like sneering
heterogeneousness. If unchecked, soon you'll only have your sister to
marry to. Cute, but you do not want incest to become the only sex.
Next time your superiority complex makes you sneer at non-lisp or
newfangled languages, remember this. It is diversity of ideas, that
drives the welfare of progress.
Now, there is one judgmental criterion, that if a language or computer
technology fits it, then we not only should castigate at their
missionaries, but persecute and harass the language to the harshest
death. That is: utter sloppiness, irresponsibility, and lies. These
things are often borne out of some student's homework or moron's dirty-
work, harbored by “free” and wanton lies and personal fame, amassed
thru ignorance.
Of my short but diligent industrial unix computing experience since
1998, i have identified the following targets:
* C (and consequences like csh, C++)
* vi
* Perl
* MySQL
* unix, unixism, and things grown out of unix. (languages,
protocols, philosophies, expectations, movements)
In our software industry, i like to define criminals as those who
cause inordinate harm to society, not necessarily directly. Of the
above things, some of their authors are not such criminals or are
forgivable. While others, are hypocritical fantastic liers selfish to
the core. When dealing with these self-promoting jolly lying humble
humorous priests and their insidious superficially-harmless speeches,
there should be no benefit of doubt. Tell them directly to stop their
vicious lies. Do a face-off.
As to their brain-washed followers for example the not-yet-hard-core
unix, C, or Perl coders rampant in industry, try to snap them out of
it. This you do by loudly snapping fingers in front of their face,
making it sound like a ear piercing bang. Explain to them the utter
stupidity of the things they are using, and the harm to their brain.
IMPORTANT: _teach_, not _debate_ or _discuss_ or falling back into
your philosophical deliberating indecisiveness. I've seen enough
criticisms among learned programers or academicians on these, so i
know you know what i'm talking about. When you see a unixer
brainwashed beyond saving, kick him out of the door. He has became a
zombie who cannot be helped.
There are other languages or technology, by itself technically are
perhaps mediocre but at least is not a egregious irresponsible hack,
therefore does not deserve scorn, but sometimes it comes with
overwhelming popular outrageous lies (euphemized as hype). Java is a
example. For this reason, it is equally deserving the harshest
treatment. Any loud proponents of such should be immediately slapped
in the mouth and kicked in the ass in no ambiguous ways.
Summary: all languages have equal rights. However, those utterly
SLOPPY and IRRESPONSIBLE HACKS with promoter's LIES should be severely
punished. It is these, that cause computing industry inordinate harm.
Meanwhile, it is wrong to haughtily criticize other languages just
because they are not your cup of tea. Now, please remember this and go
do society good.
Xah
∑ http://xahlee.org/
☄
On Aug 20, 3:47 pm, ·······@gmail.com" <······@gmail.com> wrote:
> On Aug 20, 10:43 am, namekuseijin <············@gmail.com> wrote:
> > Who knows, perhaps it attracts even more interest than Haskell or Lisp
> > alone... now Arc has some tough competition! :P
>
> Arc is one of the despicable worthless shit there is.
Good that my little sarcasm prompted such inspired response from
you. ;)
······@gmail.com wrote:
> Arc is one of the despicable worthless shit there is.
>
> Arc is the type of shit that when some person becomes famous for his
> achivement in some area, who began to sell all sort of shit and
> visions just because he can, and people will buy it.
That might be true, but I'd love it if you expounded on why you believe
that? I don't have a lot of lisp experience, so I need someone to
highlight facts about why Arc is bad comparatively.
Thanks.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
Daniel Pitts wrote:
> ······@gmail.com wrote:
>
>> Arc is one of the despicable worthless shit there is.
>>
>> Arc is the type of shit that when some person becomes famous for his
>> achivement in some area, who began to sell all sort of shit and
>> visions just because he can, and people will buy it.
>
> That might be true, but I'd love it if you expounded on why you believe
> that? I don't have a lot of lisp experience, so I need someone to
> highlight facts about why Arc is bad comparatively.
PG bet the ranch on terser code at all costs, including all sorts of
whacky syntax that is so whacky bits of it conflict and cannot be used
in combination. It was starting to look like Python when I left town.
And of course the single namespace is a disaster. Oh, and the absence of
an OO package.
kt
On 2008-08-24, Daniel Pitts wrote:
> ······@gmail.com wrote:
> > Arc is one of the despicable worthless shit there is.
>
> > Arc is the type of shit that when some person becomes famous for his
> > achivement in some area, who began to sell all sort of shit and
> > visions just because he can, and people will buy it.
>
> That might be true, but I'd love it if you expounded on why you believe
> that? I don't have a lot of lisp experience, so I need someone to
> highlight facts about why Arc is bad comparatively.
i haven't actually used arc. My opinion of it is based on reading Paul
Graham's essays about his idea of some “100 year language” and
subsequent lisper's discussions on it this year here (most are highly
critical). Also, Wikipedia info gives some insight too:
http://en.wikipedia.org/wiki/Arc_(programming_language)
Paul's essay:
“The Hundred-Year Language”
http://www.paulgraham.com/hundred.html
I consider one of the most wortheless essay. Worthless in the same
sense Larry Wall would have opinions on computer languages...
to fully detail will take several hours writing perhaps 2 thousands
words essay....
ok, perhaps a quick typing as summary of my impressions... but i know
all sort of flame will come.
Paul has some sort of infatuation with the concept of “hackers” (and
his languages is such that these “hacker” will like). I think this is
a fundamental problem in his vision.
If we look closely at the concept of “hacker”, from sociology's point
of view, there are all sort of problems rendering the term or notion
almost useless. In short, i don't think there is a meaningful class of
computer programer he calle “hackers” that one could say a computer
language is for them.
for example, hacker can be defined as knowledgeable programers, or
those exceptionally good at programing among professional programers,
or those who delights in technical details and their exploitation, or
those who are programers who tends to be extremely practical and
produce lots of useful codes, or those who's coding method heavily
relies on trial and error and less on formal methods or systems, or
perhas some element of all of the above. I don't mean to pick bones on
definitions, but i just don't see any sensible meaning in his frequent
use of the term in the context of designing a language.
put in another way... let's think about what langs are his “hackers”
like? would it be lisp?? perl?? or something such as Haskell? As you
know, these lang are quite different in their nature. However, it's
quite difficult to say which is the one hackers prefers. In some
sense, it's probably perl. But in another sense, it's lisp, since lisp
being unusual and has many qualities such as it's “symbols” and
“macros” concepts that allows it to be much more flexible at computing
tasks. But then, it could also be haskell. Certainly, lots of real
computer scientists with higher mathematical knowledge prefers it and
consider themselves real hackers in the classic sense of MIT's lambda
knight and ulimate lambda etc.
looking into detail on some of his idea about Arc's tech detail ... i
find them the most worthless.
so, yeah, in summary, i see arc as almost completely meritless, and as
a celebrity's intentional or unintentional effort to peddle himself.
Note, i find some of Paul's essays very insightful or i agree with,
such as one that talk about some psychology of nerds and highschool
bullies, and his opinion on OOP ...
----------------------------
here's some of my personal opinion on language design.
I think the criterions for “best” or “100-year” language is rather
very simple.
• it is easy to use. In the sense the masses can use it, not requiring
some advanced knowledge in math or computer science or practical
esoterica like unix bag.
• it is high level. This is related to easy to use. Exact, precise
definition of “High level” is hard to give, but typically it's those
so-called scripting langs, e.g. perl, python, php, tcl, javascript.
Typical features are typeless or dynamic typing, support many
constructs that do a lot things such as list processing, regex, etc.
• it has huge number of libraries. This can be part of the lang as
considered in java “API” or perl's regex or mathematica's math
functions, or can be bundled as many perl and python's libs, or as
external archive such as perl's cpan. The bottom line is, there are
large number of libraries that can be used right away, without having
to search for it, check reliability, etc.
the above are really down-to-earth, basic ideas, almost applicable to
anything else.
the tech geekers will you believe other things like garbage
collection, model of variable, paradigms like functional vs oop,
number systems, eval model like lazy or not lazy, closure or no, tail
recursion or no, has curry or no curry, does it have linder mayer
system or kzmolif type sytem, polymorphism yes?, and other moronic
things.
If you look at what lang becomes popular in the past 2 decades (thru
various website), basically those bubble up to top, are those with
good quality in hte above criterions. (e.g. perl, php, javascript,
visual basic.) C and Java are still at top, of course, because there
are other factors such as massive marketing done by Java, and C being
old and has been the standard low level system lang for decades.
(excuse me for typos and other errors... took me already a hour to
type and lots other newsgroup responses... will perhaps edit and put
on my website in the future...)
Xah
∑ http://xahlee.org/
☄
I believe he meant "timeless". Timeless might imply that it was very
important to provide a decent language for encoding algorithms,
and not so much to the initial size of libraries at year 0. Whether or
not the language is great for encoding algorithms (or any other
timeless qualities) is largely matter of opinion, as you have stated
previously.
>> there are all sort of problems rendering the term or notion almost useless.
This page may be of use, http://www.catb.org/~esr/faqs/hacker-howto.html,
although I'm guessing you've already read it and maybe even have an
essay for it.
In fact, I wouldn't go looking for a dictionary style definition,
since he used the word "hacker" to convey what he thought a hacker
was, so his article on "great hackers" would be very relevant:
http://www.paulgraham.com/gh.html
Those language qualities you listed do seem to be a good measure for a
good language though.
It seems to me that Arc has the first 2 qualities but not the third.
On Aug 24, 6:13 pm, Ali <·············@gmail.com> wrote:
> I believe he meant "timeless". Timeless might imply that it was very
> important to provide a decent language for encoding algorithms,
> and not so much to the initial size of libraries at year 0. Whether or
> not the language is great for encoding algorithms (or any other
> timeless qualities) is largely matter of opinion, as you have stated
> previously.
>
> >> there are all sort of problems rendering the term or notion almost useless.
>
> This page may be of use, http://www.catb.org/~esr/faqs/hacker-howto.html,
> although I'm guessing you've already read it and maybe even have an
> essay for it.
i red the jargon file, perhaps some 70% of it, in late 1990s online.
At the time, i appreciate it very much.
But today, i have came to realize that the maintainer Eric Raymond is
a selfish asshole.
For example, Wikipedia has this to say
http://en.wikipedia.org/wiki/Jargon_file
quote:
«Eric S. Raymond maintains the new File with assistance from Guy
Steele, and is the credited editor of the print version, The New
Hacker's Dictionary. Some of the changes made under his watch have
been controversial; early critics accused Raymond of unfairly changing
the file's focus to the Unix hacker culture instead of the older
hacker cultures where the Jargon File originated. Raymond has
responded by saying that the nature of hacking had changed and the
Jargon File should report on hacker culture, and not attempt to
enshrine it.[2] More recently, Raymond has been accused of adding
terms to the Jargon File that appear to have been used primarily by
himself, and of altering the file to reflect his own political views.
[3]»
Eric, one of the guy largely responsible for the Open Source movement
and plays a role a antagonistic to FSF. He also created a hacker logo
to sell himself. He's essay the Cathedral and Bazzar, which i read in
late 1990s, i consider stupid. You can often read his posts or
argument online in various places, and from those post you can see
he's often just a male ass.
Wikipedia has some illuminating summary of him:
http://en.wikipedia.org/wiki/Eric_S._Raymond
basically, a money hungry and selfish ass.
It used to also talk about how he supports the iraq war with some
racist undertone or some remarks he made about blacks ... i forgot the
detail but can be easily found in the article's history log.
He used to have a page on his website, not sure if it's still around,
about what he demands if people wants him to speak. Quite rude.
> In fact, I wouldn't go looking for a dictionary style definition,
> since he used the word "hacker" to convey what he thought a hacker
> was, so his article on "great hackers" would be very relevant:
> http://www.paulgraham.com/gh.html
Paul is a interesting guy. I mean, his lisp achievements and credits
is quite sufficient for me to find him intelligent and interesting.
However, his's essays related to hackers i just find quite
wortheless... not even sufficient enough for me to scan ... as
comparison, i'd rather read text books related to sociology or
psychology.
... many famous people write essays. Philosophers, renowed scientists
of all areas, successful businessman, famous award laureates ...
often, perhaps majority, of such essays are rather riding on fame and
worthless in quality when judged in the long term like decades or
centuries ...
> Those language qualities you listed do seem to be a good measure for a
> good language though.
> It seems to me that Arc has the first 2 qualities but not the third.
i wouldn't say arc is good at all with respect to ease of use or
power.
for ease of use... first of all it uses lisp syntax, and still has
cons business. These 2 immediately disqualifies it for the masses as
easy to use. Even if we take a step back, then there's Scheme lisp, so
in no way arc is easier to use than say Scheme 5.
for power... i doubt if it is in any sense more powerful than say
Scheme lisp or common lisp. In comparison to the profileration of
functional langs like Haskell, Ocaml/f# and perhaps also erlang, Q,
Oz, Mercury, Alice, Mathematica ... the power of arc would be a
laughing stock.
... adding the fact such controversies as using ascii as char set (as
opposed to unicode), using html table as web design, no name space
mechanism (all these i gathered as hearsay or on Wikipedia) ... arc to
me is totally without merit. (NewLisp and Qi, yay!)
see also...
Proliferation of Computing Languages
http://xahlee.org/UnixResource_dir/writ/new_langs.html
Xah
∑ http://xahlee.org/
☄
On Aug 25, 6:16 am, ·······@gmail.com" <······@gmail.com> wrote:
>
> .... It used to also talk about how he supports the iraq war with some
> racist undertone or some remarks he made about blacks ... i forgot the
> detail but can be easily found in the article's history log.
>
You can find Raymond's remarks about blacks here:
http://en.wikiquote.org/wiki/Eric_S._Raymond
| In the U.S., blacks are 12% of the population
| but commit 50% of violent crimes; can
| anyone honestly think this is unconnected
| to the fact that they average 15 points of IQ
| lower than the general population? That
| stupid people are more violent is a fact
| independent of skin color.
--agt
On Aug 25, 6:47 am, viper-2 <········@mail.infochan.com> wrote:
> On Aug 25, 6:16 am, ·······@gmail.com" <······@gmail.com> wrote:
>
>
>
> > .... It used to also talk about how he supports the iraq war with some
> > racist undertone or some remarks he made about blacks ... i forgot the
> > detail but can be easily found in the article's history log.
>
> You can find Raymond's remarks about blacks here:http://en.wikiquote.org/wiki/Eric_S._Raymond
>
> | In the U.S., blacks are 12% of the population
> | but commit 50% of violent crimes; can
> | anyone honestly think this is unconnected
> | to the fact that they average 15 points of IQ
> | lower than the general population? That
> | stupid people are more violent is a fact
> | independent of skin color.
>
> --agt
figures dont lie but conclusions are subjective perhaps
On Aug 25, 3:16 am, ·······@gmail.com" <······@gmail.com> wrote:
> On Aug 24, 6:13 pm, Ali <·············@gmail.com> wrote:
>
> > I believe he meant "timeless". Timeless might imply that it was very
> > important to provide a decent language for encoding algorithms,
> > and not so much to the initial size of libraries at year 0. Whether or
> > not the language is great for encoding algorithms (or any other
> > timeless qualities) is largely matter of opinion, as you have stated
> > previously.
>
> > >> there are all sort of problems rendering the term or notion almost useless.
>
> > This page may be of use,http://www.catb.org/~esr/faqs/hacker-howto.html,
> > although I'm guessing you've already read it and maybe even have an
> > essay for it.
>
> i red the jargon file, perhaps some 70% of it, in late 1990s online.
>
> At the time, i appreciate it very much.
>
> But today, i have came to realize that the maintainer Eric Raymond is
> a selfish asshole.
>
> For example, Wikipedia has this to sayhttp://en.wikipedia.org/wiki/Jargon_file
>
> quote:
>
> «Eric S. Raymond maintains the new File with assistance from Guy
> Steele, and is the credited editor of the print version, The New
> Hacker's Dictionary. Some of the changes made under his watch have
> been controversial; early critics accused Raymond of unfairly changing
> the file's focus to the Unix hacker culture instead of the older
> hacker cultures where the Jargon File originated. Raymond has
> responded by saying that the nature of hacking had changed and the
> Jargon File should report on hacker culture, and not attempt to
> enshrine it.[2] More recently, Raymond has been accused of adding
> terms to the Jargon File that appear to have been used primarily by
> himself, and of altering the file to reflect his own political views.
> [3]»
>
> Eric, one of the guy largely responsible for the Open Source movement
> and plays a role a antagonistic to FSF. He also created a hacker logo
> to sell himself. He's essay the Cathedral and Bazzar, which i read in
> late 1990s, i consider stupid. You can often read his posts or
> argument online in various places, and from those post you can see
> he's often just a male ass.
>
> Wikipedia has some illuminating summary of him:http://en.wikipedia.org/wiki/Eric_S._Raymond
>
> basically, a money hungry and selfish ass.
>
> It used to also talk about how he supports the iraq war with some
> racist undertone or some remarks he made about blacks ... i forgot the
> detail but can be easily found in the article's history log.
>
> He used to have a page on his website, not sure if it's still around,
> about what he demands if people wants him to speak. Quite rude.
>
> > In fact, I wouldn't go looking for a dictionary style definition,
> > since he used the word "hacker" to convey what he thought a hacker
> > was, so his article on "great hackers" would be very relevant:
> >http://www.paulgraham.com/gh.html
>
> Paul is a interesting guy. I mean, his lisp achievements and credits
> is quite sufficient for me to find him intelligent and interesting.
>
> However, his's essays related to hackers i just find quite
> wortheless... not even sufficient enough for me to scan ... as
> comparison, i'd rather read text books related to sociology or
> psychology.
>
> ... many famous people write essays. Philosophers, renowed scientists
> of all areas, successful businessman, famous award laureates ...
> often, perhaps majority, of such essays are rather riding on fame and
> worthless in quality when judged in the long term like decades or
> centuries ...
>
> > Those language qualities you listed do seem to be a good measure for a
> > good language though.
> > It seems to me that Arc has the first 2 qualities but not the third.
>
> i wouldn't say arc is good at all with respect to ease of use or
> power.
>
> for ease of use... first of all it uses lisp syntax, and still has
> cons business. These 2 immediately disqualifies it for the masses as
> easy to use. Even if we take a step back, then there's Scheme lisp, so
> in no way arc is easier to use than say Scheme 5.
>
> for power... i doubt if it is in any sense more powerful than say
> Scheme lisp or common lisp. In comparison to the profileration of
> functional langs like Haskell, Ocaml/f# and perhaps also erlang, Q,
> Oz, Mercury, Alice, Mathematica ... the power of arc would be a
> laughing stock.
>
> ... adding the fact such controversies as using ascii as char set (as
> opposed to unicode), using html table as web design, no name space
> mechanism (all these i gathered as hearsay or on Wikipedia) ... arc to
> me is totally without merit. (NewLisp and Qi, yay!)
>
> see also...
> Proliferation of Computing Languageshttp://xahlee.org/UnixResource_dir/writ/new_langs.html
>
> Xah
> ∑http://xahlee.org/
>
> ☄
Raymond was granted 150,000 share options of VA Linux which reached a
value of $32 million on the day of VA's IPO.[17][18] His shares vested
over a four year period contingent on him staying on the board. Twelve
months later, following the internet bubble burst, shares of VA had
dropped from a high of $242.87 to $14. [19]
ouch
xah do you know common lisp?
Daniel Pitts <····················@virtualinfinity.net> writes:
> ······@gmail.com wrote:
>> Arc is one of the despicable worthless shit there is.
>> Arc is the type of shit that when some person becomes famous for his
>> achivement in some area, who began to sell all sort of shit and
>> visions just because he can, and people will buy it.
> That might be true, but I'd love it if you expounded on why you
> believe that? I don't have a lot of lisp experience, so I need
> someone to highlight facts about why Arc is bad comparatively.
As little lisp experience you may have, you have more than Xah.
Asking for advice to Xah in lisp matters (and probably in any other
matter), is like asking for financial advice to the first tramp you
meet.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"This statement is false." In Lisp: (defun Q () (eq nil (Q)))
On Aug 24, 10:04 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Daniel Pitts <····················@virtualinfinity.net> writes:
> > ······@gmail.com wrote:
> >> Arc is one of the despicable worthless shit there is.
> >> Arc is the type of shit that when some person becomes famous for his
> >> achivement in some area, who began to sell all sort of shit and
> >> visions just because he can, and people will buy it.
> > That might be true, but I'd love it if you expounded on why you
> > believe that? I don't have a lot of lisp experience, so I need
> > someone to highlight facts about why Arc is bad comparatively.
>
> As little lisp experience you may have, you have more than Xah.
>
> Asking for advice to Xah in lisp matters (and probably in any other
> matter), is like asking for financial advice to the first tramp you
> meet.
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> "This statement is false." In Lisp: (defun Q () (eq nil (Q)))
LOL
smakdown
go pascal!!!
On Aug 20, 11:47 am, ·······@gmail.com" <······@gmail.com> wrote:
> On Aug 20, 10:43 am, namekuseijin <············@gmail.com> wrote:
>
>
>
> > On Aug 20, 2:55 am, Scott Burson <········@gmail.com> wrote:
>
> > > You could try Liskell:http://liskell.org/
>
> > > I haven't tried it, but it looks interesting.
>
> > Whoa! Looks mighty fine to me! :D
>
> >http://liskell.org/fifteen-minute-tour
>
> > The syntax and semantics look like a nice mix of Scheme and Haskell.
> > I the ease of defining ADTs:
>
> > (defdata Point3DType
> > (Point3D Rational Rational Rational))
>
> > and pattern matching on function definition without destructuring-bind
> > or other verbose macro workaround:
> > (define (distance3D (Point3D x y z))
> > (sqrt (+ (^ x 2)
> > (+ (^ y 2) (^ z 2)))))
>
> > or function definitions in let with the same syntax sugar as in define
> > (no lambda):
> > (define (scalar-multiply s point)
> > (let (((Point3D x y z) point)
> > ((p x) (* s x)))
> > (Point3D (p x) (p y) (p z))))
>
> > Perhaps it also comes full with lazy semantics? A project to watch
> > closely.
>
> > Who knows, perhaps it attracts even more interest than Haskell or Lisp
> > alone... now Arc has some tough competition! :P
>
> Arc is one of the despicable worthless shit there is.
>
> Arc is the type of shit that when some person becomes famous for his
> achivement in some area, who began to sell all sort of shit and
> visions just because he can, and people will buy it.
>
> So, please don't mention arc. Mention Qi, NewLisp, Liskell instead.
> These are far more effort, dedication, earnestness, as well much more
> technical merits or social benefits, than dignitary's fame selling
> shits.
>
> Qi is great because it adds advanced functional features to lisp yet
> remain compatible with Common Lisp.
>
> Liskell is worth looking into because it is a experiment exploiting
> the the nested syntax, meanwhile brings in the semantics of a well
> developed functional lang.
>
> Qi and Liskell are very welcome, and non-trivial, addition to lisp
> communities that can help lispers get new insights.
>
> NewLisp is great because it is a earnest effort in modernizing lisp,
> breaking away the ~3 decades of traditions and thought patterns that
> are rooted in Common Lisp and Scheme. NewLisp's community is entirely
> distinct from CommonLisp/SchemeLisp, attracting much newer generation
> of hobbist and non-professional programers. NewLisp isn't one of the
> fashionable new lang created for the sake of new lang. It has been
> around more than a decade.
>
> http://en.wikipedia.org/wiki/NewLisphttp://en.wikipedia.org/wiki/Qi_(programming_language)
>
> I support Qi, NewLisp, Liskell. Please mention these in your
> socializing chats.
>
> Paul Graham, the author of Arc, of course have every right to create
> his lang just like anyone else, and even for the sole purpose of
> selling his name just because he can. And perhaps due to his past
> contribution in the lisp community, Arc might be successful and
> getting a lot users purely due to Paul's fame. However, please
> consider the real value of a new lang, from technical to social, and
> not as opposed to who's more famous. (for example, technical
> considerations can be such as what new functionality it brings, such
> as Qi, or what insight it might bring, such as Liskell. Social
> consideration can be such as whether it bring the ideas of lisp to
> entirely new segments of society, such as NewLisp.)
>
> See also:
>
> What Languages to Hatehttp://xahlee.org/UnixResource_dir/writ/language_to_hate.html
>
> plain text version follows:
> ----------------------------------
>
> What Languages to Hate
>
> Xah Lee, 2002-07-18
>
> Dear lisp comrades and other concerned parties,
>
> First, all languages have equal rights. Do not belittle other
> languages just because YOUR favorite language is a bit better in this
> aspect or that. Different people have different ideas and manners of
> perception. Ideas compete and thrive in all unexpected fashions.
> Societies improve, inventions progress. Lisp may be a first in this or
> that, or faster or flexibler, or higher level than other languages old
> and new, but then there are other languages the like of Mathematica &
> Haskell & Dylan et al which ridicule lisps in the same way lisp
> ridicule other languages.
>
> Just because YOU are used to more functional programing or love lots
> of parenthesis doesn't mean they are the only and best concepts. The
> so-called Object Oriented programing of Java fame, or the visual
> programing of Visual Basic fame, or the logic programing of Prolog
> fame, or the format-stable syntax of Python fame, or the “one line of
> Mathematica equals ten to one thousand lines of lisp” of _A New Kind
> Of Science_ fame... all are parts of healthy competing concepts,
> paradigms, or directions of growth.
>
> The way some of you deride other languages is like sneering
> heterogeneousness. If unchecked, soon you'll only have your sister to
> marry to. Cute, but you do not want incest to become the only sex.
> Next time your superiority complex makes you sneer at non-lisp or
> newfangled languages, remember this. It is diversity of ideas, that
> drives the welfare of progress.
>
> Now, there is one judgmental criterion, that if a language or computer
> technology fits it, then we not only should castigate at their
> missionaries, but persecute and harass the language to the harshest
> death. That is: utter sloppiness, irresponsibility, and lies. These
> things are often borne out of some student's homework or moron's dirty-
> work, harbored by “free” and wanton lies and personal fame, amassed
> thru ignorance.
>
> Of my short but diligent industrial unix computing experience since
> 1998, i have identified the following targets:
>
> * C (and consequences like csh, C++)
> * vi
> * Perl
> * MySQL
> * unix, unixism, and things grown out of unix. (languages,
> protocols, philosophies, expectations, movements)
>
> In our software industry, i like to define criminals as those who
> cause inordinate harm to society, not necessarily directly. Of the
> above things, some of their authors are not such criminals or are
> forgivable. While others, are hypocritical fantastic liers selfish to
> the core. When dealing with these self-promoting jolly lying humble
> humorous priests and their insidious superficially-harmless speeches,
> there should be no benefit of doubt. Tell them directly to stop their
> vicious lies. Do a face-off.
>
> As to their brain-washed followers for example the not-yet-hard-core
> unix, C, or Perl coders rampant in industry, try to snap them out of
> it. This you do by loudly snapping fingers in front of their face,
> making it sound like a ear piercing bang. Explain to them the utter
> stupidity of the things they are using, and the harm to their brain.
> IMPORTANT: _teach_, not _debate_ or _discuss_ or falling back into
> your philosophical deliberating indecisiveness. I've seen enough
> criticisms among learned programers or academicians on these, so i
> know you know what i'm talking about. When you see a unixer
> brainwashed beyond saving, kick him out of the door. He has became a
> zombie who cannot be helped.
>
> There are other languages or technology, by itself technically are
> perhaps mediocre but at least is not a egregious irresponsible hack,
> therefore does not deserve scorn, but sometimes it comes with
> overwhelming popular outrageous lies (euphemized as hype). Java is a
> example. For this reason, it is equally deserving the harshest
> treatment. Any loud proponents of such should be immediately slapped
> in the mouth and kicked in the ass in no ambiguous ways.
>
> Summary: all languages have equal rights. However, those utterly
> SLOPPY and IRRESPONSIBLE HACKS with promoter's LIES should be severely
> punished. It is these, that cause computing industry inordinate harm.
> Meanwhile, it is wrong to haughtily criticize other languages just
> because they are not your cup of tea. Now, please remember this and go
> do society good.
>
> Xah
> ∑http://xahlee.org/
>
> ☄
like the ask a ninja guys says "I'n not advocating violence, but it
works, and works fast!"
On Aug 20, 7:55 am, Scott Burson <········@gmail.com> wrote:
> On Aug 19, 10:11 pm, Ralph Allan Rice <··········@gmail.com> wrote:
>
> > On Aug 19, 1:31 pm, ssecorp <············@gmail.com> wrote:
>
> > > What are you LISPers opinion of Haskell?
>
> > I recently did some Haskell (and Erlang) hacking, too. Although I like
> > both languages and they both have their niches, the biggest feature
> > that takes me back to Common Lisp every time is macros. Whenever I use
> > another language (does not matter what it is), deep down I wish the
> > language had macros like Common Lisp.
>
> You could try Liskell:http://liskell.org/
>
> I haven't tried it, but it looks interesting.
>
> -- Scott
I just checked out the sight but it doesn't look like much has been
done there recently. Does anyone know any more about this.
Robert
On Aug 19, 10:11 pm, Ralph Allan Rice <··········@gmail.com> wrote:
> On Aug 19, 1:31 pm, ssecorp <············@gmail.com> wrote:
>
> > What are you LISPers opinion of Haskell?
>
> I recently did some Haskell (and Erlang) hacking, too. Although I like
> both languages and they both have their niches, the biggest feature
> that takes me back to Common Lisp every time is macros. Whenever I use
> another language (does not matter what it is), deep down I wish the
> language had macros like Common Lisp.
>
> --
> Ralph
why?
what do they do?
ssecorp wrote:
> What are you LISPers opinion of Haskell?
>
> Pros and cons compared to LISP?
All I know is that some google yobbo listened to sean parent try to
explain for 76 minutes why the dataflow paradigm offered two orders of
magnitude code reduction and all the yobbo could ask was, "Why didn't
you use Haskell?" Far it be it from a Lisper to accuse someone of being
obsessed with an obscure niche language, but I just did.
I think only F# is better at turning otherwise intelligent engineers
into frothing at the mouth idiots. I would have added OCaml but I saw
some investment bank in NYC was Actually Using It, and The Kenny hasa
soft spot for Programmers Actually Programming.
hth, kt
On Aug 19, 9:27 pm, Kenny <·········@gmail.com> wrote:
> I would have added OCaml but I saw
> some investment bank in NYC was Actually Using It, and The Kenny hasa
> soft spot for Programmers Actually Programming.
Also I think FFTW3, the very well used open source Fourier transform
library, uses OCaml to generate optimized C code...
From: Jon Harrop
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <g8h0gn$sl$3@aioe.org>
DeverLite wrote:
> On Aug 19, 9:27�pm, Kenny <·········@gmail.com> wrote:
>> I would have added OCaml but I saw
>> some investment bank in NYC was Actually Using It, and The Kenny hasa
>> soft spot for Programmers Actually Programming.
>
> Also I think FFTW3, the very well used open source Fourier transform
> library, uses OCaml to generate optimized C code...
And FFTW is part of MATLAB. Intel, Microsoft and Citrix all have huge OCaml
code bases as well...
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Aug 19, 7:27 pm, Kenny <·········@gmail.com> wrote:
> ssecorp wrote:
> > What are you LISPers opinion of Haskell?
>
> > Pros and cons compared to LISP?
>
> All I know is that some google yobbo listened to sean parent try to
> explain for 76 minutes why the dataflow paradigm offered two orders of
> magnitude code reduction and all the yobbo could ask was, "Why didn't
> you use Haskell?" Far it be it from a Lisper to accuse someone of being
> obsessed with an obscure niche language, but I just did.
>
> I think only F# is better at turning otherwise intelligent engineers
> into frothing at the mouth idiots. I would have added OCaml but I saw
> some investment bank in NYC was Actually Using It, and The Kenny hasa
> soft spot for Programmers Actually Programming.
>
> hth, kt
link?
youtube?
or you work @google and saw it firsthand?
From: Jon Harrop
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <g8fohj$3ju$1@aioe.org>
ssecorp wrote:
> What are you LISPers opinion of Haskell?
>
> Pros and cons compared to LISP?
Haskell's success rate at generating widely-used open source code is far
lower than most other languages:
http://flyingfrogblog.blogspot.com/2008/08/haskells-virginity.html
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Aug 19, 5:30 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> ssecorp wrote:
> > What are you LISPers opinion of Haskell?
>
> > Pros and cons compared to LISP?
>
> Haskell's success rate at generating widely-used open source code is far
> lower than most other languages:
>
> http://flyingfrogblog.blogspot.com/2008/08/haskells-virginity.html
In summary, Jon's blocg says the haskell compiler is GHC is dropping
the haskell-based darc as its source control system.
good news to know.
See also:
Distributed RCS, Darcs, and Math Sacrilege
http://xahlee.org/UnixResource_dir/writ/darcs.html
plain text version below.
-------------------------
Distributed RCS, Darcs, and Math Sacrilege
Xah Lee, 2007-10-19
When i first heard about distributed revision control system about 2
years ago, i heard of Darcs, which is written in Haskell↗. I was
hugely excited, thinking about the functional programing i love, and
the no-side effect pure system i idolize, and the technology of human
animal i rapture in daily.
I have no serious actual need to use a revision control system (RCS)
in recent years, so i never really tried Darcs (nor actively using any
RCS). I just thought the new-fangled distributed tech in combination
of Haskell was great.
About 2 months ago, i was updating a 5-year old page i wrote on unix
tools (The Unix Pestilence: Tools and Software) and i was trying to
update myself on the current state of the art of revision systems. I
read Wikipedia (Darcs↗) this passage:
Darcs currently has a number of significant bugs (see e.g. [1]).
The most severe of them is "the Conflict bug" - an exponential blowup
in time needed to perform conflict resolution during merges, reaching
into the hours and days for "large" repositories. A redesign of the
repository format and wide-ranging changes in the codebase are planned
in order to fix this bug, and work on this is planned to start in
Spring 2007 [2].
This somewhat bursted my bubble, as there always was some doubt in the
back of my mind about just how Darcs is not just a fantasy-ware
trumpeted by a bunch of functional tech geekers. (i heard of Darcs in
irc emacs channel, who are often student and hobbyists programers)
Also, in my light research, it was to my surprise, that Darcs is not
the only distributed system, and perhaps not the first one neither,
contrary to my impressions. In fact, today there are quite a LOT
distributed revision systems, actually as a norm. When one looks into
these, such as Git↗, one finds that some of them are already used in
the industry for large projects, as opposed to Darcs's academic/
hobbist kind of community.
In addition to these findings, one exacerbation that greatly pissed me
off entirely about Darcs, is the intro of the author (David Roundy)'s
essay about his (questionable-sounding) “theory of patches” used in
Darcs. ( http://darcs.net/manual/node8.html#Patch )
Here's a quote:
I think a little background on the author is in order. I am a
physicist, and think like a physicist. The proofs and theorems given
here are what I would call ``physicist'' proofs and theorems, which is
to say that while the proofs may not be rigorous, they are practical,
and the theorems are intended to give physical insight. It would be
great to have a mathematician work on this, but I am not a
mathematician, and don't care for math.
From the beginning of this theory, which originated as the result
of a series of email discussions with Tom Lord, I have looked at
patches as being analogous to the operators of quantum mechanics. I
include in this appendix footnotes explaining the theory of patches in
terms of the theory of quantum mechanics. I know that for most people
this won't help at all, but many of my friends (and as I write this
all three of darcs' users) are physicists, and this will be helpful to
them. To non-physicists, perhaps it will provide some insight into how
at least this physicist thinks.
I love math. I respect Math. I'm nothing but a menial servant to
Mathematics. Who the fuck is this David guy, who proclaims that he's
no mathematician, then proceed to tell us he doesn't fucking care
about math? Then, he went on about HIS personal fucking zeal for
physics, in particular injecting the highly quacky “quantum mechanics”
with impunity.
-------------------------
Btw, Jon, you often attack Lisp, Haskell. However, i don't think i've
ever seen you criticize OCaml.
Of course, since you sell OCaml thus you are probably very biased.
Is there some criticism of OCaml you could say? so at least to show
you are not that biased?
If you do reply to give some criticism of OCaml, please don't just
give some cursory lip service that appears to be negative criticism
but not. It might be true that you really think OCaml is
comparatively great in all or almost all aspects... but surely there
are some critically negative aspects?
Xah
∑ http://xahlee.org/
☄
Xah Lee wrote:
«
“Distributed RCS, Darcs, and Math Sacrilege”
http://xahlee.org/UnixResource_dir/writ/darcs.html
»
As of 2007-10, the “theory of patches” introduction section of darc's
documentation that contains the “don't care for math” phrase is at
“http://darcs.net/manual/node8.html#Patch”. As of 2008-08-19, that
section seems to moved to a different section, in this url “http://
darcs.net/manual/node9.html” , and the “don't care about math” bit has
been removed.
Thanks to Xah Lee, whose harsh criticism on society sometimes takes
effect silently.
Xah
∑ http://xahlee.org/
☄
On Aug 19, 9:57 pm, ·······@gmail.com" <······@gmail.com> wrote:
> Xah Lee wrote:
>
> «
> “Distributed RCS, Darcs, and Math Sacrilege”http://xahlee.org/UnixResource_dir/writ/darcs.html
> »
>
> As of 2007-10, the “theory of patches” introduction section of darc's
> documentation that contains the “don't care for math” phrase is at
> “http://darcs.net/manual/node8.html#Patch”. As of 2008-08-19, that
> section seems to moved to a different section, in this url “http://
> darcs.net/manual/node9.html” , and the “don't care about math” bit has
> been removed.
>
> Thanks to Xah Lee, whose harsh criticism on society sometimes takes
> effect silently.
>
> Xah
> ∑http://xahlee.org/
>
> ☄
anyone nick name you 'exactly' yet?
On 19 ago, 22:15, ·······@gmail.com" <······@gmail.com> wrote:
> I love math. I respect Math. I'm nothing but a menial servant to
> Mathematics. Who the fuck is this David guy, who proclaims that he's
> no mathematician, then proceed to tell us he doesn't fucking care
> about math? Then, he went on about HIS personal fucking zeal for
> physics, in particular injecting the highly quacky “quantum mechanics”
> with impunity.
Physics and engineers don't care much about math, it's just a useful
tool for their more pragmatic goals.
> Btw, Jon, you often attack Lisp, Haskell. However, i don't think i've
> ever seen you criticize OCaml.
Oh, he does criticize OCaml at every oportunity there is to sell
F#. :)
From: Jon Harrop
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <g8h0i6$sl$4@aioe.org>
namekuseijin wrote:
> Oh, he does criticize OCaml at every oportunity there is to sell
> F#. :)
You realize we sell OCaml products as well:
http://www.ffconsultancy.com/products/ocaml_for_scientists/?u
http://www.ffconsultancy.com/products/ocaml_journal/?u
In fact, there is currently more money in OCaml than F#...
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Haskell is awesome. I heard it might be better to start with ML if it
is your first strongly-typed FP, though.
From: Jon Harrop
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <g8h02g$sl$1@aioe.org>
······@gmail.com wrote:
> Btw, Jon, you often attack Lisp, Haskell. However, i don't think i've
> ever seen you criticize OCaml.
Despite my foray into other FPLs, OCaml has remained my favourite language
for getting work done (F# is arguably better for making money) but OCaml
does have some problems:
. OCaml lacks a concurrent garbage collector and, consequently, is unable to
leverage shared-memory parallelism on a wide range of tasks. F# fixed this.
. OCaml's has unsafe built-in polymorphic functions such as equality,
comparison and hashing. These can silently break if they are accidentally
applied to abstract types and the subsequent bugs can be almost impossible
to fix.
. OCaml has a cumbersome foreign function interface.
. OCaml lacks run-time type information and, consequently, type-safe
serialization and generic printing. F# solved this problem.
. OCaml lacks operator overloading so mathematical expressions involving
many different numeric types are unnecessarily. F# solved this problem.
. OCaml lacks many basic types such as int8, int16, float32, complex32. F#
solved this problem.
. OCaml lacks value types so complex numbers cannot be unboxed. F# solved
this problem and, consequently, is 5.5x faster at complex FFTs than
naively-written OCaml.
. OCaml has an old fashioned one-stage compiler design. F# improves upon
this with the CLR's ahead-of-time compilation. For example, the CLR
generates type specialized native code whereas OCaml uses a uniform generic
representation that can incur substantial performance hits.
. OCaml's uniform generic representation includes tagged 31- and 63-bit
integers. F#'s unboxed representation is ~3x faster.
. The OCaml implementation cannot be contributed to and we cannot pay INRIA
to fix or improve it. For example, I filed a bug with a verbatim source
code fix that was only actually instigated a year later.
I believe these problems can be solved in a future open source FPL without
sacrificing the key features that make OCaml so productive. However, many
of these problems do not constitute research and, consequently, they are
unlikely to be fixed by academic programming language researchers.
I am not sure how to proceed with such a project (e.g. build upon LLVM or
build upon Mono?) but there appears to be growing interest in this idea.
Ideally, FPL communities would collaborate to build a common language
run-time for OCaml, Lisp, Scheme, Haskell and so on but I cannot see that
happening for social reasons. Without such collaboration, I doubt any of
these languages will ever get a concurrent GC approaching the efficiency
of .NET's.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Aug 19, 5:30 pm, Jon Harrop wrote:
> Haskell's success rate at generating widely-used open source code is far
> lower than most other languages:
Your Debian install figures say nothing about "success rates", and do
nothing to compare this rate against "most other languages". Did you
compare against any other language than OCaml? No.
For example, what is the success rate of say, F# at generating widely-
used open source code?
I see nothing to justify your conclusions about the productivity of
*languages in general* based soley on the install figures of a handful
of tools on Debian.
All we can conclude here is that FFTW, a C library, is popular. At a
stretch you might make some conclusions about the effectiveness of the
ocaml-debian packaging team. Any other conclusion is lost in the
noise.
(BTW. this thread is worth it just to see Harrop and Xah Lee
discussing Haskell on a Lisp thread. I do believe this is how baby
trolls are born :)
From: Jon Harrop
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <g91doi$a2n$1@aioe.org>
Don Stewart wrote:
> On Aug 19, 5:30�pm, Jon Harrop wrote:
>> Haskell's success rate at generating widely-used open source code is far
>> lower than most other languages:
>
> Your Debian install figures say nothing about "success rates",
The Debian and Ubuntu popcon results cover billions of software
installations, hundreds of thousands of users from two of the most popular
Linux distributions and tens of thousands of packages. They are undoubtedly
among the most reliable quantitative sources of information for how widely
adopted open source projects have become.
The article I cited contains a thorough analysis based upon these objective
quantifications and it estimates the order of magnitude ratio of the
success rates of OCaml and Haskell for creating widely-used open source
software. The conclusion is that Haskell is an order of magnitude less
successful than OCaml.
> For example, what is the success rate of say, F# at generating widely-
> used open source code?
Unknown: no comparable data are available for F# because it is a proprietary
Microsoft language.
> I see nothing to justify your conclusions about the productivity of
> *languages in general* based soley on the install figures of a handful
> of tools on Debian.
You are misrepresenting both the conclusion and the evidence. I am
disappointed: even Ganesh Sittampalam managed to create a plausible
sounding objection, although his quantifications turned out to be nothing
more than wildly inaccurate guesses.
> All we can conclude here is that FFTW, a C library, is popular.
You can get a lot more out of these data if you analyse them properly.
Moreover, the analysis is quite easy: even a web programmer could do it.
> At a stretch you might make some conclusions about the effectiveness of
> the ocaml-debian packaging team.
On the contrary, the success of projects like FFTW, Unison and MLDonkey had
nothing to do with the OCaml-Debian packaging team.
> Any other conclusion is lost in the noise.
Here are the facts again:
. 221,293 installs of popular OCaml software compared to only 7,830 of
Haskell.
. 235,312 lines of well-tested OCaml code compared to only 27,162 lines of
well-tested Haskell code.
Those are huge differences. How else do you explain them?
> (BTW. this thread is worth it just to see Harrop and Xah Lee
> discussing Haskell on a Lisp thread. I do believe this is how baby
> trolls are born :)
I find it far more enlightening that you would ban me from the Haskell Cafe
mailing list and IRC channel in order to avoid discussion of your own
findings. You must be much less confident in your work than I am in mine.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
>
> The Debian and Ubuntu popcon results cover billions of software
> installations, hundreds of thousands of users from two of the most popular
> Linux distributions and tens of thousands of packages. They are undoubtedly
> among the most reliable quantitative sources of information for how widely
> adopted open source projects have become.
This years results of the Debian and Ubuntu popularity contests are
based on 74011 submissions. There have never been more than 80,000
submissions in a single year.
This is hardly a comprehensive metric.
>
> The article I cited contains a thorough analysis based upon these objective
> quantifications and it estimates the order of magnitude ratio of the
> success rates of OCaml and Haskell for creating widely-used open source
> software. The conclusion is that Haskell is an order of magnitude less
> successful than OCaml.
The "article" you cite is your same bogus analysis of the debian
package popularity contest, basically it is a thinly veiled plug for
Flying Frog Consultancy.
From: Jon Harrop
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <g922ta$20b$1@aioe.org>
parnell wrote:
>> The Debian and Ubuntu popcon results cover billions of software
>> installations, hundreds of thousands of users from two of the most
>> popular Linux distributions and tens of thousands of packages. They are
>> undoubtedly among the most reliable quantitative sources of information
>> for how widely adopted open source projects have become.
>
> This years results of the Debian and Ubuntu popularity contests are
> based on 74011 submissions. There have never been more than 80,000
> submissions in a single year.
That is obviously wrong given that the article cited 184,574 installs of
FFTW alone.
> This is hardly a comprehensive metric.
You appear to have neglected the Ubuntu popularity contest that account for
an order of magnitude more people again.
>> The article I cited contains a thorough analysis based upon these
>> objective quantifications and it estimates the order of magnitude ratio
>> of the success rates of OCaml and Haskell for creating widely-used open
>> source software. The conclusion is that Haskell is an order of magnitude
>> less successful than OCaml.
>
> The "article" you cite is your same bogus analysis of the debian
> package popularity contest, basically it is a thinly veiled plug for
> Flying Frog Consultancy.
In other words, you also have no testable objections to the analysis
presented in the article so you are resorting to ad-hominem attacks. I am
not surprised: you clearly do not put your money where your mouth is, as I
do.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
In article <············@aioe.org>, Jon Harrop <···@ffconsultancy.com>
wrote:
> parnell wrote:
> >> The Debian and Ubuntu popcon results cover billions of software
> >> installations, hundreds of thousands of users from two of the most
> >> popular Linux distributions and tens of thousands of packages. They are
> >> undoubtedly among the most reliable quantitative sources of information
> >> for how widely adopted open source projects have become.
> >
> > This years results of the Debian and Ubuntu popularity contests are
> > based on 74011 submissions. There have never been more than 80,000
> > submissions in a single year.
>
> That is obviously wrong given that the article cited 184,574 installs of
> FFTW alone.
>
> > This is hardly a comprehensive metric.
>
> You appear to have neglected the Ubuntu popularity contest that account for
> an order of magnitude more people again.
>
> >> The article I cited contains a thorough analysis based upon these
> >> objective quantifications and it estimates the order of magnitude ratio
> >> of the success rates of OCaml and Haskell for creating widely-used open
> >> source software. The conclusion is that Haskell is an order of magnitude
> >> less successful than OCaml.
> >
> > The "article" you cite is your same bogus analysis of the debian
> > package popularity contest, basically it is a thinly veiled plug for
> > Flying Frog Consultancy.
>
> In other words, you also have no testable objections to the analysis
> presented in the article so you are resorting to ad-hominem attacks. I am
> not surprised: you clearly do not put your money where your mouth is, as I
> do.
___________________________
/| /| | |
||__|| | Please don't |
/ O O\__ feed |
/ \ the troll |
/ \ \ |
/ _ \ \ ----------------------
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | __||
/ / \ |____| ||
/ | | /| | --|
| | |// |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ // |
/ _ \\ _ // | /
* / \_ /- | - | |
* ___ c_c_c_C/ \C_c_c_c____________
If you have to post something about Dr. Jon Harrop (or his
sock puppets), then post it here:
http://harrop-highly.blogspot.com/
On Aug 26, 4:30 pm, Rainer Joswig <······@lisp.de> wrote:
> In article <············@aioe.org>, Jon Harrop <····@ffconsultancy.com>
> wrote:
>
>
>
> > parnell wrote:
> > >> The Debian and Ubuntu popcon results cover billions of software
> > >> installations, hundreds of thousands of users from two of the most
> > >> popular Linux distributions and tens of thousands of packages. They are
> > >> undoubtedly among the most reliable quantitative sources of information
> > >> for how widely adopted open source projects have become.
>
> > > This years results of the Debian and Ubuntu popularity contests are
> > > based on 74011 submissions. There have never been more than 80,000
> > > submissions in a single year.
>
> > That is obviously wrong given that the article cited 184,574 installs of
> > FFTW alone.
>
> > > This is hardly a comprehensive metric.
>
> > You appear to have neglected the Ubuntu popularity contest that account for
> > an order of magnitude more people again.
>
> > >> The article I cited contains a thorough analysis based upon these
> > >> objective quantifications and it estimates the order of magnitude ratio
> > >> of the success rates of OCaml and Haskell for creating widely-used open
> > >> source software. The conclusion is that Haskell is an order of magnitude
> > >> less successful than OCaml.
>
> > > The "article" you cite is your same bogus analysis of the debian
> > > package popularity contest, basically it is a thinly veiled plug for
> > > Flying Frog Consultancy.
>
> > In other words, you also have no testable objections to the analysis
> > presented in the article so you are resorting to ad-hominem attacks. I am
> > not surprised: you clearly do not put your money where your mouth is, as I
> > do.
>
> ___________________________
> /| /| | |
> ||__|| | Please don't |
> / O O\__ feed |
> / \ the troll |
> / \ \ |
> / _ \ \ ----------------------
> / |\____\ \ ||
> / | | | |\____/ ||
> / \|_|_|/ | __||
> / / \ |____| ||
> / | | /| | --|
> | | |// |____ --|
> * _ | |_|_|_| | \-/
> *-- _--\ _ \ // |
> / _ \\ _ // | /
> * / \_ /- | - | |
> * ___ c_c_c_C/ \C_c_c_c____________
>
> If you have to post something about Dr. Jon Harrop (or his
> sock puppets), then post it here:
>
> http://harrop-highly.blogspot.com/
sock puppets lol
>You appear to have neglected the Ubuntu popularity contest that account for
>an order of magnitude more people again.
>
True, Ubuntu has 683367 submissions. The data gets murkier once you
pick through it for instance the FFTW data that you cite
vote old recent no files
Package: fftw3 139 9884 27 165142
Where
vote - number of people who use this package regularly;
old - number of people who installed, but don't use this package
regularly;
recent - number of people who upgraded this package recently;
no-files - number of people whose entry didn't contain enough
information
(atime and ctime were 0).
So although we have ~185,000 installs of FFTW only 139 of those
installs are "used".
Surly some of the "no files" set must be used so if we use the ratio
of vote to old we come up with 2,322 more that most likely should be
in the "vote" column.
You analysis of the data was not in any way thorough, your portrayal
of the data and the conclusions you draw about haskell on this list
and in your article are misleading.
In article
<····································@y21g2000hsf.googlegroups.com>,
parnell <·············@ronin-capital.com> wrote:
> >You appear to have neglected the Ubuntu popularity contest that account for
> >an order of magnitude more people again.
> >
>
> True, Ubuntu has 683367 submissions. The data gets murkier once you
> pick through it for instance the FFTW data that you cite
> vote old recent no files
> Package: fftw3 139 9884 27 165142
>
> Where
> vote - number of people who use this package regularly;
> old - number of people who installed, but don't use this package
> regularly;
> recent - number of people who upgraded this package recently;
> no-files - number of people whose entry didn't contain enough
> information
> (atime and ctime were 0).
>
> So although we have ~185,000 installs of FFTW only 139 of those
> installs are "used".
> Surly some of the "no files" set must be used so if we use the ratio
> of vote to old we come up with 2,322 more that most likely should be
> in the "vote" column.
>
> You analysis of the data was not in any way thorough, your portrayal
> of the data and the conclusions you draw about haskell on this list
> and in your article are misleading.
Last I looked FFTW was a C library. Has that changed?
--
http://lispm.dyndns.org/
On Aug 27, 8:29 am, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@y21g2000hsf.googlegroups.com>,
>
>
>
> parnell <·············@ronin-capital.com> wrote:
> > >You appear to have neglected the Ubuntu popularity contest that account for
> > >an order of magnitude more people again.
>
> > True, Ubuntu has 683367 submissions. The data gets murkier once you
> > pick through it for instance the FFTW data that you cite
> > vote old recent no files
> > Package: fftw3 139 9884 27 165142
>
> > Where
> > vote - number of people who use this package regularly;
> > old - number of people who installed, but don't use this package
> > regularly;
> > recent - number of people who upgraded this package recently;
> > no-files - number of people whose entry didn't contain enough
> > information
> > (atime and ctime were 0).
>
> > So although we have ~185,000 installs of FFTW only 139 of those
> > installs are "used".
> > Surly some of the "no files" set must be used so if we use the ratio
> > of vote to old we come up with 2,322 more that most likely should be
> > in the "vote" column.
>
> > You analysis of the data was not in any way thorough, your portrayal
> > of the data and the conclusions you draw about haskell on this list
> > and in your article are misleading.
>
> Last I looked FFTW was a C library. Has that changed?
>
> --http://lispm.dyndns.org/
It is an excellent C library generated by OCaml code.
Here is an excerpt from their FAQ:
Question 2.7. Which language is FFTW written in?
FFTW is written in ANSI C. Most of the code, however, was
automatically generated by a program called genfft, written in the
Objective Caml dialect of ML. You do not need to know ML or to have an
Objective Caml compiler in order to use FFTW.
http://www.fftw.org/
From: Jon Harrop
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <g93uu8$3j9$1@aioe.org>
parnell wrote:
>>You appear to have neglected the Ubuntu popularity contest that account
>>for an order of magnitude more people again.
>>
>
> True, Ubuntu has 683367 submissions. The data gets murkier once you
> pick through it for instance the FFTW data that you cite
> vote old recent no files
> Package: fftw3 139 9884 27 165142
>
> Where
> vote - number of people who use this package regularly;
> old - number of people who installed, but don't use this package
> regularly;
> recent - number of people who upgraded this package recently;
> no-files - number of people whose entry didn't contain enough
> information
> (atime and ctime were 0).
>
> So although we have ~185,000 installs of FFTW only 139 of those
> installs are "used".
The fftw3 package transitioned to libfftw3-3 a year ago:
http://people.debian.org/~igloo/popcon-graphs/index.php?packages=fftw3%2C
libfftw3-3&show_installed=on&want_ticks=on&from_date=&to_date=&hlght_date
=&date_fmt=%25Y-%25m&beenhere=1
So you have analysed data about the wrong package.
> Surly some of the "no files" set must be used so if we use the ratio
> of vote to old we come up with 2,322 more that most likely should be
> in the "vote" column.
The old package is now largely unused now that the transition is complete,
yes.
> You analysis of the data was not in any way thorough, your portrayal of
> the data and the conclusions you draw about haskell on this list and in
> your article are misleading.
Let's just review the correct data from Ubuntu:
rank name inst vote old recent no-files
1735 libfftw3-3 104150 9084 77412 8288 9366
7652 darcs 2998 271 2634 92 1
As you can see, the "recent" column shows an even larger discrepancy: FFTW
has two orders of magnitude more recent installs than Darcs (8,288 vs 92).
Please do continue trying to disprove my findings or try to build a
similarly objective and statistically meaningful study that contracts these
results. I have actually tried to do this myself but I am only finding more
and more data that substantiate my original conclusion that Haskell is not
yet a success in this context.
For example, MLDonkey alone is still seeing tens of thousands of downloads
every month from SourceForge:
http://sourceforge.net/project/stats/detail.php?group_id=156414&
ugn=mldonkey&type=prdownload&mode=12months&package_id=0
I cannot find any software written in Haskell that gets within an order of
magnitude of that.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
hi Jon Harrop,
[ “Haskell's virginity” by Jon Harrop
http://flyingfrogblog.blogspot.com/2008/08/haskells-virginity.html
(a report on OCaml and Haskell use in linux)
]
First, i like to thank you for the informative study on particular
aspect of OCaml and Haskell popularity. I think it is informative, and
the effort of your report in to some degree non-trivial.
With that said, i do believe your opinion are often biased and tends
peddle your products and website about OCaml.
In particular, i don't think the conclusion you made, about how OCaml
is one order of magnitude more use in the industry, being valid.
For example, many commercial use of languages are not public. As a
example, Wolfram Research, the maker of Mathematica, sells more
Mathematica than any lisp companies combined.
This can be gathered from company size and financial records. However,
if you go by your methods, such as polling stats from linux distros,
or other means of checking stats among open source communities, you
won't find any indication of this.
Granted, your study is specifically narrowed to OpenSource project
queries. But there is still a fact about commercial, non-public use,
which often are far more serious and important. Open Source projects
are typically just happensances of some joe hacker's enthus about a
lang, and open source products's audience is again often not with any
serious considerations.
For example, your report contains FFTW, Unison, Darcs. Unison is a bi-
way file syncing tool, which i personally use daily. Darcs is a
revision system for source code. FFTW, as i learned, is a lib for
fourier transform. These tools, basically are results of some joe
hacker who happens to love or use a particular lang. Their users,
basically use them because there isn't others around (in the case of
Darcs, because it uses a lang they like). The other tools listed in
your report: MLDonkey, Free Tennis, Planets, HPodder, LEdit, Hevea,
Polygen, i haven't checked what they are, but i think you'd agree they
basically fit into my describtion about FFTW, Unison, Darcs above.
Namely, some hobby programers happened to create a software that does
X well above others, thus other hobby programers who happens to need
it, use them.
(the above is quickly written, i'm sure there are many flaws to pick
as i phrased it, but i think you get the idea)
In your report, you made a sort of conclusion as this:
«This led us to revisit the subject of Haskell's popularity and track
record. We had reviewed Haskell last year in order to ascertain its
commercial viability when we were looking to diversify into other
functional languages. Our preliminary results suggested that Haskell
was one of the most suitable functional languages but this recent news
has brought that into question.»
That remark is slightly off. You phrased “Haskell's popularity and
track record”, but note that your stat is just a measure of some pop
tools among linux.
It is a exageration to say that it's some sort of “track record” of
haskell like a damnatation. Haskell for example, has strong academic
background. So, a fair “track record” would also measure its academic
use.
You also used the word “popularity”. Again, popularity is a fuzzy
word, but in general it also connate to mindshare. Between Haskell and
OCaml, i doubt more programer heard or knows about OCaml than Haskell,
and as far as mindshare goes, both are dwarfed by Lisp.
Then, you mentioned “commercial viability”. Again, what tools happened
to be cooked up by idle tech geekers in particular lang does not have
much to do with “commercial viability”.
So, although i do find your report meaningful and has some force in
indicating how OCaml is more used in terms of number of solid tools
among idle programers, but i don't agree with your seemingly overboard
conclusion that OCaml is actually some order of magnitude more used or
popular than Haskell for serious projects.
This is a pure guess: i think any validity of OCaml's popularity in
open source industrial use than Haskell is probably because OCaml has
more industrial background than Haskell, given the lang's histories.
------------------
On a tangent, many here accuse you being a troll. As i mentioned, i do
find your posts tends to be divisive and selling your website, but
considered on the whole of newsgroup's posts in particular by many
regulars, i think your posting behavior overall are in any sense
particularly bad.
Recently, i answered to a post used your name and your photo in
group.goople.com's profile. When i answered that post, i thought it
was from you. Thanks for letting me know otherwise.
(See:
Fake Jon Harrop post
http://groups.google.com/group/comp.lang.lisp/msg/43f971ff443e2ce5
Fake Jon Harrop profile
http://groups.google.com/groups/profile?enc_user=Cv3pMh0AAACHpIZ29S1AglWPUrDEZmMqdL-C5pPggpE8SFMrQg3Ptg
)
I think many tech geekers on newsgroups are just ignorant fuckfaces.
The guy who fake'd your identity, to the degree of using your photo in
his fake profile, perhaps thinks he's being humorous.
Xah
∑ http://xahlee.org/
☄
On Aug 27, 9:23 am, Jon Harrop <····@ffconsultancy.com> wrote:
> parnell wrote:
> >>You appear to have neglected the Ubuntu popularity contest that account
> >>for an order of magnitude more people again.
>
> > True, Ubuntu has 683367 submissions. The data gets murkier once you
> > pick through it for instance the FFTW data that you cite
> > vote old recent no files
> > Package: fftw3 139 9884 27 165142
>
> > Where
> > vote - number of people who use this package regularly;
> > old - number of people who installed, but don't use this package
> > regularly;
> > recent - number of people who upgraded this package recently;
> > no-files - number of people whose entry didn't contain enough
> > information
> > (atime and ctime were 0).
>
> > So although we have ~185,000 installs of FFTW only 139 of those
> > installs are "used".
>
> The fftw3 package transitioned to libfftw3-3 a year ago:
>
> http://people.debian.org/~igloo/popcon-graphs/index.php?packages=fftw...
> libfftw3-3&show_installed=on&want_ticks=on&from_date=&to_date=&hlght_date
> =&date_fmt=%25Y-%25m&beenhere=1
>
> So you have analysed data about the wrong package.
>
> > Surly some of the "no files" set must be used so if we use the ratio
> > of vote to old we come up with 2,322 more that most likely should be
> > in the "vote" column.
>
> The old package is now largely unused now that the transition is complete,
> yes.
>
> > You analysis of the data was not in any way thorough, your portrayal of
> > the data and the conclusions you draw about haskell on this list and in
> > your article are misleading.
>
> Let's just review the correct data from Ubuntu:
>
> rank name inst vote old recent no-files
> 1735 libfftw3-3 104150 9084 77412 8288 9366
> 7652 darcs 2998 271 2634 92 1
>
> As you can see, the "recent" column shows an even larger discrepancy: FFTW
> has two orders of magnitude more recent installs than Darcs (8,288 vs 92).
>
> Please do continue trying to disprove my findings or try to build a
> similarly objective and statistically meaningful study that contracts these
> results. I have actually tried to do this myself but I am only finding more
> and more data that substantiate my original conclusion that Haskell is not
> yet a success in this context.
>
> For example, MLDonkey alone is still seeing tens of thousands of downloads
> every month from SourceForge:
>
> http://sourceforge.net/project/stats/detail.php?group_id=156414&
> ugn=mldonkey&type=prdownload&mode=12months&package_id=0
>
> I cannot find any software written in Haskell that gets within an order of
> magnitude of that.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancyhttp://www.ffconsultancy.com/products/?u
From: Jon Harrop
Subject: Re: OCaml vs Haskell [was Re: What do you LISPers think of Haskell?]
Date:
Message-ID: <g94csj$m3m$1@aioe.org>
······@gmail.com wrote:
> With that said, i do believe your opinion are often biased and tends
> peddle your products and website about OCaml.
I certainly do peddle our products whenever possible. However, the data I
presented are verifiable and I would encourage anyone interested to repeat
the analysis themselves. There are many caveats in doing so but I think any
reasonable study will come to the same conclusion because the data are so
clear in this case.
> In particular, i don't think the conclusion you made, about how OCaml
> is one order of magnitude more use in the industry, being valid.
That was not my conclusion! I was careful to say that this refers only to
open source software (having examined two major Linux distros). I added
that this undermines my confidence in using Haskell commercially but that
is a personal opinion and not a justifiable conclusion.
> For example, many commercial use of languages are not public. As a
> example, Wolfram Research, the maker of Mathematica, sells more
> Mathematica than any lisp companies combined.
> This can be gathered from company size and financial records. However,
> if you go by your methods, such as polling stats from linux distros,
> or other means of checking stats among open source communities, you
> won't find any indication of this.
Interestingly, Wolfram Research have used OCaml commercially as well.
> Granted, your study is specifically narrowed to OpenSource project
> queries. But there is still a fact about commercial, non-public use,
> which often are far more serious and important. Open Source projects
> are typically just happensances of some joe hacker's enthus about a
> lang, and open source products's audience is again often not with any
> serious considerations.
>
> For example, your report contains FFTW, Unison, Darcs. Unison is a bi-
> way file syncing tool, which i personally use daily. Darcs is a
> revision system for source code. FFTW, as i learned, is a lib for
> fourier transform. These tools, basically are results of some joe
> hacker who happens to love or use a particular lang. Their users,
> basically use them because there isn't others around (in the case of
> Darcs, because it uses a lang they like). The other tools listed in
> your report: MLDonkey, Free Tennis, Planets, HPodder, LEdit, Hevea,
> Polygen, i haven't checked what they are, but i think you'd agree they
> basically fit into my describtion about FFTW, Unison, Darcs above.
Some do but FFTW certainly does not. FFTW is the result of decades of work
by the world's foremost experts on the subject who received prestigious
awards for their ground breaking work. FFTW is such a tremendous
achievement that many commercial users, including The MathWorks for MATLAB,
have paid to incorporate FFTW into their commercial products under license
from MIT.
MLDonkey has been one of the most prolific file sharing utilities ever, and
is believed to have had ~250,000 users at its peak. LEdit is a widely used
tool for command line editing. Hevea is a widely used LaTeX to HTML
translator.
So some of these programs are fun toys (like Planets) but many are really
serious tools.
> �This led us to revisit the subject of Haskell's popularity and track
> record. We had reviewed Haskell last year in order to ascertain its
> commercial viability when we were looking to diversify into other
> functional languages. Our preliminary results suggested that Haskell
> was one of the most suitable functional languages but this recent news
> has brought that into question.�
>
> That remark is slightly off. You phrased ?Haskell's popularity and
> track record?, but note that your stat is just a measure of some pop
> tools among linux.
> It is a exageration to say that it's some sort of ?track record? of
> haskell like a damnatation. Haskell for example, has strong academic
> background.
While the vast majority of Haskell's use appears to be academic, I am not
even sure that it is fair to say that Haskell has a "strong academic
background".
> So, a fair ?track record? would also measure its academic
> use.
That is a question of perspective and I am interested in commercial
applications of these languages, of course.
> You also used the word ?popularity?. Again, popularity is a fuzzy
> word, but in general it also connate to mindshare. Between Haskell and
> OCaml, i doubt more programer heard or knows about OCaml than Haskell,
I agree.
> and as far as mindshare goes, both are dwarfed by Lisp.
I do not believe that.
> Then, you mentioned ?commercial viability?. Again, what tools happened
> to be cooked up by idle tech geekers in particular lang does not have
> much to do with ?commercial viability?.
I disagree. The direct commercialization of FFTW is the most obvious counter
example but many of the other tools have direct commercial counterparts.
> So, although i do find your report meaningful and has some force in
> indicating how OCaml is more used in terms of number of solid tools
> among idle programers, but i don't agree with your seemingly overboard
> conclusion that OCaml is actually some order of magnitude more used or
> popular than Haskell for serious projects.
The data speak for themselves, IMHO.
> This is a pure guess: i think any validity of OCaml's popularity in
> open source industrial use than Haskell is probably because OCaml has
> more industrial background than Haskell, given the lang's histories.
I certainly find the OCaml community to be very grounded in practicality and
the Haskell community to be intolerably theoretical.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Andrew Reilly
Subject: Re: OCaml vs Haskell [was Re: What do you LISPers think of Haskell?]
Date:
Message-ID: <6hmeghFms8j2U2@mid.individual.net>
On Wed, 27 Aug 2008 21:20:51 +0100, Jon Harrop wrote:
> Some do but FFTW certainly does not. FFTW is the result of decades of
> work by the world's foremost experts on the subject who received
> prestigious awards for their ground breaking work. FFTW is such a
> tremendous achievement that many commercial users, including The
> MathWorks for MATLAB, have paid to incorporate FFTW into their
> commercial products under license from MIT.
FFTW is a superb piece of work, but I think that it's important to note
that its use of OCaml is strictly off-line and not performance critical.
The OCaml is used to generate C code, and is not actually run by anyone
but the FFTW developers. Everyone else just compiles and runs the
generated C code.
So the choice of OCaml comes down to familiarity and convenience for the
developers, rather than run-time performance. Given what it's doing (I
haven't looked at the OCaml code since the very first version came out,
so I've essentially forgotten it) I suspect that the pattern matching
functional nature was much more important than the type safety or
compiled performance. I suppose that Frigo and Johnson have written
about their choice of OCaml somewhere. Doesn't seem to be one on the
FFTW web site though. Skimming some of their papers, it's clearly a good
choice, because the expression simplifiers can be expressed quite neatly,
and matching seems to be used extensively. I suspect that Haskell or
Prolog or even one of the modern schemes (with structures and match)
could have been used just about as well, had the authors been so inclined.
Cheers,
--
Andrew
From: Jon Harrop
Subject: Re: OCaml vs Haskell [was Re: What do you LISPers think of Haskell?]
Date:
Message-ID: <g95v6j$nji$1@aioe.org>
Andrew Reilly wrote:
> On Wed, 27 Aug 2008 21:20:51 +0100, Jon Harrop wrote:
>> Some do but FFTW certainly does not. FFTW is the result of decades of
>> work by the world's foremost experts on the subject who received
>> prestigious awards for their ground breaking work. FFTW is such a
>> tremendous achievement that many commercial users, including The
>> MathWorks for MATLAB, have paid to incorporate FFTW into their
>> commercial products under license from MIT.
>
> FFTW is a superb piece of work, but I think that it's important to note
> that its use of OCaml is strictly off-line
Yes.
> and not performance critical.
No. OCaml's performance is as important here as it is in any other compiler:
compile time performance is important.
> The OCaml is used to generate C code, and is not actually run by anyone
> but the FFTW developers. Everyone else just compiles and runs the
> generated C code.
On the contrary, FFTW's performance stems from its ability to generate
custom codelets for transform lengths that the user values. Users do this
by running the OCaml code to generate more C. Hence the Debian source
package is downloaded more often than the binary package because users need
the OCaml source code.
> So the choice of OCaml comes down to familiarity and convenience for the
> developers, rather than run-time performance.
I do not believe so.
> Given what it's doing (I
> haven't looked at the OCaml code since the very first version came out,
> so I've essentially forgotten it) I suspect that the pattern matching
> functional nature was much more important than the type safety or
> compiled performance.
On the contrary, generating custom codelets is a very time consuming process
that required days of computation when FFTW was first released. Moreover,
the authors of FFTW would have repeated this process countless times to
obtain their results and perform thorough benchmarking of the run-time.
So OCaml's predictable and excellent performance was unquestionably of
critical importance to this high-profile project.
> I suppose that Frigo and Johnson have written
> about their choice of OCaml somewhere. Doesn't seem to be one on the
> FFTW web site though. Skimming some of their papers, it's clearly a good
> choice, because the expression simplifiers can be expressed quite neatly,
> and matching seems to be used extensively.
Yes.
> I suspect that Haskell or
> Prolog or even one of the modern schemes (with structures and match)
> could have been used just about as well, had the authors been so inclined.
Until there is evidence to support your hypothesis, we know only that OCaml
is capable of this.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Andrew Reilly
Subject: Re: OCaml vs Haskell [was Re: What do you LISPers think of Haskell?]
Date:
Message-ID: <6hnlqvFmkqpeU1@mid.individual.net>
On Thu, 28 Aug 2008 11:39:36 +0100, Jon Harrop wrote:
> On the contrary, FFTW's performance stems from its ability to generate
> custom codelets for transform lengths that the user values. Users do
> this by running the OCaml code to generate more C. Hence the Debian
> source package is downloaded more often than the binary package because
> users need the OCaml source code.
No, all of the codelets are already generated and shipped with the source
distribution. These are tested for performance at run-time (or at least
when the wisdom is generated). The FreeBSD port of fftw3 does not have
ocaml as a compile or run-time dependency. Sure the ocaml source ships
with the distribution too, in case anyone cares to fiddle with it, I
suppose. Indeed, I have fftw3 on my system (it's a dependency of 18
other packages on my system), but I don't have ocaml.
Maybe the Debian maintainers do things differently.
Cheers,
--
Andrew
From: Jon Harrop
Subject: Re: OCaml vs Haskell [was Re: What do you LISPers think of Haskell?]
Date:
Message-ID: <g96q7f$21t$1@aioe.org>
Andrew Reilly wrote:
> On Thu, 28 Aug 2008 11:39:36 +0100, Jon Harrop wrote:
>> On the contrary, FFTW's performance stems from its ability to generate
>> custom codelets for transform lengths that the user values. Users do
>> this by running the OCaml code to generate more C. Hence the Debian
>> source package is downloaded more often than the binary package because
>> users need the OCaml source code.
>
> No, all of the codelets are already generated and shipped with the source
> distribution.
No, *some* codelets are generated and shipped but by no mean all (infinity)
of them. This is precisely the purpose of the genfft tool: you can use it
to generate new codelets that are not bundled in order to improve
performance for certain lengths of transform.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Andrew Reilly wrote:
> So the choice of OCaml comes down to familiarity and convenience for the
> developers, rather than run-time performance. Given what it's doing (I
> haven't looked at the OCaml code since the very first version came out,
> so I've essentially forgotten it) I suspect that the pattern matching
> functional nature was much more important than the type safety or
> compiled performance. I suppose that Frigo and Johnson have written
> about their choice of OCaml somewhere. Doesn't seem to be one on the
> FFTW web site though. Skimming some of their papers, it's clearly a good
> choice, because the expression simplifiers can be expressed quite neatly,
> and matching seems to be used extensively. I suspect that Haskell or
> Prolog or even one of the modern schemes (with structures and match)
> could have been used just about as well, had the authors been so inclined.
I recently stumbled upon an interesting excerpt from the FFTW site:
"The genfft program was written using Objective Caml, a dialect of ML.
Objective Caml is a small and elegant language developed by Xavier Leroy.
The implementation is available from ftp.inria.fr in the directory
lang/caml-light. We used versions 1.07 and 2.00 of the software. In
previous releases of FFTW, genfft was written in Caml Light, by the same
authors. An even earlier implementation of genfft was written in Scheme,
but Caml is definitely better for this kind of application." -
http://www.fftw.org/fftw2_doc/fftw_7.html
So the authors were even coming from a Lisp/Scheme background but after
trying OCaml they concluded that it is "definitely better" and migrated
entirely from Scheme to OCaml.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 3 Set, 16:21, Jon Harrop <····@ffconsultancy.com> wrote:
> ...
Let's guerrilla everybody!!
-XY
From: John Thingstad
Subject: Re: OCaml vs Haskell [was Re: What do you LISPers think of Haskell?]
Date:
Message-ID: <op.ugwtkutzut4oq5@pandora.alfanett.no>
P� Wed, 03 Sep 2008 16:21:29 +0200, skrev Jon Harrop
<···@ffconsultancy.com>:
>
> So the authors were even coming from a Lisp/Scheme background but after
> trying OCaml they concluded that it is "definitely better" and migrated
> entirely from Scheme to OCaml.
>
Of cource for FFT Fortran would probaly be the best choice..
--------------
John Thingstad
John Thingstad wrote:
> På Wed, 03 Sep 2008 16:21:29 +0200, skrev Jon Harrop
> <···@ffconsultancy.com>:
>> So the authors were even coming from a Lisp/Scheme background but after
>> trying OCaml they concluded that it is "definitely better" and migrated
>> entirely from Scheme to OCaml.
>
> Of cource for FFT Fortran would probaly be the best choice..
You can alter the OCaml source code to FFTW to generate Fortran instead of C
and rewrite the stubs in Fortran but I believe C was chosen because it is
far more widely available and has far more mature tools.
For example, I recently tried to compile the Fortran 77 source code to BLAS
and LAPACK from NetLib and all of the commercial compilers I tried
(including Intel's) failed to do so reliably except for the GCC which is
rock solid but generates inefficient code. So I am certainly happy that
FFTW uses C instead of Fortran.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
> Had your previous assertion been true then I would agree but I cannot see
> that this is the case. The "installed" data that I analyzed does not trend
> with the "vote" data and does not correlate with the fluctuations in
> the "recent" and "old" data. So this source of error did not affect my
> analysis.
http://people.debian.org/~igloo/popcon-graphs/index.php?packages=unis..%2Cdarcs&show_installed=on&show_vote=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
The voted category and the installed do not show the wild fluctuations
of the recent or old categories. When you count the installed
category you are counting installs of software that is never used,
completely invalidating your analysis.
From: Tamas K Papp
Subject: Re: OCaml vs Haskell [was Re: What do you LISPers think of Haskell?]
Date:
Message-ID: <6hnj9mFm0g2uU1@mid.individual.net>
On Thu, 28 Aug 2008 05:05:47 -0700, parnell wrote:
> The voted category and the installed do not show the wild fluctuations
> of the recent or old categories. When you count the installed category
> you are counting installs of software that is never used, completely
> invalidating your analysis.
Has is ever occurred to you that you are tirelessly arguing about a
statistic that is quite meaningless when you consider the original
question (popularity of programming languages)? Just asking.
The fact that your opponent can't fill up his day with anything
productive and thus has the time to engage in these inane arguments does
not mean that you should, too.
Tamas
From: Jon Harrop
Subject: Re: OCaml vs Haskell [was Re: What do you LISPers think of Haskell?]
Date:
Message-ID: <g96qb0$21t$2@aioe.org>
Tamas K Papp wrote:
> On Thu, 28 Aug 2008 05:05:47 -0700, parnell wrote:
>> The voted category and the installed do not show the wild fluctuations
>> of the recent or old categories. When you count the installed category
>> you are counting installs of software that is never used, completely
>> invalidating your analysis.
>
> Has is ever occurred to you that you are tirelessly arguing about a
> statistic that is quite meaningless when you consider the original
> question (popularity of programming languages)?
That was not the original question.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Jon Harrop
Subject: Re: OCaml vs Haskell [was Re: What do you LISPers think of Haskell?]
Date:
Message-ID: <g96t7q$jl4$1@aioe.org>
parnell wrote:
>> Had your previous assertion been true then I would agree but I cannot see
>> that this is the case. The "installed" data that I analyzed does not
>> trend with the "vote" data and does not correlate with the fluctuations
>> in the "recent" and "old" data. So this source of error did not affect my
>> analysis.
>
> http://people.debian.org/~igloo/popcon-graphs/index.php?packages=unis.
%2Cdarcs&show_installed=on&show_vote=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>
>
> The voted category and the installed do not show the wild fluctuations
> of the recent or old categories. When you count the installed category you
> are counting installs of software that is never used, completely
> invalidating your analysis.
The proportion of unused installs of OCaml software would have to be an
order of magnitude higher than for Haskell software to account for the
observed discrepancy. That is clearly not realistic but let's quantify it
nonetheless.
The proportion of "vote" to "install" for the various packages is currently:
libfftw3-3 9.6%
unison-gtk 15.8%
mldonkey-gui 15.8%
darcs 11.7%
freetennis 6.6%
planets 5.3%
hpodder 8.4%
ledit 9.1%
hevea 7.5%
polygen 6.7%
As you can see, there is no evidence of any discrepancy at all, let alone
the order of magnitude discrepancy required to justify your assumption.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
·······@gmail.com" <······@gmail.com> writes:
> hi Jon Harrop,
> [...]
>
> Recently, i answered to a post used your name and your photo in
> group.goople.com's profile. When i answered that post, i thought it
> was from you. Thanks for letting me know otherwise.
>
> (See:
>
> Fake Jon Harrop post
> http://groups.google.com/group/comp.lang.lisp/msg/43f971ff443e2ce5
>
> Fake Jon Harrop profile
> http://groups.google.com/groups/profile?enc_user=Cv3pMh0AAACHpIZ29S1AglWPUrDEZmMqdL-C5pPggpE8SFMrQg3Ptg
> )
Thanks for reminding me. I enjoyed reading those also a second time.
Nicolas
······@gmail.com wrote:
> For example, many commercial use of languages are not public. As a
> example, Wolfram Research, the maker of Mathematica, sells more
> Mathematica than any lisp companies combined.
> This can be gathered from company size and financial records. However,
> if you go by your methods, such as polling stats from linux distros,
> or other means of checking stats among open source communities, you
> won't find any indication of this.
I believe WRI sell products over several orders of magnitude range in cost
so I don't understand how you could have done that analysis.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: Kenny
Subject: Re: OCaml vs Haskell [was Re: What do you LISPers think of Haskell?]
Date:
Message-ID: <48c8a2e1$0$26977$607ed4bc@cv.net>
Jon Harrop wrote:
> ······@gmail.com wrote:
>
>>For example, many commercial use of languages are not public. As a
>>example, Wolfram Research, the maker of Mathematica, sells more
>>Mathematica than any lisp companies combined.
>>This can be gathered from company size and financial records. However,
>>if you go by your methods, such as polling stats from linux distros,
>>or other means of checking stats among open source communities, you
>>won't find any indication of this.
>
>
> I believe WRI sell products over several orders of magnitude range in cost
> so I don't understand how you could have done that analysis.
>
Maybe he struck a balance:
http://smuglispweeny.blogspot.com/2008/09/urbbr-2-how-bad-is-this-book.html
Looks like c.l.l is the best friends you have. You should try fitting in
better, could be the first step on The Road to Recovery.
kt
Kenny wrote:
> Jon Harrop wrote:
> > ······@gmail.com wrote:
> >
> >>For example, many commercial use of languages are not public. As a
> >>example, Wolfram Research, the maker of Mathematica, sells more
> >>Mathematica than any lisp companies combined.
> >>This can be gathered from company size and financial records. However,
> >>if you go by your methods, such as polling stats from linux distros,
> >>or other means of checking stats among open source communities, you
> >>won't find any indication of this.
> >
> >
> > I believe WRI sell products over several orders of magnitude range in cost
> > so I don't understand how you could have done that analysis.
> >
>
>
> Maybe he struck a balance:
>
> http://smuglispweeny.blogspot.com/2008/09/urbbr-2-how-bad-is-this-book.html
>
>
> Looks like c.l.l is the best friends you have. You should try fitting in
> better, could be the first step on The Road to Recovery.
Bite your tongue. Would you really like to see common lisp for
scientist book spam promoted everywhere where froggy is not already
kicked out? And that leaves c.l.l only.
And guess what would froggy write about? Common lisp type system and
pattern matching libraries (Ok Marco might be pleased).
bobi
>
> kt
Slobodan Blazeski wrote:
> Bite your tongue. Would you really like to see common lisp for scientist
> book promoted everywhere?
What interesting topics would you like a book on Lisp/Scheme to cover?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Aug 27, 11:23 am, Jon Harrop <····@ffconsultancy.com> wrote:
> parnell wrote:
> >>You appear to have neglected the Ubuntu popularity contest that account
> >>for an order of magnitude more people again.
>
> > True, Ubuntu has 683367 submissions. The data gets murkier once you
> > pick through it for instance the FFTW data that you cite
> > vote old recent no files
> > Package: fftw3 139 9884 27 165142
>
> > Where
> > vote - number of people who use this package regularly;
> > old - number of people who installed, but don't use this package
> > regularly;
> > recent - number of people who upgraded this package recently;
> > no-files - number of people whose entry didn't contain enough
> > information
> > (atime and ctime were 0).
>
> > So although we have ~185,000 installs of FFTW only 139 of those
> > installs are "used".
>
> The fftw3 package transitioned to libfftw3-3 a year ago:
>
> http://people.debian.org/~igloo/popcon-graphs/index.php?packages=fftw...
> libfftw3-3&show_installed=on&want_ticks=on&from_date=&to_date=&hlght_date
> =&date_fmt=%25Y-%25m&beenhere=1
>
> So you have analysed data about the wrong package.
>
> > Surly some of the "no files" set must be used so if we use the ratio
> > of vote to old we come up with 2,322 more that most likely should be
> > in the "vote" column.
>
> The old package is now largely unused now that the transition is complete,
> yes.
>
> > You analysis of the data was not in any way thorough, your portrayal of
> > the data and the conclusions you draw about haskell on this list and in
> > your article are misleading.
>
> Let's just review the correct data from Ubuntu:
>
> rank name inst vote old recent no-files
> 1735 libfftw3-3 104150 9084 77412 8288 9366
> 7652 darcs 2998 271 2634 92 1
>
> As you can see, the "recent" column shows an even larger discrepancy: FFTW
> has two orders of magnitude more recent installs than Darcs (8,288 vs 92).
>
> Please do continue trying to disprove my findings or try to build a
> similarly objective and statistically meaningful study that contracts these
> results. I have actually tried to do this myself but I am only finding more
> and more data that substantiate my original conclusion that Haskell is not
> yet a success in this context.
>
> For example, MLDonkey alone is still seeing tens of thousands of downloads
> every month from SourceForge:
>
> http://sourceforge.net/project/stats/detail.php?group_id=156414&
> ugn=mldonkey&type=prdownload&mode=12months&package_id=0
>
> I cannot find any software written in Haskell that gets within an order of
> magnitude of that.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancyhttp://www.ffconsultancy.com/products/?u
I don't need to you just proved my point.
Your claim of "221,293 installs of popular OCaml software " is
misleading at best given that there are only 10,911 installs of FFTW
out of the 184,574, that are actually used.
Without FFTW it is not looking good for either Haskell or OCaml on the
Unbuntu side:
vote old recent no-files
Package: mldonkey 7 56 2 1
Package: mldonkey-gui 262 4498 124 0
Package: mldonkey-server 830 5130 118 0
Package: unison 930 9214 277 7
Package: darcs 271 2634 92 1
Package: hpodder 157 2913 54 0
Sure OCaml is slightly ahead but your claim was that "OCaml is 30×
more successful at creating widely-used open source software" does not
hold up.
I agree with the claim:
FFTW is 10x more successful than any other open source OCaml or
Haskell software package in the Debian/Unbuntu popcon.
From: Jon Harrop
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <g94ch7$khq$1@aioe.org>
parnell wrote:
> On Aug 27, 11:23�am, Jon Harrop <····@ffconsultancy.com> wrote:
>> Please do continue trying to disprove my findings or try to build a
>> similarly objective and statistically meaningful study that contracts
>> these results. I have actually tried to do this myself but I am only
>> finding more and more data that substantiate my original conclusion that
>> Haskell is not yet a success in this context.
>> ...
>
> I don't need to you just proved my point.
>
> Your claim of "221,293 installs of popular OCaml software " is
> misleading at best given that there are only 10,911 installs of FFTW
> out of the 184,574, that are actually used.
I made the same mistake of trying to analyse the "recent" column but any
analysis of it is fraught with problems because it is strongly dependent
upon so many irrelevant variables. That data refers to the number of users
who upgraded a package within the past month. If you trend the data it
oscillates wildly and clearly cannot be proportional to the current number
of users (which would be a much smoother function) as one might have
expected:
http://people.debian.org/~igloo/popcon-graphs/index.php?packages=unison-gtk
%2Cdarcs&show_recent=on&want_legend=on&from_date=&to_date=&hlght_date=&
date_fmt=%25Y-%25m&beenhere=1
These wild variations are due to new package releases so this does not
reflect the number of current users at all.
One could argue that the maxima in this trend may be a more accurate
reflection of the current number of users but I believe even that is very
erroneous because of the 1 month window. For example, we only upgrade every
6-12 months.
So we cannot reasonably draw any relevant conclusions from this data, at
least not for Ubuntu where such trend data is not even available (AFAIK).
> Without FFTW it is not looking good for either Haskell or OCaml on the
> Unbuntu side:
> vote old recent no-files
> Package: mldonkey 7 56 2 1
> Package: mldonkey-gui 262 4498 124 0
> Package: mldonkey-server 830 5130 118 0
> Package: unison 930 9214 277 7
Ubuntu:
1735 libfftw3-3 104150 9084 77412 8288 9366
4355 unison-gtk 10458 1380 8662 412 4
6242 mldonkey-gui 4817 264 4423 130 0
7652 darcs 2998 271 2634 92 1
7045 freetennis 3629 226 3293 110 0
6928 planets 3786 184 3511 90 1
7549 hpodder 3080 148 2870 62 0
9733 ledit 1686 106 1505 75 0
8616 hevea 2320 127 2149 44 0
8661 polygen 2289 111 2122 55 1
Debian:
1702 libfftw3-3 9449 1827 3550 2032 2040
3206 unison 2408 651 1609 148 0
4274 mldonkey-server 1305 705 527 72 1
4186 darcs 1367 240 701 426 0
10206 freetennis 250 31 189 30 0
9794 planets 271 31 187 53 0
8084 hpodder 385 144 214 27 0
4791 ledit 1037 142 758 137 0
7046 hevea 502 84 386 32 0
8292 polygen 368 68 273 27 0
> Package: darcs 271 2634 92 1
> Package: hpodder 157 2913 54 0
>
> Sure OCaml is slightly ahead but your claim was that "OCaml is 30�
> more successful at creating widely-used open source software" does not
> hold up.
Due to the aforementioned problems those data are not an accurate reflection
of anything interesting and the conclusion stands.
> I agree with the claim:
> FFTW is 10x more successful than any other open source OCaml or
> Haskell software package in the Debian/Unbuntu popcon.
You are talking about binary packages. The core of the FFTW source code is,
of course, written in OCaml. Moreover, we can quantify the number of source
code installs, which certainly does explicitly include the OCaml code. For
Debian alone, we find:
847 fftw3 15976 2305 5802 2180 5689
So the OCaml source code to FFTW is being downloaded 2,180 times per month
by Debian users alone.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
> > I don't need to you just proved my point.
>
> > Your claim of "221,293 installs of popular OCaml software " is
> > misleading at best given that there are only 10,911 installs of FFTW
> > out of the 184,574, that are actually used.
>
> I made the same mistake of trying to analyse the "recent" column but any
> analysis of it is fraught with problems because it is strongly dependent
> upon so many irrelevant variables. That data refers to the number of users
> who upgraded a package within the past month. If you trend the data it
> oscillates wildly and clearly cannot be proportional to the current number
> of users (which would be a much smoother function) as one might have
> expected:
>
> http://people.debian.org/~igloo/popcon-graphs/index.php?packages=unis...
> %2Cdarcs&show_recent=on&want_legend=on&from_date=&to_date=&hlght_date=&
> date_fmt=%25Y-%25m&beenhere=1
>
> These wild variations are due to new package releases so this does not
> reflect the number of current users at all.
>
> One could argue that the maxima in this trend may be a more accurate
> reflection of the current number of users but I believe even that is very
> erroneous because of the 1 month window. For example, we only upgrade every
> 6-12 months.
>
> So we cannot reasonably draw any relevant conclusions from this data, at
> least not for Ubuntu where such trend data is not even available (AFAIK).
>
Yes we finally agree.
> Due to the aforementioned problems those data are not an accurate reflection
> of anything interesting and the conclusion stands.
Conclusion stands, I don't think so. Remember what you just said: "we
cannot reasonably draw any relevant conclusions from this data".
If you examine the graph of the old vs the recent you see that they
are nearly the inverse of each other and as recent jumps old falls.
It would seem to be that these are caused by people who do not
otherwise use the packages updating the package and then as the
package remains unused it moves from the recent into the old category.
http://people.debian.org/~igloo/popcon-graphs/index.php?packages=unis...%2Cdarcs&show_installed=on&show_vote=on&show_old=on&show_recent=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
The voted installs seem to trend right along with the installs, so if
they are not "an accurate reflection of anything interesting" then
neither are the total installs in which case we are in complete
agreement.
> > I agree with the claim:
> > FFTW is 10x more successful than any other open source OCaml or
> > Haskell software package in the Debian/Unbuntu popcon.
>
> You are talking about binary packages. The core of the FFTW source code is,
> of course, written in OCaml. Moreover, we can quantify the number of source
> code installs, which certainly does explicitly include the OCaml code. For
> Debian alone, we find:
>
> 847 fftw3 15976 2305 5802 2180 5689
>
> So the OCaml source code to FFTW is being downloaded 2,180 times per month
> by Debian users alone.
Jon I agree 100% that FFTW is an "OCaml" package I did not mean to
imply otherwise. My point is that it is 10 times more popular than
any of the other packages that you included in your data. The other
OCaml and the Haskell packages are in the same ball park as far as
total installs or "votes" are concerned. So what one can conclude
from this is that the language that one chooses to create an open
source project in does not seem to matter nearly as much as what that
package will do (or really to be more accurate some unknown factor
that is not captured in the data).
From: Jon Harrop
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <g94o6g$4l2$1@aioe.org>
parnell wrote:
>> So we cannot reasonably draw any relevant conclusions from this data, at
>> least not for Ubuntu where such trend data is not even available (AFAIK).
>
> Yes we finally agree.
>
>> Due to the aforementioned problems those data are not an accurate
>> reflection of anything interesting and the conclusion stands.
>
> Conclusion stands, I don't think so. Remember what you just said: "we
> cannot reasonably draw any relevant conclusions from this data".
Note that I was talking about the "recent" data that you analyzed and
not the "installed" data that was analyzed in the article that I cited.
> If you examine the graph of the old vs the recent you see that they
> are nearly the inverse of each other and as recent jumps old falls.
Yes.
> It would seem to be that these are caused by people who do not
> otherwise use the packages updating the package and then as the
> package remains unused it moves from the recent into the old category.
>
> http://people.debian.org/~igloo/popcon-graphs/index.php?packages=unis..
%2Cdarcs&show_installed=on&show_vote=on&show_old=on&show_recent=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>
> The voted installs seem to trend right along with the installs,
I disagree. Indeed, over the past year the "voted" has fallen whereas
the "installs" have risen for Darcs according to the data you just cited.
From the data you cite, large fluctuations correlate between the "old"
and "recent" data and the "vote" column to a lesser degree but
the "installed" column (that I analyzed) does not exhibit these
fluctuations at all.
> so if
> they are not "an accurate reflection of anything interesting" then
> neither are the total installs in which case we are in complete
> agreement.
Had your previous assertion been true then I would agree but I cannot see
that this is the case. The "installed" data that I analyzed does not trend
with the "vote" data and does not correlate with the fluctuations in
the "recent" and "old" data. So this source of error did not affect my
analysis.
>> > I agree with the claim:
>> > FFTW is 10x more successful than any other open source OCaml or
>> > Haskell software package in the Debian/Unbuntu popcon.
>>
>> You are talking about binary packages. The core of the FFTW source code
>> is, of course, written in OCaml. Moreover, we can quantify the number of
>> source code installs, which certainly does explicitly include the OCaml
>> code. For Debian alone, we find:
>>
>> 847 � fftw3 � � � � � � � � � � � � �15976 �2305 �5802 �2180 �5689
>>
>> So the OCaml source code to FFTW is being downloaded 2,180 times per
>> month by Debian users alone.
>
> Jon I agree 100% that FFTW is an "OCaml" package I did not mean to
> imply otherwise. My point is that it is 10 times more popular than
> any of the other packages that you included in your data.
Yes.
> The other
> OCaml and the Haskell packages are in the same ball park as far as
> total installs or "votes" are concerned.
Unison also has 3x more installs than anything written in Haskell but my
original point was also that there are many more popular projects written
in OCaml than Haskell. Indeed, even excluding FFTW, open source OCaml
software on Debian+Ubuntu still has 7x more users than Haskell and that (to
me) is a very significant discrepancy. Moreover, it is an underestimate
because we have not counted several other popular OCaml projects like
MTASC, ADVI, HaXe and so on.
> So what one can conclude from this is that the language that one chooses
> to create an open source project in does not seem to matter nearly as much
> as what that package will do (or really to be more accurate some unknown
> factor that is not captured in the data).
That is only one of many possible explanations. For example, another
equally-plausible explanation is that Haskell is inherently incapable of
solving these problems in a usable way. I suspect the truth is somewhere in
between.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 28 Aug., 01:33, Jon Harrop <····@ffconsultancy.com> wrote:
> parnell wrote:
> >> So we cannot reasonably draw any relevant conclusions from this data, at
> >> least not for Ubuntu where such trend data is not even available (AFAIK).
>
> > Yes we finally agree.
>
> >> Due to the aforementioned problems those data are not an accurate
> >> reflection of anything interesting and the conclusion stands.
>
> > Conclusion stands, I don't think so. Remember what you just said: "we
> > cannot reasonably draw any relevant conclusions from this data".
>
> Note that I was talking about the "recent" data that you analyzed and
> not the "installed" data that was analyzed in the article that I cited.
>
> > If you examine the graph of the old vs the recent you see that they
> > are nearly the inverse of each other and as recent jumps old falls.
>
> Yes.
>
> > It would seem to be that these are caused by people who do not
> > otherwise use the packages updating the package and then as the
> > package remains unused it moves from the recent into the old category.
>
> >http://people.debian.org/~igloo/popcon-graphs/index.php?packages=unis..
>
> %2Cdarcs&show_installed=on&show_vote=on&show_old=on&show_recent=on&want_leg end=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>
>
>
> > The voted installs seem to trend right along with the installs,
>
> I disagree. Indeed, over the past year the "voted" has fallen whereas
> the "installs" have risen for Darcs according to the data you just cited.
>
> From the data you cite, large fluctuations correlate between the "old"
> and "recent" data and the "vote" column to a lesser degree but
> the "installed" column (that I analyzed) does not exhibit these
> fluctuations at all.
>
> > so if
> > they are not "an accurate reflection of anything interesting" then
> > neither are the total installs in which case we are in complete
> > agreement.
>
> Had your previous assertion been true then I would agree but I cannot see
> that this is the case. The "installed" data that I analyzed does not trend
> with the "vote" data and does not correlate with the fluctuations in
> the "recent" and "old" data. So this source of error did not affect my
> analysis.
>
>
>
> >> > I agree with the claim:
> >> > FFTW is 10x more successful than any other open source OCaml or
> >> > Haskell software package in the Debian/Unbuntu popcon.
>
> >> You are talking about binary packages. The core of the FFTW source code
> >> is, of course, written in OCaml. Moreover, we can quantify the number of
> >> source code installs, which certainly does explicitly include the OCaml
> >> code. For Debian alone, we find:
>
> >> 847 fftw3 15976 2305 5802 2180 5689
>
> >> So the OCaml source code to FFTW is being downloaded 2,180 times per
> >> month by Debian users alone.
>
> > Jon I agree 100% that FFTW is an "OCaml" package I did not mean to
> > imply otherwise. My point is that it is 10 times more popular than
> > any of the other packages that you included in your data.
>
> Yes.
>
> > The other
> > OCaml and the Haskell packages are in the same ball park as far as
> > total installs or "votes" are concerned.
>
> Unison also has 3x more installs than anything written in Haskell but my
> original point was also that there are many more popular projects written
> in OCaml than Haskell. Indeed, even excluding FFTW, open source OCaml
> software on Debian+Ubuntu still has 7x more users than Haskell and that (to
> me) is a very significant discrepancy. Moreover, it is an underestimate
> because we have not counted several other popular OCaml projects like
> MTASC, ADVI, HaXe and so on.
>
> > So what one can conclude from this is that the language that one chooses
> > to create an open source project in does not seem to matter nearly as much
> > as what that package will do (or really to be more accurate some unknown
> > factor that is not captured in the data).
>
> That is only one of many possible explanations. For example, another
> equally-plausible explanation is that Haskell is inherently incapable of
> solving these problems in a usable way. I suspect the truth is somewhere in
> between.
>
This (popularity of Haskell and OCAML) is completely off-topic in
comp.lang.lisp. Move to comp.lang.functional. You may advertise there.
On Tue, 19 Aug 2008 10:31:27 -0700, ssecorp wrote:
> What are you LISPers opinion of Haskell?
>
> Pros and cons compared to LISP?
I tried Haskell before CL. Most of the programming I do is the
application/implementation of numerical methods for solving economic
models.
Even though I recognize the `elegance' of certain Haskell constructs, the
language was a straitjacket for me because of two things: the type system
and the functional purity.
The type system required a lot of scaffolding (Either, Maybe, ...) when I
wanted to do something non-trivial. Indeed, Haskell makes the
construction of this scaffolding really easy, but in CL, I just find that
I don't have to do it and I can spend time writing more relevant code
instead.
Also, sometimes I had difficulty rewriting my algorithms in purely
functional ways. I agree that it can always be done, but I had to spend
a lot of time fighting Haskell.
What attracted me to Haskell initially was the elegance found in toy
examples (eg the Fibonacci series). It took me a lot of time to realize
that toy examples are, well, toy examples, and whether a language handles
them well is not relevant to problems of a larger scale. For example,
pattern matching looked fascinating, until I realized that I am not using
it that often.
Also, when I tried Haskell I didn't know about macros, which give Lisp a
lot of extra power. Now of course I would not ever use a language
without CL-like macros.
Note that I am not claiming that CL is `better', just that it suits me
better. Haskell is a fine language, and I don't intend to disparage it.
You will have to make up your own mind. I would suggest that you try
both: even if you end up using only one of them, working in the other one
for at least a month will broaden your horizons.
Best,
Tamas
On Aug 20, 4:35 pm, Tamas K Papp <······@gmail.com> wrote:
> I tried Haskell before CL. Most of the programming I do is the
> application/implementation of numerical methods for solving economic
> models.
> Even though I recognize the `elegance' of certain Haskell constructs, the
> language was a straitjacket for me because of two things: the type system
> and the functional purity.
That's weird. Functional languages abstractions and syntax should go
hand-to-hand with numerical problems such as those you describe.
> The type system required a lot of scaffolding (Either, Maybe, ...) when I
> wanted to do something non-trivial.
You mean IO?
> Also, sometimes I had difficulty rewriting my algorithms in purely
> functional ways. I agree that it can always be done, but I had to spend
> a lot of time fighting Haskell.
That doesn't make any sense: you don't fight Haskell when writing in
purely functional ways, only when allowing mutation and side-effects
in. And since you're mostly dealing with numerical computations and
algorithms, I believe IO would be very limited to just a few sections,
like reading lots of data from external sources and generating output.
> For example,
> pattern matching looked fascinating, until I realized that I am not using
> it that often.
Perhaps because you're programming in Haskell as if it was Lisp?
On Wed, 20 Aug 2008 13:36:12 -0700, namekuseijin wrote:
> On Aug 20, 4:35 pm, Tamas K Papp <······@gmail.com> wrote:
>> I tried Haskell before CL. Most of the programming I do is the
>> application/implementation of numerical methods for solving economic
>> models.
>
>> Even though I recognize the `elegance' of certain Haskell constructs,
>> the language was a straitjacket for me because of two things: the type
>> system and the functional purity.
>
> That's weird. Functional languages abstractions and syntax should go
> hand-to-hand with numerical problems such as those you describe.
Sometimes they do, sometimes they don't. You can always write the
problem in purely functional ways, but sometimes that required quite a
bit of effort. For example, something like using a simple hash table
(which is still "provisional") requires IO. Things like that were a pain.
>> The type system required a lot of scaffolding (Either, Maybe, ...) when
>> I wanted to do something non-trivial.
>
> You mean IO?
Nope, I mean handling cases when a non-numerical result needs to be
returned or handled. Think of using nil to indicate a missing number in
Lisp: in Haskell you would need a Maybe. Or think of a function that
could take a real number or a list, for that I had to use Either. Things
like this got tiresome after a while. But this was not why I stopped
using the language.
>> Also, sometimes I had difficulty rewriting my algorithms in purely
>> functional ways. I agree that it can always be done, but I had to
>> spend a lot of time fighting Haskell.
>
> That doesn't make any sense: you don't fight Haskell when writing in
> purely functional ways, only when allowing mutation and side-effects in.
> And since you're mostly dealing with numerical computations and
> algorithms, I believe IO would be very limited to just a few sections,
> like reading lots of data from external sources and generating output.
Your beliefs do not coincide with my experience. If you have already
specified the algorithm that you are trying to implement, perhaps you can
figure out the uber-functional way to do it in the first try. But in my
line of work, you experiment with different algorithms and because you
don't know which one of them will work a priori. I find Lisp ideal for
that kind of tinkering, whereas in Haskell, I found this hard.
>> For example,
>> pattern matching looked fascinating, until I realized that I am not
>> using it that often.
>
> Perhaps because you're programming in Haskell as if it was Lisp?
If you reread my post, you will find that I started Haskell before CL.
Anyhow, please don't feel that you need to defend Haskell from me. I
emphasized that I consider Haskell a fine language, just not suitable for
my purposes. I gave Haskell an try, I used it for about 6 weeks. Of
course you can always claim that if I had used it for 6 years, I would be
more experienced and would see how to do things the Haskell way, but
honestly, I don't care. I was more productive in Lisp after a week than
in Haskell after 6 weeks.
Best,
Tamas
From: Jon Harrop
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <g8mi50$bln$2@aioe.org>
Tamas K Papp wrote:
> On Wed, 20 Aug 2008 13:36:12 -0700, namekuseijin wrote:
>> Perhaps because you're programming in Haskell as if it was Lisp?
>
> If you reread my post, you will find that I started Haskell before CL.
Sounds like you were not familiar with modern static typing though.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Aug 22, 7:24 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Tamas K Papp wrote:
> > On Wed, 20 Aug 2008 13:36:12 -0700, namekuseijin wrote:
> >> Perhaps because you're programming in Haskell as if it was Lisp?
>
> > If you reread my post, you will find that I started Haskell before CL.
>
> Sounds like you were not familiar with modern static typing though.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancyhttp://www.ffconsultancy.com/products/?u
God, you're a pompous ass!
mayson wrote:
> > Tamas K Papp wrote:
> ...
> God, you're a pompous ass!
"Lisp is as fast as Fortran for scientific computing" claims economics
student:
http://www.amazon.com/gp/pdp/profile/AO5ZHGQYTI4NE
His published software includes a sparse matrix library written in Lisp
using a hash table based representation:
http://www.princeton.edu/~tpapp/index.html
Given the context, I think my response was remarkably polite. Now, how
should I reply to his incorrect statements about the business policies of
companies with regard to research?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> Given the context, I think my response was remarkably polite.
PWUAHAHAHAHA!!!...wtf would you know about polite? That's like asking
Sarah Palin about ethical government.
hth, kenny
P� Sun, 14 Sep 2008 14:09:05 +0200, skrev Jon Harrop
<···@ffconsultancy.com>:
> mayson wrote:
>> > Tamas K Papp wrote:
>> ...
>> God, you're a pompous ass!
>
> "Lisp is as fast as Fortran for scientific computing" claims economics
> student:
>
> http://www.amazon.com/gp/pdp/profile/AO5ZHGQYTI4NE
>
> His published software includes a sparse matrix library written in Lisp
> using a hash table based representation:
>
> http://www.princeton.edu/~tpapp/index.html
>
> Given the context, I think my response was remarkably polite. Now, how
> should I reply to his incorrect statements about the business policies of
> companies with regard to research?
>
This is not entirely untrue. Like Fortran and unlike C it can use size
declaration to optimize floating point operations to allow several low
precision computations to run in parallel. Of course you need a compiler
that was optimized for numerical computing to get good results. CMUCL was
originally designed for numerical computing and so is the SBCL branch.
These compilers are better at type inference than the others.
Though getting the same performance as Fortran is a bit of a stretch
except perhaps for a few short examples.
--------------
John Thingstad
On Sun, 14 Sep 2008 14:47:46 +0200, John Thingstad wrote:
> På Sun, 14 Sep 2008 14:09:05 +0200, skrev Jon Harrop
> <···@ffconsultancy.com>:
>
>> mayson wrote:
>>> > Tamas K Papp wrote:
>>> ...
>>> God, you're a pompous ass!
>>
>> "Lisp is as fast as Fortran for scientific computing" claims economics
>> student:
>>
>> http://www.amazon.com/gp/pdp/profile/AO5ZHGQYTI4NE
>>
>> His published software includes a sparse matrix library written in Lisp
>> using a hash table based representation:
>>
>> http://www.princeton.edu/~tpapp/index.html
>>
>> Given the context, I think my response was remarkably polite. Now, how
>> should I reply to his incorrect statements about the business policies
>> of companies with regard to research?
>>
>>
> This is not entirely untrue. Like Fortran and unlike C it can use size
> declaration to optimize floating point operations to allow several low
> precision computations to run in parallel. Of course you need a compiler
> that was optimized for numerical computing to get good results. CMUCL
> was originally designed for numerical computing and so is the SBCL
> branch. These compilers are better at type inference than the others.
>
> Though getting the same performance as Fortran is a bit of a stretch
> except perhaps for a few short examples.
Hi John and others,
I am not going to argue with JH, for one thing, I have long ago killfiled
him so I no longer see his comments. And that is a good thing, as he has
a (not-so-well) hidden agenda and is apt to distort the statements of
others, or deviate from the topic if he think this is in his interest.
For example, he quotes me as saying "Lisp is as fast as Fortran for
scientific computing", and the quotation marks imply that it is a
verbatim quote. But I never said that, what I said is "the speed of
modern CL implementations is in the same league as C and Fortran".
Distorting someone's statements and then arguing with them is not
something that should be taken seriously.
Anyhow, to clarify my statement: in the kind of scientific computing I
do, I write code to solve economic models numerically. A lot of time is
spent developing and tweaking the code. First, I usually solve a
simplified version of my model, then if the results are interesting, I
think of extensions, and solve them too. If some result looks
interesting, I try to figure out where it is coming from.
My guess would be that for every hour spent running the code, I devote
5-20 hours to programming. This is where Lisp has a spectacular
advantage to C or Fortran. I can build up a quick and dirty version of
my algorithm, then modify it on the fly. If a numerical solver does not
converge because the objective function is nasty (eg not smoothly
differentiable), I can step into a debugger and explore it. I can even
automate this process with advanced condition handling of Lisp: for
example, if I find that Powell's minpack (which I packaged as cl-minpack,
fast but not too robust) does not converge, I signal a condition, and let
Nelder-Mead (more robust, slow, does not use derivatives) take over from
there. I could cite countless other examples.
Numerical solutions are not crisp and clean, sometimes they get downright
messy. The important thing is to organize computation well, and have
good debugging facilities if something goes wrong. Lisp does a superb
job in both respects.
Now what about runtime speed? Runtime speed is important, of course.
What I find is that the big divide is between 'interpreted' and
'compiled' languages: the former are slow, the second are fast. Of
course there are differences within groups, but they don't matter that
much. Would it be nice if my programs ran, say, twice as fast? Yes.
Would I switch to Fortran or C for that? Hell, no, I would spend ages
writing and debugging code, and I would hate it, because I know I would
be doing things manually that I could automate in Lisp. I switched to CL
from R (which is a nice, friendly but interpreted language), mainly for
reasons of speed (I found out about macros and condition handling later).
I find that those who care about differences in speed that are below a
factor of 2 (or even 5) are missing the point. If you want speed and
care about nothing else, you would code in assembly, that is the
"fastest" by definition. For some projects, that is the way to go, but
not for most -- programmer time is far more valuable, and correctness of
results (which comes from debugging and testing) is invaluable.
Also, these days I find that I don't even optimize my Lisp code, if it is
fast enough. And with SBCL, it is, so why would I care?
Sorry for the long post :-)
Best,
Tamas
In article <··············@mid.individual.net>,
Tamas K Papp <······@gmail.com> wrote:
> On Sun, 14 Sep 2008 14:47:46 +0200, John Thingstad wrote:
>
> > På Sun, 14 Sep 2008 14:09:05 +0200, skrev Jon Harrop
> > <···@ffconsultancy.com>:
> >
> >> mayson wrote:
> >>> > Tamas K Papp wrote:
> >>> ...
> >>> God, you're a pompous ass!
> >>
> >> "Lisp is as fast as Fortran for scientific computing" claims economics
> >> student:
> >>
> >> http://www.amazon.com/gp/pdp/profile/AO5ZHGQYTI4NE
> >>
> >> His published software includes a sparse matrix library written in Lisp
> >> using a hash table based representation:
> >>
> >> http://www.princeton.edu/~tpapp/index.html
> >>
> >> Given the context, I think my response was remarkably polite. Now, how
> >> should I reply to his incorrect statements about the business policies
> >> of companies with regard to research?
> >>
> >>
> > This is not entirely untrue. Like Fortran and unlike C it can use size
> > declaration to optimize floating point operations to allow several low
> > precision computations to run in parallel. Of course you need a compiler
> > that was optimized for numerical computing to get good results. CMUCL
> > was originally designed for numerical computing and so is the SBCL
> > branch. These compilers are better at type inference than the others.
> >
> > Though getting the same performance as Fortran is a bit of a stretch
> > except perhaps for a few short examples.
>
> Hi John and others,
>
> I am not going to argue with JH, for one thing, I have long ago killfiled
> him so I no longer see his comments. And that is a good thing, as he has
> a (not-so-well) hidden agenda and is apt to distort the statements of
> others, or deviate from the topic if he think this is in his interest.
> For example, he quotes me as saying "Lisp is as fast as Fortran for
> scientific computing", and the quotation marks imply that it is a
> verbatim quote. But I never said that, what I said is "the speed of
> modern CL implementations is in the same league as C and Fortran".
> Distorting someone's statements and then arguing with them is not
> something that should be taken seriously.
>
> Anyhow, to clarify my statement: in the kind of scientific computing I
> do, I write code to solve economic models numerically. A lot of time is
> spent developing and tweaking the code. First, I usually solve a
> simplified version of my model, then if the results are interesting, I
> think of extensions, and solve them too. If some result looks
> interesting, I try to figure out where it is coming from.
I think it is a good sign that it works for you. (Common) Lisp had been
designed for exploratory (mostly AI) programming (there
were other design goals, too). Thus it acts as a
'tool for the mind' (not my words, but I think it fits here - Hi Ernst!).
The ability to quickly code algorithms and explore various versions
with data, the ability to extend the language into the problem
domain and the interactive nature of the implementations make
this possible. You are exactly describing this experience.
> My guess would be that for every hour spent running the code, I devote
> 5-20 hours to programming. This is where Lisp has a spectacular
> advantage to C or Fortran. I can build up a quick and dirty version of
> my algorithm, then modify it on the fly. If a numerical solver does not
> converge because the objective function is nasty (eg not smoothly
> differentiable), I can step into a debugger and explore it. I can even
> automate this process with advanced condition handling of Lisp: for
> example, if I find that Powell's minpack (which I packaged as cl-minpack,
> fast but not too robust) does not converge, I signal a condition, and let
> Nelder-Mead (more robust, slow, does not use derivatives) take over from
> there. I could cite countless other examples.
>
> Numerical solutions are not crisp and clean, sometimes they get downright
> messy. The important thing is to organize computation well, and have
> good debugging facilities if something goes wrong. Lisp does a superb
> job in both respects.
>
> Now what about runtime speed? Runtime speed is important, of course.
> What I find is that the big divide is between 'interpreted' and
> 'compiled' languages: the former are slow, the second are fast. Of
> course there are differences within groups, but they don't matter that
> much. Would it be nice if my programs ran, say, twice as fast? Yes.
> Would I switch to Fortran or C for that? Hell, no, I would spend ages
> writing and debugging code, and I would hate it, because I know I would
> be doing things manually that I could automate in Lisp. I switched to CL
> from R (which is a nice, friendly but interpreted language), mainly for
> reasons of speed (I found out about macros and condition handling later).
>
> I find that those who care about differences in speed that are below a
> factor of 2 (or even 5) are missing the point. If you want speed and
> care about nothing else, you would code in assembly, that is the
> "fastest" by definition. For some projects, that is the way to go, but
> not for most -- programmer time is far more valuable, and correctness of
> results (which comes from debugging and testing) is invaluable.
>
> Also, these days I find that I don't even optimize my Lisp code, if it is
> fast enough. And with SBCL, it is, so why would I care?
>
> Sorry for the long post :-)
>
> Best,
>
> Tamas
--
http://lispm.dyndns.org/
>>Distorting someone's statements and then arguing with them is not
>>something that should be taken seriously.
Yeah, they should, that's where Americans get their presidents.
hth, kenny
On Sun, 14 Sep 2008 12:55:25 -0400, Kenny <·········@gmail.com> wrote:
>
>>>Distorting someone's statements and then arguing with them is not
>>>something that should be taken seriously.
>
>Yeah, they should, that's where Americans get their presidents.
>
Nope. Americans generally favor style over substance. They routinely
elect the candidates who make the most grandiose promises ...
regardless of whether those candidates have any chance of actually
delivering on them.
George
From: Kenny
Subject: Web2 [was/is stupid Americans [was Re: Lisp as a tool for the mind]]
Date:
Message-ID: <48cd88a4$0$13873$607ed4bc@cv.net>
George Neuner wrote:
> On Sun, 14 Sep 2008 12:55:25 -0400, Kenny <·········@gmail.com> wrote:
>
>
>>>>Distorting someone's statements and then arguing with them is not
>>>>something that should be taken seriously.
>>
>>Yeah, they should, that's where Americans get their presidents.
>>
>
>
> Nope. Americans generally favor style over substance. They routinely
> elect the candidates who make the most grandiose promises ...
Please. Republicans so not promise anything. They scream apple pie the
loudest and wave the flag hardest. That is about as subtle as we get in
our thinking, that and who we would like party with or poke.
Reagab/Clinton/Bush2/Palin yes, Dukakis/Bush1/Gore/Kerry no. So that is
McCains problem, all he has is the POW sob thing.
You have England to blame, they sent all the worst over here so we could
rule the world. Or was that Australia? We got the religious nutjobs who
elected Bush2 and in the 21st century want to teach creationism and see
images of Jesus in tree bark. I digress. Fortunately the Chinese will be
making chop suey out of us in a decade and they are a serious
civilization, no more Dukes of Hazzard reruns -- 1900 to 2020, the
second Dark Ages?
McCain gets my vote, I want a MILF on TV for the next four at least,
maybe more if she takes the WH (one way or another). Where was I?
Oh! Web2.0, the latest addition to Kenny's Dominion... I am kicking ass
and taking numbers, of course, but what I see is a little code here, a
little code there -- where's my app? Diffuse, my friend, aka scattered.
I think we need the granularity of Ajax but we need to keep the
semantics all in one place, probably the server until Fanz gets off its
ass and does a Lisp plugin.
Yes? No? Other _________________________________________?
kt
On Sun, 14 Sep 2008 17:56:53 -0400, Kenny <·········@gmail.com> wrote:
>I want a MILF on TV for the next four at least,
>maybe more if she takes the WH (one way or another).
That would be nice. But when was the last time you saw a VP on TV
outside of a campaign? If McCain wins, we'll won't see Palin again
until 2011, and if he doesn't, we may not see her again at all.
Anyway, I think both parties suck and I don't like McCain, Obama or
Biden. I don't know enough about Palin yet to generalize - so far I
like some things she has said and I don't like others.
Anyway, we should move this to alt.politics.
George
From: Kenny
Subject: Re: Web2 [was/is stupid Americans [was Re: Lisp as a tool for the mind]]
Date:
Message-ID: <48cde913$0$15545$607ed4bc@cv.net>
George Neuner wrote:
> On Sun, 14 Sep 2008 17:56:53 -0400, Kenny <·········@gmail.com> wrote:
>
>
>>I want a MILF on TV for the next four at least,
>>maybe more if she takes the WH (one way or another).
>
>
> That would be nice. But when was the last time you saw a VP on TV
> outside of a campaign? If McCain wins,...
I am counting on him dying. Or have you not seen Goldie Hawn in
Protocol? McCain turned his campaign into a Hollywood screenplay when he
picked Palin, god bless his sanctimonious two-faced heart.
we'll won't see Palin again
> until 2011, and if he doesn't, we may not see her again at all.
Can you say "Eagleton"? Sher ya can.
>
> Anyway, I think both parties suck and I don't like McCain, Obama or
> Biden. I don't know enough about Palin yet to generalize - so far I
> like some things she has said and I don't like others.
>
> Anyway, we should move this to alt.politics.
Why? This thread is about Web2.0 programming with Lisp, and whether a
thin layer of JS glue funnellevents in one directions and HTML/js in the
other can make the web disappera the way Celtk/Cello makes Tcl/Tk disappear.
What did you think of Woodward's book?
kenny
From: Tim X
Subject: Re: Web2 [was/is stupid Americans [was Re: Lisp as a tool for the mind]]
Date:
Message-ID: <87abe9dd7g.fsf@lion.rapttech.com.au>
> On Sun, 14 Sep 2008 17:56:53 -0400, Kenny <·········@gmail.com> wrote:
>
>>I want a MILF on TV for the next four at least,
>>maybe more if she takes the WH (one way or another).
Just for you Kenny
http://www.herobuilders.com/08.htm
--
tcross (at) rapttech dot com dot au
From: David Combs
Subject: Re: Web2 [was/is stupid Americans [was Re: Lisp as a tool for the mind]]
Date:
Message-ID: <gb79cf$kl8$1@reader1.panix.com>
In article <·························@cv.net>,
Kenny <·········@gmail.com> wrote:
>George Neuner wrote:
>> On Sun, 14 Sep 2008 12:55:25 -0400, Kenny <·········@gmail.com> wrote:
>>
>>
>>>>>Distorting someone's statements and then arguing with them is not
>>>>>something that should be taken seriously.
>>>
>>>Yeah, they should, that's where Americans get their presidents.
>>>
>>
>>
>> Nope. Americans generally favor style over substance. They routinely
>> elect the candidates who make the most grandiose promises ...
>
>Please. Republicans so not promise anything. They scream apple pie the
>loudest and wave the flag hardest. That is about as subtle as we get in
>our thinking, that and who we would like party with or poke.
>Reagab/Clinton/Bush2/Palin yes, Dukakis/Bush1/Gore/Kerry no. So that is
>McCains problem, all he has is the POW sob thing.
>
>You have England to blame, they sent all the worst over here so we could
>rule the world. Or was that Australia? We got the religious nutjobs who
>elected Bush2 and in the 21st century want to teach creationism and see
>images of Jesus in tree bark. I digress. Fortunately the Chinese will be
>making chop suey out of us in a decade and they are a serious
>civilization, no more Dukes of Hazzard reruns -- 1900 to 2020, the
>second Dark Ages?
>
>McCain gets my vote,
Fool me once, blame on you;
fool me twice, blame on me;
fool me three times, ...
>I want a MILF on TV for the next four at least,
>maybe more if she takes the WH (one way or another). Where was I?
>
>Oh! Web2.0, the latest addition to Kenny's Dominion... I am kicking ass
>and taking numbers, of course, but what I see is a little code here, a
>little code there -- where's my app? Diffuse, my friend, aka scattered.
>
>I think we need the granularity of Ajax but we need to keep the
>semantics all in one place, probably the server until Fanz gets off its
>ass and does a Lisp plugin.
>
>Yes? No? Other _________________________________________?
>
>kt
On 14 Sep, 16:46, Tamas K Papp <······@gmail.com> wrote:
> For example, he quotes me as saying "Lisp is as fast as Fortran for
> scientific computing", and the quotation marks imply that it is a
> verbatim quote. But I never said that, what I said is "the speed of
> modern CL implementations is in the same league as C and Fortran".
> Distorting someone's statements and then arguing with them is not
> something that should be taken seriously.
>
> Anyhow, to clarify my statement: in the kind of scientific computing I
> do, I write code to solve economic models numerically. A lot of time is
> spent developing and tweaking the code. First, I usually solve a
> simplified version of my model, then if the results are interesting, I
> think of extensions, and solve them too. If some result looks
> interesting, I try to figure out where it is coming from.
>
> My guess would be that for every hour spent running the code, I devote
> 5-20 hours to programming. This is where Lisp has a spectacular
> advantage to C or Fortran. I can build up a quick and dirty version of
> my algorithm, then modify it on the fly. If a numerical solver does not
> converge because the objective function is nasty (eg not smoothly
> differentiable), I can step into a debugger and explore it. I can even
> automate this process with advanced condition handling of Lisp: for
> example, if I find that Powell's minpack (which I packaged as cl-minpack,
> fast but not too robust) does not converge, I signal a condition, and let
> Nelder-Mead (more robust, slow, does not use derivatives) take over from
> there. I could cite countless other examples.
>
> Numerical solutions are not crisp and clean, sometimes they get downright
> messy. The important thing is to organize computation well, and have
> good debugging facilities if something goes wrong. Lisp does a superb
> job in both respects.
>
> Now what about runtime speed? Runtime speed is important, of course.
> What I find is that the big divide is between 'interpreted' and
> 'compiled' languages: the former are slow, the second are fast. Of
> course there are differences within groups, but they don't matter that
> much. Would it be nice if my programs ran, say, twice as fast? Yes.
> Would I switch to Fortran or C for that? Hell, no, I would spend ages
> writing and debugging code, and I would hate it, because I know I would
> be doing things manually that I could automate in Lisp. I switched to CL
> from R (which is a nice, friendly but interpreted language), mainly for
> reasons of speed (I found out about macros and condition handling later).
>
> I find that those who care about differences in speed that are below a
> factor of 2 (or even 5) are missing the point. If you want speed and
> care about nothing else, you would code in assembly, that is the
> "fastest" by definition. For some projects, that is the way to go, but
> not for most -- programmer time is far more valuable, and correctness of
> results (which comes from debugging and testing) is invaluable.
>
> Also, these days I find that I don't even optimize my Lisp code, if it is
> fast enough. And with SBCL, it is, so why would I care?
In other words, your work has not been performance intensive enough
for Lisp's performance to be an impediment and you believe that you
would hate Fortran. That's fine and, in fact, is the buy-in for using
Mathematica.
However, that is completely different from your claim that "the speed
of modern CL implementations is in the same league as C and Fortran".
In particular, you have apparently not even attempted to use Fortran,
let alone produced or even cited any verifiable benchmark results to
substantiate your claim.
Cheers,
Jon.
P� Fri, 19 Sep 2008 01:55:01 +0200, skrev Dr Jon D Harrop
<··················@googlemail.com>:
> However, that is completely different from your claim that "the speed
> of modern CL implementations is in the same league as C and Fortran".
> In particular, you have apparently not even attempted to use Fortran,
> let alone produced or even cited any verifiable benchmark results to
> substantiate your claim.
You seem to completely miss the point. Mainly that it is fast enough
whereas R is too slow. Programmer productivity is more important.
This mirrors my experience. My AI programs were running to slow in Python
so I started writing them in Lisp. They are fast enough and as such it
really doesn't matter if they would be even faster in C. (I worked with
C/C++ programming for 10 years professionally so it's not for lack of
ability.)
There is a large investment in time getting to be fluent in a language so
I am not likely to shift to a different language on a whim. I also read
Knuth TAOCP for that matter and enjoy implementing things myself rather
than using libraries. Guess I am just of the old school. Like Lisp.
--------------
John Thingstad
On Thu, 18 Sep 2008 16:55:01 -0700, Dr Jon D Harrop wrote:
> In other words, your work has not been performance intensive enough for
> Lisp's performance to be an impediment and you believe that you would
> hate Fortran. That's fine and, in fact, is the buy-in for using
> Mathematica.
>
> However, that is completely different from your claim that "the speed of
> modern CL implementations is in the same league as C and Fortran". In
> particular, you have apparently not even attempted to use Fortran, let
> alone produced or even cited any verifiable benchmark results to
> substantiate your claim.
Oh dear, you changed you address or something, as you were not filtered
out by my newsreader. I will remedy that promptly.
If you think I will argue with you, you are quite mistaken. I am not
selling Lisp or Lisp consulting. I don't care a lot about convincing
others, I care about using the tool that is best for me.
Tamas
Tamas K Papp wrote:
> If you think I will argue with you, you are quite mistaken. I am not
> selling Lisp or Lisp consulting. I don't care a lot about convincing
> others, I care about using the tool that is best for me.
Then why did you put that baseless propaganda on your website?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 19 Ago, 19:31, ssecorp <············@gmail.com> wrote:
> Pros and cons compared to LISP?
If enough every-day Lispers would mention it accidentally, maybe I
would care...
-PM
On Tue, 19 Aug 2008 10:31:27 -0700, ssecorp wrote:
> What are you LISPers opinion of Haskell?
From an interview with Simon Peyton-Jones in Techworld [1]:
"People sometimes complain and say ‘I want to do this obviously sensible
thing, and Haskell doesn’t let me do it.’ And we have to say, well, that
was a place we chose not to invest effort in. It’s usually not
fundamental however, in that you can get around it in some other way."
Bondage & discipline at its best. A language that constrains your
programing to what its designers 'chose not to invest effort in' is
seriously limiting per se, since unless its designers were omniscient.
And I don't want to "get around" the language. The language should be
there for my convenience, not the other way round.
Tamas
[1] http://www.techworld.com.au/article/261007/-
z_programming_languages_haskell?pp=2
In article <··············@mid.individual.net>,
Tamas K Papp <······@gmail.com> wrote:
> On Tue, 19 Aug 2008 10:31:27 -0700, ssecorp wrote:
>
> > What are you LISPers opinion of Haskell?
>
> From an interview with Simon Peyton-Jones in Techworld [1]:
>
> "People sometimes complain and say ‘I want to do this obviously sensible
> thing, and Haskell doesn’t let me do it.’ And we have to say, well, that
> was a place we chose not to invest effort in. It’s usually not
> fundamental however, in that you can get around it in some other way."
>
> Bondage & discipline at its best. A language that constrains your
> programing to what its designers 'chose not to invest effort in' is
> seriously limiting per se, since unless its designers were omniscient.
> And I don't want to "get around" the language. The language should be
> there for my convenience, not the other way round.
>
> Tamas
>
> [1] http://www.techworld.com.au/article/261007/-
> z_programming_languages_haskell?pp=2
Haskell was designed to be the Common Lazy Typed FPL.
Single paradigm, special approach. As such it
is much deeper in its support for FP than Common Lisp,
but less broad in its support for other ways
of programming. Common Lisp has for example extensive
support for object-oriented programming built-in.
You get some flexibility Haskell from its non-strict evaluation
and type inference. Its also an experimentation vehicle
for the academic FP community. Haskell and Common Lisp
are really very very different languages.
--
http://lispm.dyndns.org/
From: Raffael Cavallaro
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <gb11up$s8e$1@aioe.org>
On 2008-09-19 14:02:40 -0400, Rainer Joswig <······@lisp.de> said:
> Its also an experimentation vehicle
> for the academic FP community.
Yes, Peyton-Jones is quite explicit about this:
"...Haskell does take kind of an extreme approach: the language is
pure, and it has a pretty sophisticated type system too. We’ve used
Haskell in effect as a laboratory for exploring advanced type system
ideas. And that can make things complicated.
I think a good point is that Haskell is a laboratory: it’s a lab to
explore ideas in. We intended it to be usable for real applications,
and I think that it definitely is, and increasingly so. But it wasn’t
intended as a product for a company that wanted to sell a language to
absolutely as many programmers as possible, in which you might take
more care to make the syntax look like C, and you might think again
about introducing complex features as you don’t want to be confusing."
From: Raffael Cavallaro
Subject: Re: What do you LISPers think of Haskell?
Date:
Message-ID: <gb16mn$e8g$1@aioe.org>
On 2008-09-19 17:01:27 -0400, "j.oke" <········@gmail.com> said:
> (Sorry, and: wow: you (and many of Common Readers here...) really need
> *that* *many* reasons to convince themselves of the right choice to
> prefer CL to [... ... ...]).
>
> I'm surpuzzled...
You miss the point. We don't need convincing at all - I've been using
lisp since the early 90's and Rainer has been using it much longer than
that.
We're simply pointing out that comparing lisp to haskell is really
apples to oranges since common lisp was not designed to be a laboratory
for programming language research (there's scheme if you're looking for
a laboratory lisp) and haskell quite explicitly was.
Peyton-Jones points out that the driving force behind haskell was to do
"one thing and do it well," in this case, the lazy pure functional
paradigm. Common lisp is an omnibus designed to do many things well, so
they're really not comparable. If you want to explore the pure
functional paradigm and/or lazy evaluation, work with haskell. If you
want a multi-paradigm language with functional features among many
others, use common lisp.