On Wednesday, 4 June 2014 at 20:10:51 UTC, Ary Borenszweig wrote:
> On 6/4/14, 3:33 PM, Craig Dillabaugh wrote:
>> On Wednesday, 4 June 2014 at 17:31:56 UTC, Ary Borenszweig wrote:
>>> On 6/4/14, 1:27 PM, Meta wrote:
>>>> On Wednesday, 4 June 2014 at 06:19:05 UTC, Andrei Alexandrescu wrote:

clip

>>
>> But using function templates and the like you can still get fairly
>> 'Python-like' code in D.  I find dealing with types to be one of the
>> areas that requires the 'least' amount of mental effort in software
>> development. I don't understand why people see 'untyped' languages as
>> simpler for the most part.
>
> I was actually talking about having to specify types everywhere, like in function signatures, the fields of classes and structs, etc.
>
> You can still have a language that feels dynamic but is statically typed. The compiler catches type-related bugs for you, and you can prototype something very fast. Then you can add type annotations (if you want). I wouldn't say this language is 'untyped'.
>
> One such language is Julia.

OK, but my point was that specifying the type (at least for me) takes an insignificant amount of time (and is very useful months down the road when I am looking at the code, trying to figure out what it is supposed to do).

When declaring a variable, in almost every case, figuring out the proper type, and writing that type takes a fraction of a second.

I brought up templates because I figured one objection to my claim would be that it is easier to write functions in Python because you don't have to specify a type.  D templates take a bit more work, but for simple tasks (like you would commonly have in a scripting situtation) they should be about as simple as their Python equivalents.

On Wednesday, 4 June 2014 at 21:02:21 UTC, Craig Dillabaugh wrote:
> However, my primary point was that adding a string to a number
> is really an 'undefined' operation.  So I don't think such
> automatic casting is (generally) helpful.

Yeah, I'm generally against it... but I have a weird view of typing.

The way I see it, you should go either strong and static or dynamic and weak - I hate the middle ground.

So, in my view:

Best (like D):
string a = "10"; int b = 20;
a + b; // compile time error: cannot do string + int

Sometimes ok (my jsvar/script language also PHP and some others):
var a = "10"; var b = 20;
a + b; // 30

Blargh (javascript):
var a = "10"; var b = 20;
a + b; // "1020"

Hatred:
var a = "10"; var b = 20;
a + b; // throws an exception at run time



The D one is best because it draws your attention to something that is imperfect immediately and reliably via a compilation error. Then you can solve it with to!int or
whatever easily.

The weak+dynamic is passable to me because it actually mostly works. The operator you choose coerces the arguments and gives something basically usable. I'd be ok if it
threw an exception in the case of a string that cannot be sanely converted to int, but if it can be made to work, just do it.

The javascript one is blargh just because + is overloaded, making it easy to accidentally do the wrong thing (this just bit me in a real world code thing like 20
minutes ago, coincidentally). But I still prefer it to the last one..

Which cares about the types enough to throw an exception, but makes you wait for runtime to tell you about it. Pain in the butt that leads to fragile code that just
breaks a lot.


For example, one version of a library returns numbers typed as strings so you do some string stuff on them... then the next version returns them typed as numbers and
the old string concat pieces now randomly break next time you run it.

Pain! If I need to know what the type is anyway, please just give me a compiler to catch this stuff.

