On Thu, 05 Jun 2014 09:30:44 +0200
Andrei Alexandrescu via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> On 6/5/14, 7:59 AM, Nick Sabalausky wrote:
> > So let me get this straight: There are programmers out there who find the occasional type annotations on some declarations to be significantly more work than following a convention of nearly *quadrupling* the amount of code they have to write? Two to three lines of tests for every one line of real code is considered rapid development, "saving developer time", "just getting things done", etc? And all that's considered a "style" of coding?
> >
> > You're right, I really don't understand that style of coding at all. ;)
> >
> > Don't get me wrong, I am pretty big on unittests, but even still: If
> > people are trying to save developer time by replacing each minor
> > type annotation with several extra unittests (which are less
> > reliable anyway
> > - greater room for human error), then something's gone horribly
> > wrong.
> >
> >  > It's usually quite hard to explain such
> >  > differences in coding stile to people that are used to static
> >  > typing.
> >  >
> >
> > That doesn't surprise me. It's also very difficult to explain 2+2==5 to people who are accustomed to basic arithmetic. ;)
>
> I have to confess this echoes a few similar confusions I have about the use and advocacy of dynamically-typed languages. One argument I've heard a while back was that static type errors are not "proportional response" and that static types only detect the most trivial of bugs, so why bother at all. But then the heavy-handed approach to unittesting espoused by dynamic languages, of which arguably a good part would be automated by a static type system, seems to work against that argument.

Indeed. It just makes no sense to claim that using dynamic typing is simpler and easier when you're then forced to write a bunch of test code just to catch bugs that the compiler in a statically typed language would have caught for you anyway.

Though I confess what horrifies me the most about dynamic languages is code like this

if(cond)
    var = "hello world";
else
    var = 42;

The fact that an if statement could change the type of a variable is just atrocious IMHO. Maybe I've just spent too much of my time in statically typed languages, but I just do not understand the draw that dynamically typed languages have for some people. They seem to think that avoiding a few simple things that you have to do in your typical statically typed language is somehow a huge improvement when it causes them so many serious problems that static languages just don't have.

- Jonathan M Davis

Am 05.06.2014 11:42, schrieb Jonathan M Davis via Digitalmars-d-announce:
> if(cond)
>      var = "hello world";
> else
>      var = 42;
>
> The fact that an if statement could change the type of a variable is just
> atrocious IMHO. Maybe I've just spent too much of my time in statically typed
> languages, but I just do not understand the draw that dynamically typed
> languages have for some people. They seem to think that avoiding a few simple
> things that you have to do in your typical statically typed language is
> somehow a huge improvement when it causes them so many serious problems that
> static languages just don't have.

maybe some sort of misunderstanded generic style
of programming in prior D times :)

On Thursday, 5 June 2014 at 09:43:13 UTC, Jonathan M Davis via Digitalmars-d-announce wrote:
> On Thu, 05 Jun 2014 09:30:44 +0200
> Andrei Alexandrescu via Digitalmars-d-announce
> <digitalmars-d-announce@puremagic.com> wrote:
>
>> On 6/5/14, 7:59 AM, Nick Sabalausky wrote:
>> > So let me get this straight: There are programmers out there who
>> > find the occasional type annotations on some declarations to be
>> > significantly more work than following a convention of nearly
>> > *quadrupling* the amount of code they have to write? Two to three
>> > lines of tests for every one line of real code is considered rapid
>> > development, "saving developer time", "just getting things done",
>> > etc? And all that's considered a "style" of coding?
>> >
>> > You're right, I really don't understand that style of coding at
>> > all. ;)
>> >
>> > Don't get me wrong, I am pretty big on unittests, but even still: If
>> > people are trying to save developer time by replacing each minor
>> > type annotation with several extra unittests (which are less
>> > reliable anyway
>> > - greater room for human error), then something's gone horribly
>> > wrong.
>> >
>> >  > It's usually quite hard to explain such
>> >  > differences in coding stile to people that are used to static
>> >  > typing.
>> >  >
>> >
>> > That doesn't surprise me. It's also very difficult to explain
>> > 2+2==5 to people who are accustomed to basic arithmetic. ;)
>>
>> I have to confess this echoes a few similar confusions I have about
>> the use and advocacy of dynamically-typed languages. One argument
>> I've heard a while back was that static type errors are not
>> "proportional response" and that static types only detect the most
>> trivial of bugs, so why bother at all. But then the heavy-handed
>> approach to unittesting espoused by dynamic languages, of which
>> arguably a good part would be automated by a static type system,
>> seems to work against that argument.
>
> Indeed. It just makes no sense to claim that using dynamic typing is simpler
> and easier when you're then forced to write a bunch of test code just to catch
> bugs that the compiler in a statically typed language would have caught for
> you anyway.
>
> Though I confess what horrifies me the most about dynamic languages is code
> like this
>
> if(cond)
>     var = "hello world";
> else
>     var = 42;
>
> The fact that an if statement could change the type of a variable is just
> atrocious IMHO. Maybe I've just spent too much of my time in statically typed
> languages, but I just do not understand the draw that dynamically typed
> languages have for some people. They seem to think that avoiding a few simple
> things that you have to do in your typical statically typed language is
> somehow a huge improvement when it causes them so many serious problems that
> static languages just don't have.
>
> - Jonathan M Davis

