Re: Interview at Lang.NEXT

2014-07-01 Thread Sebastiaan Koppe via Digitalmars-d-announce
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.


Re: Interview at Lang.NEXT

2014-06-20 Thread Bruno Medeiros via Digitalmars-d-announce

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


Re: Interview at Lang.NEXT

2014-06-17 Thread Jacob Carlborg via Digitalmars-d-announce

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


Re: Interview at Lang.NEXT

2014-06-16 Thread Bruno Medeiros via Digitalmars-d-announce

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


Re: Interview at Lang.NEXT

2014-06-16 Thread Nick Sabalausky via Digitalmars-d-announce

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!



Re: Interview at Lang.NEXT

2014-06-10 Thread Mattcoder via Digitalmars-d-announce

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

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

Matheus.


Re: Interview at Lang.NEXT

2014-06-10 Thread Andrei Alexandrescu via Digitalmars-d-announce

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


Re: Interview at Lang.NEXT

2014-06-07 Thread Burp via Digitalmars-d-announce

 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




Re: Interview at Lang.NEXT

2014-06-07 Thread bearophile via Digitalmars-d-announce

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


Re: Interview at Lang.NEXT

2014-06-06 Thread John Colvin via Digitalmars-d-announce
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.




Re: Interview at Lang.NEXT

2014-06-06 Thread deadalnix via Digitalmars-d-announce

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.


Re: Interview at Lang.NEXT

2014-06-06 Thread deadalnix via Digitalmars-d-announce

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.


Re: Interview at Lang.NEXT

2014-06-05 Thread Nick Sabalausky via Digitalmars-d-announce

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




Re: Interview at Lang.NEXT

2014-06-05 Thread Andrei Alexandrescu via Digitalmars-d-announce

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



Re: Interview at Lang.NEXT

2014-06-05 Thread bearophile via Digitalmars-d-announce

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


Re: Interview at Lang.NEXT

2014-06-05 Thread Jacob Carlborg via Digitalmars-d-announce

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


Re: Interview at Lang.NEXT

2014-06-05 Thread Jacob Carlborg via Digitalmars-d-announce

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


Re: Interview at Lang.NEXT

2014-06-05 Thread Jonathan M Davis via Digitalmars-d-announce
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


Re: Interview at Lang.NEXT

2014-06-05 Thread dennis luehring via Digitalmars-d-announce

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



Re: Interview at Lang.NEXT

2014-06-05 Thread Bill Baxter via Digitalmars-d-announce
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


Re: Interview at Lang.NEXT

2014-06-05 Thread Brian Rogoff via Digitalmars-d-announce

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




Re: Interview at Lang.NEXT

2014-06-05 Thread Bill Baxter via Digitalmars-d-announce
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


Re: Interview at Lang.NEXT

2014-06-05 Thread Atila Neves via Digitalmars-d-announce

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



Re: Interview at Lang.NEXT

2014-06-05 Thread Walter Bright via Digitalmars-d-announce

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.




Re: Interview at Lang.NEXT

2014-06-05 Thread Jacob Carlborg via Digitalmars-d-announce

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


Re: Interview at Lang.NEXT

2014-06-05 Thread Jonathan M Davis via Digitalmars-d-announce
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


Re: Interview at Lang.NEXT

2014-06-04 Thread Joakim via Digitalmars-d-announce
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.


Re: Interview at Lang.NEXT

2014-06-04 Thread Jonathan M Davis via Digitalmars-d-announce
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


Re: Interview at Lang.NEXT

2014-06-04 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 6/4/14, 9:33 AM, Joakim 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.


FWIW I'm not sure high resolution is necessary or recommended when 
watching me :o). -- Andrei




Re: Interview at Lang.NEXT

2014-06-04 Thread Walter Bright via Digitalmars-d-announce

On 6/4/2014 2:08 AM, Andrei Alexandrescu wrote:

FWIW I'm not sure high resolution is necessary or recommended when watching me
:o). -- Andrei



I look better at low res.


Re: Interview at Lang.NEXT

2014-06-04 Thread w0rp via Digitalmars-d-announce
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.)


Re: Interview at Lang.NEXT

2014-06-04 Thread Meta via Digitalmars-d-announce
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.


Re: Interview at Lang.NEXT

2014-06-04 Thread Walter Bright via Digitalmars-d-announce

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.


Re: Interview at Lang.NEXT

2014-06-04 Thread Ary Borenszweig via Digitalmars-d-announce

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.


Re: Interview at Lang.NEXT

2014-06-04 Thread Meta via Digitalmars-d-announce

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.


Re: Interview at Lang.NEXT

2014-06-04 Thread bearophile via Digitalmars-d-announce

Meta:

and there's always std.variant.Variant when you don't want to 
bother with them.


How many good usages of D Variant do you know?

Bye,
bearophile


Re: Interview at Lang.NEXT

2014-06-04 Thread Meta via Digitalmars-d-announce

On Wednesday, 4 June 2014 at 17:57:40 UTC, Ary Borenszweig wrote:

Even in function signatures?


alias var = std.variant.Variant;

auto DoStuff(var x, var y)
{
//Do stuff with x and y
}


