The Illusion of Static Typing
Jacob Cohen
languages. Don't get me wrong, I don't *hate* them, because they
really conjure very little emotion in me at all... I just don't see
how they're ever useful in any possible way, and I'm constantly
baffled by people who act like they're the second coming. It's like if
you painted spoiler tags on the back of your car so it will go faster.
In fact, not only is it pointless, it's counterproductive, because it
takes away from the real power that's available to you if you know
where to look.
I was talking to a Haskell programmer yesterday. (You know the type:
Thinks *way* too much about everything, always has this lost look in
his eyes, talks strictly in terms of category theory whenever he
realizes he's losing an argument... Never written a macro in his life.
Basically, he's going for a gold medal in the virgin olympics.) And,
you know, it really struck me how desperately he was clinging to the
fairy tale of the necessity of type declarations. I tried to explain
to him how he was completely going against the spirit of Knuth's Law
(premature optimization) but he was totally blind to it, almost like a
Holocaust denier. He just didn't understand that all static languages
are fundamentally prohibited from even being mentioned in the same
breath as a real high-level language.
And then when I tried to coerce him with concepts like interactive
development, he said (get this) "Haskell is *all about* interactive
development." He actually said that. No joke. At first I almost
laughed, and then I realized how sad it is that every time he changes
a function definition, he has to sit and wait a few minutes for his
compiler to make sense of this toy language's devilish semantics. And
then I almost cried, honestly, I almost wept for him, right there. I
could no longer bear to tell him that Haskell is just another static
language. If I'd said another word his tiny mind might have broken,
and rather than make up stupid words from category theory to pad his
academic resume, he might have jumped off a bridge. He must have known
in his heart that Haskell was a toy, and I was systematically
destroying the illusion. If only academics weren't so sensitive...
But I digress. I think the real problem is that the entire current
crop of programmers has mostly been ruined by static typing. It forces
them into boxes and poisons their tiny minds, when they'd have the
whole world to see if only they abandoned these artificial
constraints. Even scripting languages that tout themselves as
"dynamic" are really backdoor OO type systems with a nice friendly
clown face painted over the devouring static jaws. At times I think
there's no hope for computer science.
Then again, there *was* a tiny glimmer yesterday. As I continued on my
afternoon stroll, an acquaintance approached me (a non-programmer) and
informed me he was interested in Lisp. I smiled and showed him how to
install Emacs, SLIME, and naturally SBCL. He's already well on his way
to joining the ranks of good programmers. I'm thankful I had the
opportunity to save *one* person from total disaster, even if another
is probably lost forever. So rejoice with me, c.l.l, and let's nest
some parens.
Anti Vigilante
Type declarations are the redundant pedantic function form binding panic
room paganism of programming.
A type is nothing more than a name reference to a function impersonating
a paradigm. Deal with it as such,
Alan Mackenzie
> You know, c.l.l, I can't tell you how much disdain I have ....
Hmm. Why does this smell like flame bait, before I've even read to the
end of the first sentence?
> ... for static languages.
> Don't get me wrong, I don't *hate* them, because they
> really conjure very little emotion in me at all... I just don't see
> how they're ever useful in any possible way, and I'm constantly
> baffled by people who act like they're the second coming.
There are lots of different types of programming around. I wouldn't
advise you to apply for a job in safety critical programming - you know,
medical systems, weapon systems, industrial control systems, vehicle
control systems - with that sort of attitude. When the overriding
priority is to eliminate bugs, static typing is useful, since it does
away with a whole class of bugs. have you ever programmed in Ada, by the
way? ;-)
Sometimes, you need to crank every last bit of speed out of hardware.
If type checking has to be done at run time, the program's going to be
that bit slower.
> I was talking to a Haskell programmer yesterday. (You know the type:
> Thinks *way* too much about everything, always has this lost look in
> his eyes, talks strictly in terms of category theory whenever he
> realizes he's losing an argument... Never written a macro in his life.
> Basically, he's going for a gold medal in the virgin olympics.) And,
> you know, it really struck me how desperately he was clinging to the
> fairy tale of the necessity of type declarations.
Fairy tale? Actually, Haskell programmers don't do all that much type
declaration, at least not compared with Ada hackers. They let the
compiler figure it out, mostly. (Note: my Haskell experience is at the
"Hello, world!" stage.)
> I tried to explain to him how he was completely going against the
> spirit of Knuth's Law (premature optimization) but he was totally blind
> to it, almost like a Holocaust denier.
Ah, you've been reading Paul Graham. Maybe this thread should stop here,
by virtue of Godwin's law.
> He just didn't understand that all static languages are fundamentally
> prohibited from even being mentioned in the same breath as a real
> high-level language.
But I'm not sure you've understood him.
> And then when I tried to coerce him with concepts like interactive
> development, he said (get this) "Haskell is *all about* interactive
> development." He actually said that. No joke.
Yes. He's done Haskell. Have you?
> At first I almost laughed, and then I realized how sad it is that every
> time he changes a function definition, he has to sit and wait a few
> minutes for his compiler to make sense of this toy language's devilish
> semantics.
But he won't be fumbling through with a debugger at 4:00 a.m. on the day
after the release date, trying to work out why he's passed a one element
list to a function which wants just the element. This sort of argument's
being doing the rounds since Pascal was the bright new language in the
late 1970s.
Actually, Haskell's semantics are beautifully simple, crystal clear.
They were designed by mathematicians after all. They're so clear that
they enable you to work easily with sophisticated concepts such as
monads. I'm sure you could do this in Lisp too, but I'd defy anybody to
try it in Ada or C++ or Java.
> And then I almost cried, honestly, I almost wept for him, right there.
> I could no longer bear to tell him that Haskell is just another static
> language.
How much experience of statically typed languages have you?
> If I'd said another word his tiny mind might have broken, and rather
> than make up stupid words from category theory to pad his academic
> resume, he might have jumped off a bridge. He must have known in his
> heart that Haskell was a toy, and I was systematically destroying the
> illusion. If only academics weren't so sensitive...
They get sensitised by having to deal with moronic students all day long,
I think.
Have you ever studied category theory? Does it occur to you that some
knowledge of it might give you some useful insights which would enable
you to hack better?
Haskell's a brilliant language, because it lets you write programs with
fewer lines of source. Everybody knows that the number of bugs in a
program, and the speed of writing is proportional to LOC, regardless
of the source language. The biggest disadvantage with static typing is
the sheer bulk of C++'s and Java's prolix type declarations.
But programming in Haskell requires a certain intellectual prowess not
needed for languages like C or Perl or Ada. Not sure about Lisp.
> Then again, there *was* a tiny glimmer yesterday. As I continued on my
> afternoon stroll, an acquaintance approached me (a non-programmer) and
> informed me he was interested in Lisp. I smiled and showed him how to
> install Emacs, SLIME, and naturally SBCL.
Excellent man! I think ALL programmers should know some Lisp, even if
they are going to be joining the ranks of Visual Basic programmers in
real life.
--
Alan Mackenzie (Nuremberg, Germany).
Pascal J. Bourguignon
> Jacob Cohen <jlc.lar...@gmail.com> wrote:
>> You know, c.l.l, I can't tell you how much disdain I have ....
>
> Hmm. Why does this smell like flame bait, before I've even read to the
> end of the first sentence?
>
>> ... for static languages.
>
>> Don't get me wrong, I don't *hate* them, because they
>> really conjure very little emotion in me at all... I just don't see
>> how they're ever useful in any possible way, and I'm constantly
>> baffled by people who act like they're the second coming.
>
> There are lots of different types of programming around. I wouldn't
> advise you to apply for a job in safety critical programming - you know,
> medical systems, weapon systems, industrial control systems, vehicle
> control systems - with that sort of attitude. When the overriding
> priority is to eliminate bugs, static typing is useful, since it does
> away with a whole class of bugs. have you ever programmed in Ada, by the
> way? ;-)
Static analysis tools are useful, yes. But static typing alone,
closely tied to the compiler? I doubt it. (Insert Pascal Costanza's
arguments here).
RAX was a vehicule control system, wasn't it?
http://en.wikipedia.org/wiki/Deep_Space_1
It wasn't statically typed, but it was still statically analysed (and
indeed bugs were found from these analyses, if late).
--
__Pascal Bourguignon__
jacob navia
>
> There are lots of different types of programming around. I wouldn't
> advise you to apply for a job in safety critical programming - you know,
I would advise anyone against working in weapons regardless of the
programming language being used.
:-)
Alan Mackenzie
> Alan Mackenzie a ?crit :
Yes, but. This is in danger of degenerating into a wide ranging
political and philosophical, totally off-topic debate. So let's just
stop here.
> :-)
Alan Mackenzie
>> Jacob Cohen <jlc.lar...@gmail.com> wrote:
>>> You know, c.l.l, I can't tell you how much disdain I have ....
>> Hmm. Why does this smell like flame bait, before I've even read to the
>> end of the first sentence?
>>> ... for static languages.
>>> Don't get me wrong, I don't *hate* them, because they
>>> really conjure very little emotion in me at all... I just don't see
>>> how they're ever useful in any possible way, and I'm constantly
>>> baffled by people who act like they're the second coming.
>> There are lots of different types of programming around. I wouldn't
>> advise you to apply for a job in safety critical programming - you know,
>> medical systems, weapon systems, industrial control systems, vehicle
>> control systems - with that sort of attitude. When the overriding
>> priority is to eliminate bugs, static typing is useful, since it does
>> away with a whole class of bugs. have you ever programmed in Ada, by the
>> way? ;-)
> Static analysis tools are useful, yes. But static typing alone,
> closely tied to the compiler? I doubt it. (Insert Pascal Costanza's
> arguments here).
No, nothing "alone". Often all sorts of revolting things like UML and
CMM tend to come into play.
> RAX was a vehicule control system, wasn't it?
> http://en.wikipedia.org/wiki/Deep_Space_1
> It wasn't statically typed, but it was still statically analysed (and
> indeed bugs were found from these analyses, if late).
:-) Was it? Excellent! Did this static analysis cost more than static
typing would have?
Don't misundertand me. I far prefer dynamically typed languages like
Lisp; I hack Emacs, after all. But the suggestion that statically typed
languages have no legitimate place anywhere is, well, silly.
Anti Vigilante
Static typing for performance and filtering according to a standard is
great. Static typing for categorizing and turning programming into
botany... Er no thanks.
Ron Garret
wrote:
> Maybe this thread should stop here,
Yeah, it' probably should. But I'll give you long odds that it won't.
rg
Ron Garret
Not quite. The static analysis did find problems, but all those were
fixed before flight. Nonetheless, despite the fact that the code as
flown passed a then-state-of-the-art formal static analysis that
supposedly proved certain properties of the system, including, notably,
the absence of deadlocks, and despite the fact that the code passed
extensive ground-based testing, it nonetheless deadlocked in flight.
And there was a recent case of a similar thing happening in an operating
system that was supposedly statically analyzed and code-reviewed out the
wazoo.
That's the real problem with static analysis. It's not that it doesn't
give you any useful information. It does. The problem is that it lulls
you into a false sense of security, that because your code type checked
or passed some other kind of static analysis it is therefore free of
bugs. It almost certainly isn't.
rg
Pascal J. Bourguignon
You're probably right, but again, it could stop if only nobody would
feel the urge to respond...
--
__Pascal Bourguignon__
budden
&rest parameters declaration and type-of function.
Also, there are dynamic, interactive, statically typed languages.
No, not a Haskell. T-SQL of MS SQL Server.
Good implementation of static typing _does_ improve execution
speed significantly. Also it _does_ improve program safety in many
cases.
Tamas K Papp
> Good implementation of static typing _does_ improve execution speed
> significantly. Also it _does_ improve program safety in many cases.
I think those things have more to do with type inference than static
typing per se. Sure, static typing allows type inference, but there
are other ways (look at SBCL, for example).
Also, my experience (in the admittedly rather limited domain of
numerical computations) suggests that execution speed comes from
improving the algorithm, not from micro-optimizing code. For me, CL
is the best language for the former. Ostensibly "fast" languages like
Fortran are a straitjacket. Haskell is a very nice deluxe
straitjacket with a personal stereo and self-adjusting straps.
Anyhow, the above things have been said most-positive-fixnum times
before, and I don't want to contribute to another language debate.
The OP is a rather inflammatory article with very little content
anyway.
Tamas
Kaz Kylheku
> And then when I tried to coerce him with concepts like interactive
> development, he said (get this) "Haskell is *all about* interactive
> development."
Well, Haskell runs on Unix, and Unix is interactive. You've got your shell,
editor, make, ... There is all this *text*, and it's dynamically typed.
Sometimes the text is a Haskell program, sometimes it's a shell command, etc.
budden
>typing per se.
of static typing. It'd be nice to know at any time if your type
is determined or it can change.
So, I think the entire discussion is pointless. There is typing
as a property of language. And there is dynamic/static language
implementations which require less/more recompilations.
Problem is that most statically typed languages are also static.
They are inflexible and incovinient, but many people simply have
no knowledge of dynamic ones so they can't compare. Hence they
reject advantages of dynamic implementations. IMO they lose.
budden
> editor, make, ... There is all this *text*, and it's dynamically typed.
> Sometimes the text is a Haskell program, sometimes it's a shell command, etc.
directories are packages
files are symbols
make, bash, hgc, gcc are fbound
compilers are #'compile
unix is a lisp.
lisp is a unix.
C and Haskell are neither unix nor lisp.
Lisp is great :-)
Pillsy
The Haskell implementation I've played with[1] has both a compiler and
an interpreter, and you can load compiled code into the interpreter as
well as entering new definitions into it, and it has rough equivalents
of INSPECT as well.
The experience is notably inferior to the CL REPLs I've used, because
(among other things) the syntax for doing things in the interpreter is
different from the syntax you use in source files. Learning a second,
more limited variation on Haskell's already agonizingly baroque syntax
is not my idea of a good time.
Also, if there's an easy way to compile a file from inside the
interpreter I don't know what it is.
Still, it's a step up from the edit-build-test set-up you get with a
language like C.
Cheers, Pillsy
[1] GHC, the Glasgow Haskell Compiler.
Thomas A. Russ
Must.....disable......send.......key......before.....it's....too....late....
--
Thomas A. Russ, USC/Information Sciences Institute
(Darn it. I'm using an Emacs newsreader, so even with the send key
disabled, I was able to directly call MESSAGE-SEND from the lisp
prompt)
Aatu Koskensilta
> The experience is notably inferior to the CL REPLs I've used, because
> (among other things) the syntax for doing things in the interpreter is
> different from the syntax you use in source files. Learning a second,
> more limited variation on Haskell's already agonizingly baroque syntax
> is not my idea of a good time.
Haskell's syntax is hardly "agonizingly baroque". That aside, the syntax
in GHCi is essentially just ordinary Haskell within an implicit
do-block.
--
Aatu Koskensilta (aatu.kos...@uta.fi)
"Wovon mann nicht sprechen kann, dar�ber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
Dave Searles
> like a Holocaust denier.
Cool. This just might set a new record: a thread Godwinned from post one.
Usually a thread goes on for 100 or more before someone Godwins it.
Dave Searles
> Jacob Cohen <jlc.lar...@gmail.com> wrote:
>> You know, c.l.l, I can't tell you how much disdain I have ....
>
> Hmm. Why does this smell like flame bait, before I've even read to the
> end of the first sentence?
You know, flame bait's more effective if it's posted in a group where
the majority will DISagree with what it says. :)
> There are lots of different types of programming around. I wouldn't
> advise you to apply for a job in safety critical programming - you know,
> medical systems, weapon systems, industrial control systems, vehicle
> control systems - with that sort of attitude.
Really? The last time I checked, lots of those are sometimes programmed
in Lisp.
> Sometimes, you need to crank every last bit of speed out of hardware.
> If type checking has to be done at run time, the program's going to be
> that bit slower.
That's what type tags are for.
> Fairy tale? Actually, Haskell programmers don't do all that much type
> declaration, at least not compared with Ada hackers.
Ada, schmada. You should try Java.
>> I tried to explain to him how he was completely going against the
>> spirit of Knuth's Law (premature optimization) but he was totally blind
>> to it, almost like a Holocaust denier.
>
> Ah, you've been reading Paul Graham. Maybe this thread should stop here,
> by virtue of Godwin's law.
I ain't *never* seen a thread start off already Godwinned before! Are
there maybe special rules for such a case?
It's kinda like the OP scratched the 8-ball in the opening break.
>> Then again, there *was* a tiny glimmer yesterday. As I continued on my
>> afternoon stroll, an acquaintance approached me (a non-programmer) and
>> informed me he was interested in Lisp. I smiled and showed him how to
>> install Emacs, SLIME, and naturally SBCL.
>
> Excellent man!
Are you mad? If there is one sure-fire way to turn a budding young
programmer off Lisp for life, it's to expose him to that particular
environment: emacs is awful, SLIME is hard to configure, and SBCL uses
green threads on Windows.
Better would be any decent IDE plus almost any other Common Lisp, or
NetBeans + Enclojure and Clojure.
Dave Searles
> That's the real problem with static analysis. It's not that it doesn't
> give you any useful information. It does. The problem is that it lulls
> you into a false sense of security, that because your code type checked
> or passed some other kind of static analysis it is therefore free of
> bugs. It almost certainly isn't.
That is a straw-man argument. I know programmers who use static
languages (even Java) and they do not assume that if it compiles, it is
bug-free.
A.L.
Lisp is more efficient and faster than anything else
A.L.
Kaz Kylheku
> Pillsy <pill...@gmail.com> writes:
>
>> The experience is notably inferior to the CL REPLs I've used, because
>> (among other things) the syntax for doing things in the interpreter is
>> different from the syntax you use in source files. Learning a second,
>> more limited variation on Haskell's already agonizingly baroque syntax
>> is not my idea of a good time.
>
> Haskell's syntax is hardly "agonizingly baroque".
Haskell's syntax was probably designed by someone whose other hobby is
writing parser generators which general LR grammars.
Kaz Kylheku
> I know programmers
Not any that could be used as references to verify the existence of
a Dave Searles.
Ron Garret
Dave Searles <sea...@hoombah.nurt.bt.uk> wrote:
You need to look up the definition of "straw man." Just because *you*
know people who don't make this mistake doesn't mean no one does.
rg
Kaz Kylheku
> You need to look up the definition of "straw man."
Not to mention that of just about every polysyllabic word he tries to use.
Alan Mackenzie
> Learning a second, more limited variation on Haskell's already
> agonizingly baroque syntax is not my idea of a good time.
Seeing as how we're on comp.lang.lisp, surely ANY language which isn't
Lisp has "agonizingly baroque syntax" as far as a Lisp programmer is
concerned?
Pillsy
> Pillsy <pillsb...@gmail.com> wrote:
> > Learning a second, more limited variation on Haskell's already
> > agonizingly baroque syntax is not my idea of a good time.
> Seeing as how we're on comp.lang.lisp, surely ANY language which isn't
> Lisp has "agonizingly baroque syntax" as far as a Lisp programmer is
> concerned?
Not at all. Python's a good example of a non-Lisp language without
excessively complicated syntax.
Cheers,
Pillsy
Kaz Kylheku
> Pillsy <pill...@gmail.com> wrote:
>
>> Learning a second, more limited variation on Haskell's already
>> agonizingly baroque syntax is not my idea of a good time.
>
> Seeing as how we're on comp.lang.lisp, surely ANY language which isn't
> Lisp has "agonizingly baroque syntax" as far as a Lisp programmer is
> concerned?
Hadly at all, in my case here. I don't think that these have agonizingly
baroque syntax: C and C++, Modula 2, POSIX shell, Algol, BCPL, Fortran,
Modula 2, Perl, ...
Nope. Haskell syntax is singularly idiotic.
Committee-designed crap, cobbed together by autistic uber-nerds.
Dave Searles
> On 2009-09-23, Dave Searles <sea...@hoombah.nurt.bt.uk> wrote:
>> I know programmers
>
Go surf in a tsunami.
Dave Searles
> In article <h9e3gd$v2d$2...@news.eternal-september.org>,
> Dave Searles <sea...@hoombah.nurt.bt.uk> wrote:
>
>> Ron Garret wrote:
>>> That's the real problem with static analysis. It's not that it doesn't
>>> give you any useful information. It does. The problem is that it lulls
>>> you into a false sense of security, that because your code type checked
>>> or passed some other kind of static analysis it is therefore free of
>>> bugs. It almost certainly isn't.
>> That is a straw-man argument. I know programmers who use static
>> languages (even Java) and they do not assume that if it compiles, it is
>> bug-free.
>
Let me clarify, asshole:
NO experienced programmer EVER assumes that because it compiles, it's
bug-free.
Dave Searles
>
> [personal attack deleted]
Go fuck a duck-billed platypus.
Pascal J. Bourguignon
> On 2009-09-24, Alan Mackenzie <a...@muc.de> wrote:
>> Pillsy <pill...@gmail.com> wrote:
>>
>>> Learning a second, more limited variation on Haskell's already
>>> agonizingly baroque syntax is not my idea of a good time.
>>
>> Seeing as how we're on comp.lang.lisp, surely ANY language which isn't
>> Lisp has "agonizingly baroque syntax" as far as a Lisp programmer is
>> concerned?
>
> Hadly at all, in my case here. I don't think that these have agonizingly
> baroque syntax: C and C++, Modula 2, POSIX shell, Algol, BCPL, Fortran,
> Modula 2, Perl, ...
C type syntax is baroque. Otherwise nobody would have had to write
cdecl to explain what they mean.
C++ templates.
Modula-2 is ok (better than Pascal).
POSIX shell is bad.
Algol, I don't know it enough, perhaps it's worse than Pascal?
BCPL it might be better than C, I don't know.
Fortran is the ancestor, the first language for which a BNF was
invented and developed.
Perl, baroquer you die!
> Nope. Haskell syntax is singularly idiotic.
>
> Committee-designed crap, cobbed together by autistic uber-nerds.
Haskell could very well have a better syntax. I'd try Liskell first.
Baroque syntaxes don't afraid us lispers, we just wrap a sexp layer
over them and tame their syntax.
--
__Pascal Bourguignon__
Christian Lynbech
bit in argumentation level.
------------------------+-----------------------------------------------------
Christian Lynbech | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)
Alan Mackenzie
> On 2009-09-24, Alan Mackenzie <a...@muc.de> wrote:
>> Pillsy <pill...@gmail.com> wrote:
>>> Learning a second, more limited variation on Haskell's already
>>> agonizingly baroque syntax is not my idea of a good time.
>> Seeing as how we're on comp.lang.lisp, surely ANY language which isn't
>> Lisp has "agonizingly baroque syntax" as far as a Lisp programmer is
>> concerned?
> Hadly at all, in my case here. I don't think that these have agonizingly
> baroque syntax: C and C++, .....
I'm afraid they do, especially C++. I maintain Emacs's CC Mode, and I
can tell you that parsing them properly is horrendously difficult. For
example, how many arguments are there between the parenteses in this C++
snippet:
foo (bar < baz , baz > grolp)
? C++ is "soon" going to get worse. Look up C++0x (e.g. on Wikipedia)
to see how.
> ....., Modula 2, POSIX shell, Algol, BCPL, Fortran, Modula 2, Perl, ...
That would make it Modula 4, wouldn't it? ;-)
But shell script is about as baroque as you can imagine. Somehow,
though, it hangs together. Perl seems to be the same.
> Nope. Haskell syntax is singularly idiotic.
I don't see that. Care to give one or two examples of its idioticness,
together with suggestions for how it could be better?
Pillsy
[...]
> I don't see that. Care to give one or two examples of its idioticness,
> together with suggestions for how it could be better?
The bizarre behavior of the "-" operator is just completely
disgusting.
There's also a number of confusing rules about how things are allowed
to nest (no "where" clauses between guards was one that caused me a
great deal of heartburn).
Getting rid of the piles of redundant syntax would be a help. It's
incredibly unclear what the advantage of having both "where" and "let"
clauses is, for instance.
The Use any (prefix) function as an infix operator. Use any infix
operator as a prefix function. Make your own new infix operators with
whatever associativity you want! Yay?
It's too bad, because I like what I've seen of the rest of the
language. Also, it's not like there's just one or two pieces of rotten
syntax that you can learn and move on, like type declarations in C. It
seems like the madness never ends.
Cheers,
Pillsy
Ron Garret
Dave Searles <sea...@hoombah.nurt.bt.uk> wrote:
> Ron Garret wrote:
> > In article <h9e3gd$v2d$2...@news.eternal-september.org>,
> > Dave Searles <sea...@hoombah.nurt.bt.uk> wrote:
> >
> >> Ron Garret wrote:
> >>> That's the real problem with static analysis. It's not that it doesn't
> >>> give you any useful information. It does. The problem is that it lulls
> >>> you into a false sense of security, that because your code type checked
> >>> or passed some other kind of static analysis it is therefore free of
> >>> bugs. It almost certainly isn't.
> >> That is a straw-man argument. I know programmers who use static
> >> languages (even Java) and they do not assume that if it compiles, it is
> >> bug-free.
> >
> > [personal attack deleted]
>
> Let me clarify, asshole:
For the record, the "personal attack" that Dave felt this was an
appropriate response to was to say that he needed to look up the
definition of "straw man."
> NO experienced programmer EVER assumes that because it compiles, it's
> bug-free.
How do you know? Have you surveyed every experienced programmer on the
planet?
rg
Dave Searles
> [personal attack deleted]
Go play with defibrillator paddles.
Dave Searles
> In article <h9fvff$dg4$2...@news.eternal-september.org>,
> Dave Searles <sea...@hoombah.nurt.bt.uk> wrote:
>> Ron Garret wrote:
>>> In article <h9e3gd$v2d$2...@news.eternal-september.org>,
>>> Dave Searles <sea...@hoombah.nurt.bt.uk> wrote:
>>>> Ron Garret wrote:
>>>>> That's the real problem with static analysis. It's not that it doesn't
>>>>> give you any useful information. It does. The problem is that it lulls
>>>>> you into a false sense of security, that because your code type checked
>>>>> or passed some other kind of static analysis it is therefore free of
>>>>> bugs. It almost certainly isn't.
>>>> That is a straw-man argument. I know programmers who use static
>>>> languages (even Java) and they do not assume that if it compiles, it is
>>>> bug-free.
>>> [personal attack deleted]
>> Let me clarify, asshole:
>
> For the record, the "personal attack" that Dave felt this was an
But I am not.
>> NO experienced programmer EVER assumes that because it compiles, it's
>> bug-free.
>
> How do you know?
If you even need to ask, then you must not be an experienced programmer.
Pillsy
> > Dave Searles <sear...@hoombah.nurt.bt.uk> wrote:
[...]
> >> NO experienced programmer EVER assumes that because it compiles, it's
> >> bug-free.
> > How do you know?
> If you even need to ask, then you must not be an experienced programmer.
Just because a programmer has experience doesn't mean that they've
necessarily learned the right lessons from that experience.
Cheers,
Pillsy
Alan Mackenzie
>> together with suggestions for how it could be better?
> The bizarre behavior of the "-" operator is just completely
> disgusting.
Hee! OK, I can take that. It's kind of a bit like Lisp, really. I
mean,
(- 5) => -5
(- 5 0) => 5
. Hmmm.
> There's also a number of confusing rules about how things are allowed
> to nest (no "where" clauses between guards was one that caused me a
> great deal of heartburn).
I'll need to look that up.
> Getting rid of the piles of redundant syntax would be a help. It's
> incredibly unclear what the advantage of having both "where" and "let"
> clauses is, for instance.
They're the same, aren't they, except a "where" comes after the main
forms, "let" comes before. We're in violent agreement here, I think.
> The Use any (prefix) function as an infix operator. Use any infix
> operator as a prefix function. Make your own new infix operators with
> whatever associativity you want! Yay?
That's part of what it is to be a functional language. Some things just
scan better as infix operators, but sometimes you need to refer to them
as functions, like when they're a parameter to some other higher-order
function.
I actually like Haskell's syntax (despite not having hacked much more
than a "Hello, world!"), because they've taken so much care to eliminate
bloat.
> It's too bad, because I like what I've seen of the rest of the
> language. Also, it's not like there's just one or two pieces of rotten
> syntax that you can learn and move on, like type declarations in C. It
> seems like the madness never ends.
C is totally mad. You've got two distinct syntaces mixed up together,
that of normal code and that of #defines. It's a horrendous language to
parse, unless the thing doing the parsing is a compiler or equivalent.
> Cheers,
> Pillsy
vippstar
> Pillsy <pillsb...@gmail.com> wrote:
> > On Sep 24, 2:47?pm, Alan Mackenzie <a...@muc.de> wrote:
> > [...]
> >> I don't see that. ?Care to give one or two examples of its idioticness,
> >> together with suggestions for how it could be better?
> > The bizarre behavior of the "-" operator is just completely
> > disgusting.
> Hee! OK, I can take that. It's kind of a bit like Lisp, really. I
> mean,
>
> (- 5) => -5
> (- 5 0) => 5
>
> . Hmmm.
That makes much sense if (- 5 0) means 5 - 0. What's the issue here?
You can also write 5 - 0 in Haskell.
> I actually like Haskell's syntax (despite not having hacked much more
> than a "Hello, world!"), because they've taken so much care to eliminate
> bloat.
Unless you're some person with great knowledge for programming
languages I doubt you're credible (or correct) if you don't even have
experience with the language.
> > It's too bad, because I like what I've seen of the rest of the
> > language. Also, it's not like there's just one or two pieces of rotten
> > syntax that you can learn and move on, like type declarations in C. It
> > seems like the madness never ends.
>
> C is totally mad. You've got two distinct syntaces mixed up together,
> that of normal code and that of #defines. It's a horrendous language to
> parse, unless the thing doing the parsing is a compiler or equivalent.
What do you mean by two distinct syntaces? The C preprocessor doesn't
add that much to the language. To my experience newbies understand
quite easily what the C preprocessor does, and that might be because
most uses for the preprocessor are trivial. C is pretty easy to parse
for a human. C is not mad, C is most sane for what it is for.
Alan Mackenzie
> On Sep 25, 7:50?pm, Alan Mackenzie <a...@muc.de> wrote:
>> Pillsy <pillsb...@gmail.com> wrote:
>> > On Sep 24, 2:47?pm, Alan Mackenzie <a...@muc.de> wrote:
>> > [...]
>> >> I don't see that. ?Care to give one or two examples of its idioticness,
>> >> together with suggestions for how it could be better?
>> > The bizarre behavior of the "-" operator is just completely
>> > disgusting.
> What is that?
A lot of the time you've got to put parens around a -ve number. If
you're supplying -42 as an argument to foo, you've got to write
foo (-42)
, since
foo -42
would be interpreted as "subtract 42 from foo".
>> Hee! ?OK, I can take that. ?It's kind of a bit like Lisp, really. ?I
>> mean,
>> ? ?(- 5) => -5
>> ? ?(- 5 0) => 5
>> . ?Hmmm.
> That makes much sense if (- 5 0) means 5 - 0. What's the issue here?
> You can also write 5 - 0 in Haskell.
The issue is that the symbol "-" has two distinct meanings.
>> I actually like Haskell's syntax (despite not having hacked much more
>> than a "Hello, world!"), because they've taken so much care to eliminate
>> bloat.
> Unless you're some person with great knowledge for programming
> languages I doubt you're credible (or correct) if you don't even have
> experience with the language.
A fair comment in a way, but I've read Haskell. It's easier, much
easier, to read than C++.
>> > It's too bad, because I like what I've seen of the rest of the
>> > language. Also, it's not like there's just one or two pieces of rotten
>> > syntax that you can learn and move on, like type declarations in C. It
>> > seems like the madness never ends.
>> C is totally mad. ?You've got two distinct syntaces mixed up together,
>> that of normal code and that of #defines. ?It's a horrendous language to
>> parse, unless the thing doing the parsing is a compiler or equivalent.
> What do you mean by two distinct syntaces? The C preprocessor doesn't
> add that much to the language.
I maintain Emacs's CC Mode. Testing for preprocessoriness has to be done
all over the place. Preprocessor constructs stop at EOL (barring an
escaped EOL), whereas normal constructs stop at a ";" or "}". Matching braces
when there's a "}" in both arms of a #if/#else/#endif is a difficult
problem which I haven't solved yet. Sometimes a macro expands to
something which "includes its own semicolon", so that throws off the
indentation of the next line, which is interpreted as a continuation of
the previous one, for lack of a ";".
> To my experience newbies understand quite easily what the C preprocessor
> does, and that might be because most uses for the preprocessor are
> trivial. C is pretty easy to parse for a human. C is not mad, C is most
> sane for what it is for.
Every few months I get a bug report where some piece of valid C source
doesn't indented properly. They keep coming in. I keep telling myself
that, surely, I've fixed the last bug now. ;-)
Pillsy
> Pillsy <pillsb...@gmail.com> wrote:
[...]
> > The bizarre behavior of the "-" operator is just completely
> > disgusting.
> Hee! OK, I can take that. It's kind of a bit like Lisp, really. I
> mean,
> (- 5) => -5
> (- 5 0) => 5
> . Hmmm.
There's nothing unusualy about the syntax of Lisp's -, though. It's
just a function like any other. In Haskell, - is (IIRC, the only)
unary operator as well as a binary operator, so it has its own set of
syntax that's pretty screwy.
[...]
> > It's too bad, because I like what I've seen of the rest of the
> > language. Also, it's not like there's just one or two pieces of rotten
> > syntax that you can learn and move on, like type declarations in C. It
> > seems like the madness never ends.
> C is totally mad. You've got two distinct syntaces mixed up together,
> that of normal code and that of #defines.
Neither is particularly hard to understand, though, on its own. Except
for the aforementioned type declaration stuff, which is hard to read
and also introduces parsing difficulties.
I won't defend the C preprocessor beyond noting that it's not that
hard to understand what it does, because in every other respect it
sucks hardcore.
Cheers,
Pillsy
Anti Vigilante
> hard to understand what it does, because in every other respect it
> sucks hardcore.
>
> Cheers,
> Pillsy
It sucks or it has a sucky job?
Christian Lynbech
Dave> Go play with defibrillator paddles.
Relating to lisp or this news group how?
Ray Blaak
While Dave is a little touchy, I am with him on this one. I would
clarify it a bit better though:
NO experienced programmer *worth considering* EVER assumes that because
it compiles, it's bug-free.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYb...@STRIPCAPStelus.net The Rhythm has my soul.
gnubeard
> jacob navia <ja...@nospam.org> wrote:
> > Alan Mackenzie a ?crit :
> >> There are lots of different types of programming around. I wouldn't
> >> advise you to apply for a job in safety critical programming - you know,
> >> ... weapon systems
> > I would advise anyone against working in weapons regardless of the
> > programming language being used.
>
> Yes, but. This is in danger of degenerating into a wide ranging
> political and philosophical, totally off-topic debate. So let's just
> stop here.
>
> > :-)
>
> --
> Alan Mackenzie (Nuremberg, Germany).
That is PRECISELY what is useful about weapons systems - they quickly
end those long, drawn out
philosophical, political and totally off-topic debates.
vippstar
> vippstar <vipps...@gmail.com> wrote:
> >> C is totally mad. You've got two distinct syntaces mixed up together,
> >> that of normal code and that of #defines. It's a horrendous language to
> >> parse, unless the thing doing the parsing is a compiler or equivalent.
> > What do you mean by two distinct syntaces? The C preprocessor doesn't
> > add that much to the language.
>
> I maintain Emacs's CC Mode. Testing for preprocessoriness has to be done
> all over the place. Preprocessor constructs stop at EOL (barring an
> escaped EOL), whereas normal constructs stop at a ";" or "}". Matching braces
> when there's a "}" in both arms of a #if/#else/#endif is a difficult
> problem which I haven't solved yet. Sometimes a macro expands to
> something which "includes its own semicolon", so that throws off the
> indentation of the next line, which is interpreted as a continuation of
> the previous one, for lack of a ";".
and thought you meant the C preprocessor somehow makes the language
harder or madder for humans. Having written some C code, those bugs in
my syntax highlighting used to notify me of a bug in my source code.
Like you said, some macros include a semi-colon in their
macroexpansion, which is usually a bug rather than correct. If it were
the case that I was using your mode to write C code, then I'd know my
macro does this mistake when your mode doesn't indent as expected. So,
IMHO, it's better to let pathological cases not indent correctly -
it's like a "Did you really mean to write this?" note.
Raymond Wiker
> Pillsy <pill...@gmail.com> writes:
>> On Sep 25, 10:59 am, Dave Searles <sear...@hoombah.nurt.bt.uk> wrote:
>>> Ron Garret wrote:
>>> > In article <h9fvff$dg...@news.eternal-september.org>,
>>> > Dave Searles <sear...@hoombah.nurt.bt.uk> wrote:
>> [...]
>>> >> NO experienced programmer EVER assumes that because it compiles, it's
>>> >> bug-free.
>>
>>> > How do you know?
>>
>>> If you even need to ask, then you must not be an experienced programmer.
>>
>> Just because a programmer has experience doesn't mean that they've
>> necessarily learned the right lessons from that experience.
>
> While Dave is a little touchy, I am with him on this one. I would
> clarify it a bit better though:
>
> NO experienced programmer *worth considering* EVER assumes that because
> it compiles, it's bug-free.
I agree with your clarification, but it is completely different
from what was originally stated by Dave [sic].
Ron Garret
Dave Searles <sea...@hoombah.nurt.bt.uk> wrote:
> Ron Garret wrote:
> > In article <h9fvff$dg4$2...@news.eternal-september.org>,
> > Dave Searles <sea...@hoombah.nurt.bt.uk> wrote:
> >> Ron Garret wrote:
> >>> In article <h9e3gd$v2d$2...@news.eternal-september.org>,
> >>> Dave Searles <sea...@hoombah.nurt.bt.uk> wrote:
> >>>> Ron Garret wrote:
> >>>>> That's the real problem with static analysis. It's not that it doesn't
> >>>>> give you any useful information. It does. The problem is that it
> >>>>> lulls
> >>>>> you into a false sense of security, that because your code type checked
> >>>>> or passed some other kind of static analysis it is therefore free of
> >>>>> bugs. It almost certainly isn't.
> >>>> That is a straw-man argument. I know programmers who use static
> >>>> languages (even Java) and they do not assume that if it compiles, it is
> >>>> bug-free.
> >>> [personal attack deleted]
> >> Let me clarify, asshole:
> >
> > For the record, the "personal attack" that Dave felt this was an
> > appropriate response to was to say that [he was incompetent]
>
> But I am not.
That remains to be seen.
> >> NO experienced programmer EVER assumes that because it compiles, it's
> >> bug-free.
> >
> > How do you know?
>
> If you even need to ask, then you must not be an experienced programmer.
What does that have to do with anything? Why does my lack of experience
disqualify me from asking you to justify your assertions?
rg
Dave Searles
>>>>>> "Dave" == Dave Searles <sea...@hoombah.nurt.bt.uk> writes:
>
> Dave> Go play with defibrillator paddles.
>
> Relating to lisp or this news group how?
Relating to the post I followed up to. Ask that post's author how their
personal attacks relate to lisp or this news group.
Dave Searles
I'm sorry. I was unclear. By "experienced" I meant experienced, and
learned from it, to the degree that would qualify them for a serious
programming job.
Dave Searles
Wrong.
Dave Searles
> In article <h9ilsu$c3t$4...@news.eternal-september.org>,
> Dave Searles <sea...@hoombah.nurt.bt.uk> wrote:
>> Ron Garret wrote:
>>> In article <h9fvff$dg4$2...@news.eternal-september.org>,
>>> Dave Searles <sea...@hoombah.nurt.bt.uk> wrote:
>>>> Ron Garret wrote:
>>>>> In article <h9e3gd$v2d$2...@news.eternal-september.org>,
>>>>> Dave Searles <sea...@hoombah.nurt.bt.uk> wrote:
>>>>>> Ron Garret wrote:
>>>>>>> That's the real problem with static analysis. It's not that it doesn't
>>>>>>> give you any useful information. It does. The problem is that it
>>>>>>> lulls
>>>>>>> you into a false sense of security, that because your code type checked
>>>>>>> or passed some other kind of static analysis it is therefore free of
>>>>>>> bugs. It almost certainly isn't.
>>>>>> That is a straw-man argument. I know programmers who use static
>>>>>> languages (even Java) and they do not assume that if it compiles, it is
>>>>>> bug-free.
>>>>> [personal attack deleted]
>>>> Let me clarify, asshole:
>>> For the record, the "personal attack" that Dave felt this was an
>>> appropriate response to was to say that [he was incompetent]
>> But I am not.
>
No, you are.
>>>> NO experienced programmer EVER assumes that because it compiles, it's
>>>> bug-free.
>>> How do you know?
>> If you even need to ask, then you must not be an experienced programmer.
>
> What does that have to do with anything? Why does my lack of experience
> disqualify me from asking you to justify your assertions?
You've missed the point. The point is, an experienced programmer will
know that "it compiles!" is only the first step on a long road to "it
works!". Furthermore, an experienced programmer will know that an
experienced programmer knows that. If you don't know, or doubt, that,
then you logically cannot be one.
David Golden
> In Haskell, - is (IIRC, the only)
> unary operator as well as a binary operator, so it has its own set of
> syntax that's pretty screwy.
I like the apl solution best, just use a separate goddamn symbol. It's
not like it's hard to use "-" for negative and "_" for subtract. Or "�"
and "-" (as in apl) or whatever. (I'd choose "-" to be negative rather
than subtract as dealing with numeric literals from other programs is
commonplace in my field and they're of course usually going to be using
"-" for negative numbers)
[Yes I know in haskell you can use prefix "(-)" instead of infix binary
"-" and/or "negate" instead of unary "-" if you want to]
Anti Vigilante
Empires have fallen based on that kind of mental gymnastics
Ron Garret
Dave Searles <sea...@hoombah.nurt.bt.uk> wrote:
But I never said you were a liar (and claiming that I did makes you a
liar by the way). What I said was that it remains to be seen whether or
not you are incompetent. Your protests to the contrary don't carry much
weight because incompetence, like stupidity, does not yield readily to
introspection.
> >>>> NO experienced programmer EVER assumes that because it compiles, it's
> >>>> bug-free.
> >>> How do you know?
> >> If you even need to ask, then you must not be an experienced programmer.
> >
> > What does that have to do with anything? Why does my lack of experience
> > disqualify me from asking you to justify your assertions?
>
> You've missed the point. The point is, an experienced programmer will
> know that "it compiles!" is only the first step on a long road to "it
> works!".
You would think that would be true. But in many cases it isn't.
> Furthermore, an experienced programmer will know that an
> experienced programmer knows that. If you don't know, or doubt, that,
> then you logically cannot be one.
So what? I ask again, what does *my* experience (or lack thereof) have
anything to do with *your* knowledge of what *other* experienced
programmers do or do not know?
rg
Christian Lynbech
>>>>>>> "Dave" == Dave Searles <sea...@hoombah.nurt.bt.uk> writes:
>>
Dave> Go play with defibrillator paddles.
>>
>> Relating to lisp or this news group how?
Dave> Relating to the post I followed up to. Ask that post's author how
Dave> their personal attacks relate to lisp or this news group.
But I didn't make any personal attack in my post that you subsequently
responded to. Are you attacking me because of something somebody else
has been writing to you?
-- Christian
Dave Searles
> empires falling]
Don't be ridiculous. The culprits you seek are the likes of Nero,
Genghis Khan's son, and George W. Bush.
Dave Searles
>>>>>> "Dave" == Dave Searles <sea...@hoombah.nurt.bt.uk> writes:
>
>>>>>>>> "Dave" == Dave Searles <sea...@hoombah.nurt.bt.uk> writes:
> Dave> Go play with defibrillator paddles.
>>> Relating to lisp or this news group how?
>
> Dave> Relating to the post I followed up to. Ask that post's author how
> Dave> their personal attacks relate to lisp or this news group.
>
No, you are.
<m2hbus8...@defun.dk> is by you and contains a personal attack, and
is the post at issue.
Dave Searles
No, you are.
>>>>>> NO experienced programmer EVER assumes that because it compiles, it's
>>>>>> bug-free.
>>>>> How do you know?
>>>> If you even need to ask, then you must not be an experienced programmer.
>>> What does that have to do with anything? Why does my lack of experience
>>> disqualify me from asking you to justify your assertions?
>> You've missed the point. The point is, an experienced programmer will
>> know that "it compiles!" is only the first step on a long road to "it
>> works!".
>
> [says I'm a liar]
No, you are.
>> Furthermore, an experienced programmer will know that an
>> experienced programmer knows that. If you don't know, or doubt, that,
>> then you logically cannot be one.
>
> So what?
So, obviously you're too stupid to understand my point so there is
nothing to be gained by my reiterating it.
Don Geddis
> NO experienced programmer *worth considering* EVER assumes that because
> it compiles, it's bug-free.
Indeed, No True Scotsman would ever make such an assumption:
http://en.wikipedia.org/wiki/No_true_Scotsman
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
Aperture Science: we do what we must because we can. For the good of all of
us -- except the ones who are dead. -- "Still Alive", Portal
Don Geddis
> p...@informatimago.com (Pascal J. Bourguignon) writes:
>> Ron Garret <rNOS...@flownet.com> writes:
>> > In article <h9clvu$2m6h$1...@colin2.muc.de>, Alan Mackenzie <a...@muc.de> wrote:
>> >> Maybe this thread should stop here,
>> > Yeah, it' probably should. But I'll give you long odds that it won't.
>> You're probably right, but again, it could stop if only nobody would
>> feel the urge to respond...
> Must.....disable......send.......key......before.....it's....too....late....
I'm certainly not going to contribute to this continuing nonsense.
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
I believe that anything you could possibly imagine could happen, but not in the
wild, outrageous way that you describe.
-- Deep Thoughts, by Jack Handey [1999]