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.

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

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

On Thursday, 5 June 2014 at 13:32:16 UTC, 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 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.
That's an advantage of an interpreted language, regardless of
typing.
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.
D's ranges are examples of this in a statically typed language.
You don't care what the type of the range is, just so long as it
has the right api.

On Wednesday, 4 June 2014 at 06:19:05 UTC, Andrei Alexandrescu
wrote:
http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/
Andrei
OK I noticed that I messed up in answering.
I was saying that you 2 seems to be confused between LLVM and
clang.

On Wednesday, 4 June 2014 at 22:02:37 UTC, Adam D. Ruppe wrote:
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
Yup, you choose the right tradeoff. I wish std.json has something
in the same style as our jsvar.
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.
We all have to handle JSON or XML or some other thing like that
at some point. When it come to these, having variant typing is
huge for ease of use.

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

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

On Thu, 05 Jun 2014 12:46:23 +
Atila Neves via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
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
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.
No, it's not just that you're statically-minded. Your example
above is definitely atrocious, and more often than not a bug.
Well, of course it's a bug (or at least _horribly_ designed code if it's not).
The problem is that it's _legal_, and while that particular example might be
obvious, more complicated code could run into the same problem in more subtle
ways, causing bugs (and you won't even see the bug until you hit that
particular code path). Static typing avoids the whole problem.
As far as I can tell, dynamic typing doesn't really give you anything of value
over static typing. It just lets you type less (and features like auto
actually make it so that statically typed languages can eliminate a lot of the
same typing that dynamic languages eliminate but without reducing type
safety). You trade in a tool that automatically catches all kinds of bugs for
you just so that you don't have to type quite so much. It makes me wonder if
the folks who like dynamic languages ever write anything larger than a simple
script (and given how often we all screw up on even simple scripts, having the
compilers help there as well is still huge). I _definitely_ don't understand
the folks who write whole products in dynamic languages.
- Jonathan M Davis

On Wed, 04 Jun 2014 07:33:01 +
Joakim via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
On Wednesday, 4 June 2014 at 06:19:05 UTC, Andrei Alexandrescu
wrote:
http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/
wtf, the Mid Quality video is 1280x720 resolution HD video,
guess they think every programmer has a super-fast internet
connection. ;) The mp4 for Android/iPhone is a bandwidth-friendly
640x360 resolution.
Well, regardless of the internet connection speeds, I would have considered
720p to be mid quality, but I work with video for a living and tend to be a
bit of a videophile. Between work and doing stuff like messing with encoding
settings for transcoding Blu-rays, I've pretty much been ruined. I practically
can't watch DVDs anymore, and even Blu-rays frequently look pretty bad to me.
But obviously, streaming high quality video over the internet can be expensive
(and networks tend to behave badly even when you're just streaming a lot of
video locally).
- Jonathan M Davis

On Wednesday, 4 June 2014 at 06:19:05 UTC, Andrei Alexandrescu
wrote:
http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/
Andrei
I never post on Reddit myself, but I noticed the guy asking about
Qt ports. Someone else can tell him about my work on DQt if they
want. My big annoyance on that at the moment is recreating the
output of moc in D, which is something I've been putting off
doing for more fun things (like the dlang.org redesign recently.)

On Wednesday, 4 June 2014 at 06:19:05 UTC, Andrei Alexandrescu
wrote:
http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/
Andrei
When that person made the statement about expressing his mental
model in a simpler way that is still somewhat fast, and then
optimizing/adding annotations/etc. after he gets it working, I
kept expecting you to mention RDMD and D's ability to be used for
scripting, and purity/nothrow/@safe/@nogc inference. This is an
advantage D has over Rust and C++. With Rust especially, there is
no way to avoid dealing with its pointer semantics, as they
permeate the language. With D, you can write in a C or even
Python-like way (while not having to worry about ownership,
memory, etc. as the GC handles it for you), but you can then
optimize and add annotations to your code to get a lot more
performance and safety once your initial implementation is
working.

On 6/4/2014 4:27 AM, w0rp wrote:
On Wednesday, 4 June 2014 at 06:19:05 UTC, Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/
Andrei
I never post on Reddit myself, but I noticed the guy asking about Qt ports.
Someone else can tell him about my work on DQt if they want. My big annoyance on
that at the moment is recreating the output of moc in D, which is something I've
been putting off doing for more fun things (like the dlang.org redesign
recently.)
Write here what you want to say, including links to your work, and I'll post it
for you.

On 6/4/14, 1:27 PM, Meta wrote:
On Wednesday, 4 June 2014 at 06:19:05 UTC, Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/
Andrei
When that person made the statement about expressing his mental model in
a simpler way that is still somewhat fast, and then optimizing/adding
annotations/etc. after he gets it working, I kept expecting you to
mention RDMD and D's ability to be used for scripting, and
purity/nothrow/@safe/@nogc inference. This is an advantage D has over
Rust and C++. With Rust especially, there is no way to avoid dealing
with its pointer semantics, as they permeate the language. With D, you
can write in a C or even Python-like way (while not having to worry
about ownership, memory, etc. as the GC handles it for you), but you can
then optimize and add annotations to your code to get a lot more
performance and safety once your initial implementation is working.
You still have to worry about types, though.

On Wednesday, 4 June 2014 at 17:31:56 UTC, Ary Borenszweig wrote:
You still have to worry about types, though.
Yes, but you can often get away without explicitly writing types
in D, and there's always std.variant.Variant when you don't want
to bother with them.

On 6/4/14, 2:50 PM, Meta wrote:
On Wednesday, 4 June 2014 at 17:31:56 UTC, Ary Borenszweig wrote:
You still have to worry about types, though.
Yes, but you can often get away without explicitly writing types in D,
and there's always std.variant.Variant when you don't want to bother
with them.
Even in function signatures?