No, it's not just that you're statically-minded. Your example above is definitely atrocious, and more often than not a bug.

I don't know, but the only language I've used with no static types that made me comfortable was Common Lisp. That was a long time ago, but I think it was the ease of manually testing the code in a REPL that did it. Obviously today I'd write unit tests anyway.

Atila

On Thursday, 5 June 2014 at 09:43:13 UTC, Jonathan M Davis via Digitalmars-d-announce wrote:
> if(cond)
>     var = "hello world";
> else
>     var = 42;

I've sometimes wished for this functionality. It's not even a big deal in a statically typed language with built-in algebraic types and flow-based typing. The type of var is just String|Integer, and you have to disambiguate before you use its value.

On Thu, Jun 5, 2014 at 2:42 AM, Jonathan M Davis via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:

>
> Though I confess what horrifies me the most about dynamic languages is code like this
>
> if(cond)
>     var = "hello world";
> else
>     var = 42;
>
> The fact that an if statement could change the type of a variable is just atrocious IMHO.


Yeh, that's possible, but that doesn't look like something anyone with any sense would do.

The things I found most enjoyable about working on javascript were
1) REPL / fully interactive debugger
    When you hit a break point you can just start typing regular js code
into the console to poke the state of your system.
    And the convenience of the REPL for seeing what bits of code do as you
write them.
2) Duck typing / introspection ability
    If you have a bunch of objects that have a .width property, and that's
all you care about, you can just look for that.  No need to declare an
IWidthHaver interface and make all of your objects declare that they
implement it.
3) Relative ease of writing tests
    We used the Closure compiler for the js I worked on, so it wasn't
totally wild west.  It has a fair amount of static type checking.
    But when it comes to tests, it's very convenient to just be able to
fake any object by slapping some dummy functions in between curly braces.
 For example if I want a fake "IWidthHaver" instance, I just have to write
x = { width: 10 }, and I'm done.  Plus I can monkey patch things in tests,
replacing whatever method I want with a wrapper that does some custom
monitoring before or after calling the real method.  Writing tests for C++
is a pain in the butt in comparison.

--bb

On Thursday, 5 June 2014 at 12:46:24 UTC, Atila Neves wrote:
> I don't know, but the only language I've used with no static types that made me comfortable was Common Lisp. That was a long time ago, but I think it was the ease of manually testing the code in a REPL that did it. Obviously today I'd write unit tests anyway.
>
> Atila

There are languages with good static type systems (OCaml, F#, Scala, to name a few) that have REPLs as well, and they're quite useful there too.

I'm fond of Lisp, and I think Lisp macros are very powerful and useful. I like Python's (really ISWIM's) indentation sensitive syntax. But, as someone who uses 'dynamically typed' languages daily, I think static typing is a huge win and don't understand why anyone would not want to use a language with static types, especially if they were mostly inferred and so the annotation burden was minimal. ML is the language of the future ;-)

On Thu, Jun 5, 2014 at 6:34 AM, Brian Rogoff via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

>  ML is the language of the future ;-)
>
>
Yeh, it hasn't really caught on in the first 40 years since it was invented, but I'm sure it's about to explode any day now.  :-)