Re: Interview at Lang.NEXT

2014-06-04 Thread Ary Borenszweig via Digitalmars-d-announce

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?


Re: Interview at Lang.NEXT

2014-06-04 Thread Meta via Digitalmars-d-announce

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.


Re: Interview at Lang.NEXT

2014-06-04 Thread Ary Borenszweig via Digitalmars-d-announce

On 6/4/14, 2:59 PM, Meta wrote:

On Wednesday, 4 June 2014 at 17:57:40 UTC, Ary Borenszweig wrote:

Even in function signatures?


alias var = std.variant.Variant;

auto DoStuff(var x, var y)
{
 //Do stuff with x and y
}


Cool! It also looks nice too.


Re: Interview at Lang.NEXT

2014-06-04 Thread dennis luehring via Digitalmars-d-announce

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


Re: Interview at Lang.NEXT

2014-06-04 Thread Meta via Digitalmars-d-announce

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.


Re: Interview at Lang.NEXT

2014-06-04 Thread Adam D. Ruppe via Digitalmars-d-announce

On Wednesday, 4 June 2014 at 18:03:48 UTC, Ary Borenszweig wrote:

Cool! It also looks nice too.


you should check out my jsvar too

https://github.com/adamdruppe/arsd/blob/master/jsvar.d

weak typing and dynamic like javascript:

import arsd.jsvar;

void main() {
var a = 10;
var b = 20;
b += a;
b -= 4;
import std.stdio;
writeln(b);

b = [1,2,3];
b[0] *= 5;
writeln(b);

b = var.emptyObject;
b.foo = (var a) {
foreach(i; 0 .. a.get!int)
writeln(Hello);
};

b.foo()(5); // would be nice if @property worked!
}

26
[5, 2, 3]
Hello
Hello
Hello
Hello
Hello


Of course, sometimes the type still matters, like the a.get!int 
in there, but oh well.


Re: Interview at Lang.NEXT

2014-06-04 Thread bearophile via Digitalmars-d-announce

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


Re: Interview at Lang.NEXT

2014-06-04 Thread Craig Dillabaugh via Digitalmars-d-announce

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.







Re: Interview at Lang.NEXT

2014-06-04 Thread Craig Dillabaugh via Digitalmars-d-announce

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


void main() {
var a = 10;
var b = 20;
b += a;
b -= 4;
import std.stdio;
writeln(b);

b = [1,2,3];
b[0] *= 5;
writeln(b);

b = var.emptyObject;
b.foo = (var a) {
foreach(i; 0 .. a.get!int)
writeln(Hello);
};

b.foo()(5); // would be nice if @property worked!
}

26
[5, 2, 3]
Hello
Hello
Hello
Hello
Hello


Of course, sometimes the type still matters, like the a.get!int 
in there, but oh well.


But shouldn't the '26' be '1016'?


Re: Interview at Lang.NEXT

2014-06-04 Thread Adam D. Ruppe via Digitalmars-d-announce

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


Re: Interview at Lang.NEXT

2014-06-04 Thread Adam D. Ruppe via Digitalmars-d-announce

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.


Re: Interview at Lang.NEXT

2014-06-04 Thread Andrew Edwards via Digitalmars-d-announce

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


void main() {
var a = 10;
var b = 20;
b += a;
b -= 4;
import std.stdio;
writeln(b);

b = [1,2,3];
b[0] *= 5;
writeln(b);

b = var.emptyObject;
b.foo = (var a) {
foreach(i; 0 .. a.get!int)
writeln(Hello);
};

b.foo()(5); // would be nice if @property worked!
}

26
[5, 2, 3]
Hello
Hello
Hello
Hello
Hello


Of course, sometimes the type still matters, like the a.get!int in
there, but oh well.


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.


Re: Interview at Lang.NEXT

2014-06-04 Thread Nick Sabalausky via Digitalmars-d-announce

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




Re: Interview at Lang.NEXT

2014-06-04 Thread bearophile via Digitalmars-d-announce

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


Re: Interview at Lang.NEXT

2014-06-04 Thread Dicebot via Digitalmars-d-announce

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?


Re: Interview at Lang.NEXT

2014-06-04 Thread Ary Borenszweig via Digitalmars-d-announce

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.


Re: Interview at Lang.NEXT

2014-06-04 Thread Meta via Digitalmars-d-announce

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.


Re: Interview at Lang.NEXT

2014-06-04 Thread Craig Dillabaugh via Digitalmars-d-announce

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.


Re: Interview at Lang.NEXT

2014-06-04 Thread Craig Dillabaugh via Digitalmars-d-announce

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.


Re: Interview at Lang.NEXT

2014-06-04 Thread Adam D. Ruppe via Digitalmars-d-announce

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


Re: Interview at Lang.NEXT

2014-06-04 Thread Ary Borenszweig via Digitalmars-d-announce

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.




Re: Interview at Lang.NEXT

2014-06-04 Thread Ben Boeckel via Digitalmars-d-announce
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


Re: Interview at Lang.NEXT

2014-06-04 Thread Craig Dillabaugh via Digitalmars-d-announce

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.