Alas, the latter model is what Ruby and Python do :(

On 6/4/14, 6:11 PM, Craig Dillabaugh wrote:
> On Wednesday, 4 June 2014 at 20:10:51 UTC, Ary Borenszweig wrote:
>> On 6/4/14, 3:33 PM, Craig Dillabaugh wrote:
>>> On Wednesday, 4 June 2014 at 17:31:56 UTC, Ary Borenszweig wrote:
>>>> On 6/4/14, 1:27 PM, Meta wrote:
>>>>> On Wednesday, 4 June 2014 at 06:19:05 UTC, Andrei Alexandrescu wrote:
>
> clip
>
>>>
>>> But using function templates and the like you can still get fairly
>>> 'Python-like' code in D.  I find dealing with types to be one of the
>>> areas that requires the 'least' amount of mental effort in software
>>> development. I don't understand why people see 'untyped' languages as
>>> simpler for the most part.
>>
>> I was actually talking about having to specify types everywhere, like
>> in function signatures, the fields of classes and structs, etc.
>>
>> You can still have a language that feels dynamic but is statically
>> typed. The compiler catches type-related bugs for you, and you can
>> prototype something very fast. Then you can add type annotations (if
>> you want). I wouldn't say this language is 'untyped'.
>>
>> One such language is Julia.
>
> OK, but my point was that specifying the type (at least for me) takes an
> insignificant amount of time (and is very useful months down the road
> when I am looking at the code, trying to figure out what it is supposed
> to do).
>
> When declaring a variable, in almost every case, figuring out the proper
> type, and writing that type takes a fraction of a second.

The problem comes when you need to refactor your code and swap one type for another. You have to change all ocurrences of that type in that situation for another.

On Wed, Jun 04, 2014 at 19:13:32 -0300, Ary Borenszweig via Digitalmars-d-announce wrote:
> The problem comes when you need to refactor your code and swap one type for another. You have to change all ocurrences of that type in that situation for another.

That's what polymorphism and type inference is for. In Haskell at least, you rarely need to actually put types in to your source. Usually you decorate top-level API functions to make sure you got it right and for making figuring out what the type of an argument is though. And those types shouldn't be changing all that often.

--Ben

On Wednesday, 4 June 2014 at 22:13:33 UTC, Ary Borenszweig wrote:
> On 6/4/14, 6:11 PM, Craig Dillabaugh wrote:
>> On Wednesday, 4 June 2014 at 20:10:51 UTC, Ary Borenszweig wrote:
>>> On 6/4/14, 3:33 PM, Craig Dillabaugh wrote:
>>>> On Wednesday, 4 June 2014 at 17:31:56 UTC, Ary Borenszweig wrote:
>>>>> On 6/4/14, 1:27 PM, Meta wrote:
>>>>>> On Wednesday, 4 June 2014 at 06:19:05 UTC, Andrei Alexandrescu wrote:
>>
>> clip
>>
>>>>
>>>> But using function templates and the like you can still get fairly
>>>> 'Python-like' code in D.  I find dealing with types to be one of the
>>>> areas that requires the 'least' amount of mental effort in software
>>>> development. I don't understand why people see 'untyped' languages as
>>>> simpler for the most part.
>>>
>>> I was actually talking about having to specify types everywhere, like
>>> in function signatures, the fields of classes and structs, etc.
>>>
>>> You can still have a language that feels dynamic but is statically
>>> typed. The compiler catches type-related bugs for you, and you can
>>> prototype something very fast. Then you can add type annotations (if
>>> you want). I wouldn't say this language is 'untyped'.
>>>
>>> One such language is Julia.
>>
>> OK, but my point was that specifying the type (at least for me) takes an
>> insignificant amount of time (and is very useful months down the road
>> when I am looking at the code, trying to figure out what it is supposed
>> to do).
>>
>> When declaring a variable, in almost every case, figuring out the proper
>> type, and writing that type takes a fraction of a second.
>
> The problem comes when you need to refactor your code and swap one type for another. You have to change all ocurrences of that type in that situation for another.

For sure there are situations where each approach will have some
ease of implementation/maintenance advantages.

The main point I have been trying to make is that I don't personally think that static typing is any more mentally challenging than dynamic typing - in most instances.

On 6/4/2014 3:43 PM, bearophile wrote:
> Nick Sabalausky:
>
>> In my experience, using heavy dynamic typing throughout a program
>> creates far more work (mainly debugging) than it avoids. Even in tiny
>> ~100 line programs, I've spent large amounts of time tracking down
>> bugs a sane compiler would have immediately pointed out with a
>> comparatively negligible amount of my effort spent on typing.
>
> I think often this happens because you are trying to write Python/Ruby
> code like you are using C++/Java, you assume the compiler will catch
> certain kinds of bugs. If you write Python with the kind of coding
> Python requires, taking more care of the things the Python interpreter
> is not able to spot for you, you will use much less time to debug Python
> code, and the overall coding time will be quite low. In Python you write
> 2-3 lines of tests every 1 line of code, and you test every functions
> for the corner cases you can think of. You don't write more than few 3-6
> lines of code without testing them immediately. So for certain aspects
> you need more discipline to write Python, while for other things it
> needs less. For small and medium programs this leads to sufficiently
> correct Python code :-)
>

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. ;)

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

Nick Sabalausky:

> to three lines of tests for every one line of real code is considered rapid development,

My Python development is just development, it's not meant to be particularly rapid :-)

And I don't think a 3:1 ratio is too much. Among the testing code I also count the doctests, the unittests, the other tests at higher level, the logic tests done with the Python version of QuickCheck, the contracts, the class/module invariants, the loop invariants, and the safety asserts spread in the code.

Take a look at this:
http://www.sqlite.org/testing.html

>As of version 3.8.0, the SQLite library consists of approximately 84.3 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 1084 times as much test code and test scripts - 91452.5 KSLOC.<

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

On 2014-06-04 21:30, Nick Sabalausky wrote:

> In my experience, using heavy dynamic typing throughout a program
> creates far more work (mainly debugging) than it avoids. Even in tiny
> ~100 line programs, I've spent large amounts of time tracking down bugs
> a sane compiler would have immediately pointed out with a comparatively
> negligible amount of my effort spent on typing. Aside from C++ or Java,
> it's like you say: static types are one of the easiest parts to deal with.

Yeah, static typing can be a huge advantage. Currently I'm merging the latest changes in DMD to my D/Objective-C branch. I have no idea what I'm doing and fully rely on the compiler. No way in h*ll I would even think about doing that without static typing.

-- 
/Jacob Carlborg

On 2014-06-05 09:30, Andrei Alexandrescu wrote:

> 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.

Since the software we write today is so complex, even detecting the most trivial bugs are useful. We need every help we can get.

-- 
/Jacob Carlborg