--bb

On Thursday, 5 June 2014 at 13:34:03 UTC, Brian Rogoff wrote:
> On Thursday, 5 June 2014 at 12:46:24 UTC, Atila Neves wrote:
>> I don't know, but the only language I've used with no static types that made me comfortable was Common Lisp. That was a long time ago, but I think it was the ease of manually testing the code in a REPL that did it. Obviously today I'd write unit tests anyway.
>>
>> Atila
>
> There are languages with good static type systems (OCaml, F#, Scala, to name a few) that have REPLs as well, and they're quite useful there too.

Oh, I know. There's also this: http://drepl.dawg.eu/

My point was that, way back when nearly 20 years ago, manually testing the Common Lisp code I wrote one function at a time was probably the reason I was ok with not having static types. I'm not even sure I'd feel the same way now.

> I'm fond of Lisp, and I think Lisp macros are very powerful and useful. I like Python's (really ISWIM's) indentation sensitive syntax. But, as someone who uses 'dynamically typed' languages daily, I think static typing is a huge win and don't understand why anyone would not want to use a language with static types, especially if they were mostly inferred and so the annotation burden was minimal. ML is the language of the future ;-)

Yep, inferred types are a massive win in my book. Having to explicitly write types whenever I have the misfortune of writing C or old C++ is painful after C++11, D, and the very little Haskell I've done so far.

Atila

On 6/5/2014 6:31 AM, Bill Baxter via Digitalmars-d-announce wrote:
>      But when it comes to tests, it's very convenient to just be able to fake
> any object by slapping some dummy functions in between curly braces.  For
> example if I want a fake "IWidthHaver" instance, I just have to write x = {
> width: 10 }, and I'm done.  Plus I can monkey patch things in tests, replacing
> whatever method I want with a wrapper that does some custom monitoring before or
> after calling the real method.  Writing tests for C++ is a pain in the butt in
> comparison.

It's an interesting observation. It is why the functions in Warp are nearly all templates - so I can slap together dummy objects to unittest those functions.

On 2014-06-05 15:31, Bill Baxter via Digitalmars-d-announce wrote:
> On Thu, Jun 5, 2014 at 2:42 AM, Jonathan M Davis via
> Digitalmars-d-announce <digitalmars-d-announce@puremagic.com
> <mailto:digitalmars-d-announce@puremagic.com>> wrote:
>
>
>     Though I confess what horrifies me the most about dynamic languages
>     is code
>     like this
>
>     if(cond)
>          var = "hello world";
>     else
>          var = 42;
>
>     The fact that an if statement could change the type of a variable is
>     just
>     atrocious IMHO.
>
>
> Yeh, that's possible, but that doesn't look like something anyone with
> any sense would do.
>
> The things I found most enjoyable about working on javascript were
> 1) REPL / fully interactive debugger
>      When you hit a break point you can just start typing regular js
> code into the console to poke the state of your system.
>      And the convenience of the REPL for seeing what bits of code do as
> you write them.
> 2) Duck typing / introspection ability
>      If you have a bunch of objects that have a .width property, and
> that's all you care about, you can just look for that.  No need to
> declare an IWidthHaver interface and make all of your objects declare
> that they implement it.
> 3) Relative ease of writing tests
>      We used the Closure compiler for the js I worked on, so it wasn't
> totally wild west.  It has a fair amount of static type checking.
>      But when it comes to tests, it's very convenient to just be able to
> fake any object by slapping some dummy functions in between curly
> braces.  For example if I want a fake "IWidthHaver" instance, I just
> have to write x = { width: 10 }, and I'm done.  Plus I can monkey patch
> things in tests, replacing whatever method I want with a wrapper that
> does some custom monitoring before or after calling the real method.
>   Writing tests for C++ is a pain in the butt in comparison.

In D you can use a wrapper and opDispatch to delegate and intercept method calls.

-- 
/Jacob Carlborg