On Wednesday, 4 June 2014 at 17:55:15 UTC, bearophile wrote:
How many good usages of D Variant do you know?
Bye,
bearophile
It depends on what you mean by a good usage. I rarely ever use
Variant, but you *can* use it if you need weak and/or dynamic
typing.

Am 04.06.2014 19:57, schrieb Meta:
On Wednesday, 4 June 2014 at 17:55:15 UTC, bearophile wrote:
How many good usages of D Variant do you know?
Bye,
bearophile
It depends on what you mean by a good usage. I rarely ever use
Variant, but you *can* use it if you need weak and/or dynamic
typing.
but D+Variant is still far away from an untyped language - because
everything needs to be based on Variant - every signature... so
it isn't an ~correct~ solution in this context

On Wednesday, 4 June 2014 at 18:01:04 UTC, dennis luehring wrote:
Am 04.06.2014 19:57, schrieb Meta:
On Wednesday, 4 June 2014 at 17:55:15 UTC, bearophile wrote:
How many good usages of D Variant do you know?
Bye,
bearophile
It depends on what you mean by a good usage. I rarely ever use
Variant, but you *can* use it if you need weak and/or dynamic
typing.
but D+Variant is still far away from an untyped language -
because
everything needs to be based on Variant - every signature... so
it isn't an ~correct~ solution in this context
You're right, but you can get fairly close. You will never be
able to completely forget about types in D.

Adam D. Ruppe:
Of course, sometimes the type still matters,
Haskell programmers have a very different attitude toward types.
They do a kind of type-driven programming, even in small
programs. They lay down the data types (like the algebraic data
types that describe the data structures of the problem), and then
let the compiler, the type errors (and even a recent feature of
the compiler named type holes) to write down the solutions and be
guided toward correct code. This is kind of the opposite of
trying to remove types using dynamic typing, and it's also far
from the kind of strong static typing you see in Ada language.
Bye,
bearophile

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:
http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/
Andrei
When that person made the statement about expressing his
mental model in
a simpler way that is still somewhat fast, and then
optimizing/adding
annotations/etc. after he gets it working, I kept expecting
you to
mention RDMD and D's ability to be used for scripting, and
purity/nothrow/@safe/@nogc inference. This is an advantage D
has over
Rust and C++. With Rust especially, there is no way to avoid
dealing
with its pointer semantics, as they permeate the language.
With D, you
can write in a C or even Python-like way (while not having to
worry
about ownership, memory, etc. as the GC handles it for you),
but you can
then optimize and add annotations to your code to get a lot
more
performance and safety once your initial implementation is
working.
You still have to worry about types, though.
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.

On Wednesday, 4 June 2014 at 18:37:24 UTC, Craig Dillabaugh wrote:
But shouldn't the '26' be '1016'?
In javascript it would, but I hate that so I did something more
sane: + always coerces both operands to be numbers, then adds
them. To get concat, we use the D operator ~.

On Wednesday, 4 June 2014 at 18:29:49 UTC, bearophile wrote:
Haskell programmers have a very different attitude toward types.
Aye, that's more like how I prefer to do it - I like to use
separate types for virtually everything in real code.

On 6/4/2014 2:33 PM, Craig Dillabaugh wrote:
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.
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.
Related note: I find it somewhat amusing (and a little depressing) that
you can always identify the inexperienced programers by pulling out the
dynamic creates more debugging work argument. The inexperienced (or
experienced-but-still-sub-par) are always the ones who then try to tell
you good programmers are better and more careful at avoiding silly
mistakes. :) (And it's often stated using poor typing skills, too.)

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 :-) It's usually quite hard to
explain such differences in coding stile to people that are used
to static typing.
Bye,
bearophile

On Wednesday, 4 June 2014 at 19:43:53 UTC, 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 :-) It's usually quite hard to explain such differences in
coding stile to people that are used to static typing.
Bye,
bearophile
I hear this concept again and again, still can't really get it.
You are trying to save some tiny portion of time of writing down
actual type to spend much more time in different mental context
to write several lines of tests to achieve exactly the same
thing? How can this ever be a reasonable trade-off?

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:
http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/
Andrei
When that person made the statement about expressing his mental model in
a simpler way that is still somewhat fast, and then optimizing/adding
annotations/etc. after he gets it working, I kept expecting you to
mention RDMD and D's ability to be used for scripting, and
purity/nothrow/@safe/@nogc inference. This is an advantage D has over
Rust and C++. With Rust especially, there is no way to avoid dealing
with its pointer semantics, as they permeate the language. With D, you
can write in a C or even Python-like way (while not having to worry
about ownership, memory, etc. as the GC handles it for you), but you can
then optimize and add annotations to your code to get a lot more
performance and safety once your initial implementation is working.
You still have to worry about types, though.
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.

On Wednesday, 4 June 2014 at 20:10:51 UTC, Ary Borenszweig wrote:
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.
Another is Haskell, a language with very strong typing.

On Wednesday, 4 June 2014 at 18:54:00 UTC, Andrew Edwards wrote:
On 6/4/14, 2:37 PM, Craig Dillabaugh wrote:
On Wednesday, 4 June 2014 at 18:14:22 UTC, Adam D. Ruppe wrote:
On Wednesday, 4 June 2014 at 18:03:48 UTC, Ary Borenszweig
wrote:
clip
But shouldn't the '26' be '1016'?
That should only occur when the concatenation operator (~) is
used, in which case the result would be '2006' not '1016'.
Since only arithmetic operators are used in this example, the
result is as expected.
I must be dyslexic .. I concatenated in the wrong way, and you
(and Adam) are both right about the ~ operator in D. 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.

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.