On 2014-06-07 06:21, Craig Dillabaugh wrote:

> Its all the fault of people texting on their cell phones and the like!
> Too much work to write proper English words.  Amirite?

I'm not so sure about that. English is full of shortenings which is proper English: do not -> don't, you are -> you're. Then, at least in the USA, abbreviations are common as well. CIA, NYPD and so on. Even the name of the country is an abbreviation :)

-- 
/Jacob Carlborg

 bearophile-

 Do you also have so much testing code in haskell?

> In my D code I have an average 2.5 lines of testing code or every 1 line of D code, probably thanks to the stronger typing of D (and I think my D/Python code is less buggy than Phobos).
>
> Bye,
> bearophile

Burp:

>  Do you also have so much testing code in haskell?

I am still a newbie in Haskell, so my Haskell usage patterns are not significant (but if you still want an answer: from what I've seen so far I need so much time and thinking to craft every single line of Haskell code that later tests are less needed).

Bye,
bearophile

Andrei's D Talk (Day 2) is up:

http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/D

Matheus.

On 6/10/14, 6:28 AM, Mattcoder wrote:
> Andrei's D Talk (Day 2) is up:
>
> http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/D
>
> Matheus.

Topics overlap a tad with NDC's so if you watched that you may want to skip over the portion between 7:41 and 15:42.

Andrei

On 05/06/2014 08:30, Andrei Alexandrescu 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.
>
>
> Andrei
>

Dicebot, Nick, Andrei: my thoughts exactly. And I get a lot of that, since my main development language (career-wise) is Java, which dynamic language proponents like to bash for it's verbosity (yes, it's more verbose that it needs to be, but still way better than a dynamic language having to write all those tests!)

I sometimes tried to convince dynamic language proponents - the ones that write unittests at least - of the benefits of static typing, by stating that static typing is really just "compile time unit-tests"! (it is actually)

It didn't work, they didn't get it...

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 6/16/2014 10:00 AM, Bruno Medeiros wrote:
>
> Java, which dynamic
> language proponents like to bash for it's verbosity

Static language proponents like to bash Java for its verbosity, too!

On 16/06/14 16:00, Bruno Medeiros wrote:

> I sometimes tried to convince dynamic language proponents - the ones
> that write unittests at least - of the benefits of static typing, by
> stating that static typing is really just "compile time unit-tests"! (it
> is actually)

You can actually do compile time unit tests in D, that is not the type system. I.e. unit tests for CTFE functions that runs at compile time. Pretty cool actually :)

-- 
/Jacob Carlborg

On 17/06/2014 07:21, Jacob Carlborg wrote:
> On 16/06/14 16:00, Bruno Medeiros wrote:
>
>> I sometimes tried to convince dynamic language proponents - the ones
>> that write unittests at least - of the benefits of static typing, by
>> stating that static typing is really just "compile time unit-tests"! (it
>> is actually)
>
> You can actually do compile time unit tests in D, that is not the type
> system. I.e. unit tests for CTFE functions that runs at compile time.
> Pretty cool actually :)
>

I know, pretty cool yeah. But specific to D, I was talking about static typing in general.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On Thursday, 5 June 2014 at 09:43:13 UTC, Jonathan M Davis via Digitalmars-d-announce 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. 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

Wouldn't static-if accomplish much of the same?

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

I understand it is horrible, and unexperienced programmers often make the mistaken of forgetting the definition of var in the *else* condition, while painstakingly try to use it *after* it.

Now the first time I saw `auto`, in D or C++, I was horrified. But in essence it is a move towards not having to think about the type, or in other cases having to actually type it out, but just have the compiler infer it auto-matically. A dynamic language is just having auto everywhere without having to type even that, and giving up compile time type checking in turn.

On the other hand, some dynamic languages allow you to restict a variable entering a function by its type. In essence, I see both static and dynamic languages trying to meet in the middle.

The middle ground is the idea that data has a type and a variable is just a reference to some data; a way for use humans to express data flow. In other words, relying more on compile-time type inference.

That is the direction I see in general; programmers more and more relying on tools and analysers to do their work.