>Strict type system allows for a maximum number of programming errors to be
>caught at compile time.
I keep hearing this statement but others would argue that programming
errors caught at compile time only form a minor subset of all errors
caught.
So, in functional programming languages with a s
On Mon, May 3, 2010 at 11:34 AM, Casey Hawthorne wrote:
> >Strict type system allows for a maximum number of programming errors to be
> caught at compile time.
>
> I keep hearing this statement but others would argue that programming
> errors caught at compile time only form a minor subset of all
Are you really sure about that... it might cause a typing error if you misspell
something.
Proposal: "The double typing error"
Kind regards,
Samuel
On 4/05/2010, at 3:34 AM, Casey Hawthorne wrote:
> I don't mean "tpynig errros".
___
Haskell-Cafe mai
On Mon, May 3, 2010 at 9:34 AM, Casey Hawthorne wrote:
>>Strict type system allows for a maximum number of programming errors to be
>>caught at compile time.
>
> I keep hearing this statement but others would argue that programming
> errors caught at compile time only form a minor subset of all e
The problem with dynamic typing is that it has a much higher chance of
having a subtle error creep into your code that can go undetected for a long
period of time. A strong type system forces the code to fail early where
it's easier to track down and fix the problem, rather than trying to perform
d
In my opinion code is 'right' when it conforms to the specification.
Haskell's type system allows the programmer to express a part of the
specification in the types, which then get checked by the
compiler/type-checker. This is where I see the biggest benefit of a
very expressive statically checked
On May 4, 2010, at 5:07 AM, Kyle Murphy wrote:
To look at the flip side of your statistics:
Compiler says my code is right => My code is actually wrong -- 40%
Compiler says my code is wrong => My code is actually right -- 5%
I'd argue this is provably wrong, as correct code by definition
wou
On Mon, May 3, 2010 at 11:07 AM, Kyle Murphy wrote:
> The problem with dynamic typing is that it has a much higher chance of
> having a subtle error creep into your code that can go undetected for a long
> period of time. A strong type system forces the code to fail early where
> it's easier to tr
lrpalmer:
> What I seem to be getting at is this plane of type systems:
>
> Constrained - Expressive
> Unreliable
> | (C)
> |(test suites)
> | (C++).
> |
On 4 May 2010 13:30, Luke Palmer wrote:
> Here is a contrived example of what I am referring to:
>
> prefac f 0 = 1
> prefac f n = n * f (n-1)
>
> fac = (\x -> x x) (\x -> prefac (x x))
I can't work out how this works (or should work rather); is it meant
to be using church numerals or something (
prefac is just a normal factorial function with recursion factored out. fix
prefac 5 gives 120, for example.
On Tue, May 4, 2010 at 12:13 AM, Ivan Miljenovic
wrote:
> On 4 May 2010 13:30, Luke Palmer wrote:
> > Here is a contrived example of what I am referring to:
> >
> > prefac f 0 = 1
> > pre
On Tue, May 4, 2010 at 12:13 AM, Ivan Miljenovic
wrote:
> On 4 May 2010 13:30, Luke Palmer wrote:
>> Here is a contrived example of what I am referring to:
>>
>> prefac f 0 = 1
>> prefac f n = n * f (n-1)
>>
>> fac = (\x -> x x) (\x -> prefac (x x))
>
> I can't work out how this works (or should
On Mon, May 3, 2010 at 10:13 PM, Ivan Miljenovic
wrote:
> On 4 May 2010 13:30, Luke Palmer wrote:
>> Here is a contrived example of what I am referring to:
>>
>> prefac f 0 = 1
>> prefac f n = n * f (n-1)
>>
>> fac = (\x -> x x) (\x -> prefac (x x))
>
> I can't work out how this works (or should
On 04/05/2010, at 13:30, Luke Palmer wrote:
> On Mon, May 3, 2010 at 11:07 AM, Kyle Murphy wrote:
>
>> The fact that it doesn't is proof enough that there's a problem
>> with it even if that problem is simply that the types you're using aren't
>> exactly correct. Further, I'd argue that in the f
14 matches
Mail list logo
