www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Eloquently sums up my feelings about the disadvantages of dynamic

reply Walter Bright <newshound2 digitalmars.com> writes:
http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8
Oct 15 2013
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 16.10.2013 00:15, schrieb Walter Bright:

 http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8


Agree.

While I do like dynamic languages for prototyping and small 
applications, I came to the conclusion they don't scale in the enterprise.

Plus with type inference, specially in the ML family, there is hardly 
any difference in terms of succinctness and the static languages are 
more tooling friendly.



--
Paulo
Oct 15 2013
parent reply "simendsjo" <simendsjo gmail.com> writes:
On Tuesday, 15 October 2013 at 22:31:06 UTC, Paulo Pinto wrote:

 Am 16.10.2013 00:15, schrieb Walter Bright:

 http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8


 Agree.

 While I do like dynamic languages for prototyping and small 
 applications, I came to the conclusion they don't scale in the 
 enterprise.


(...)

Haven't tried Ruby, but I switched from Python to D because of 
static typing and speed back in 2007.

Why on earth should
   someVariable = 1

   somevariable = 2
give me hard to track bugs?
Even lua requires you to say "I'm creating a *new* variable now".

And a compiler that doesn't do simple optimizations?
   for x in range(0,10):
     i = x*x


^ - might be painfully slow. You should of course code like a 
compiler and create i outside the loop!

And no types means I have to read the source for every method to 
see what types it actually expects.
Dynamic typing does not mean you don't have types to care about, 
it just means the types are hidden from sight and cause bugs at 
runtime. I will never again code in a dynamic language if I can 
avoid it. All the "advantages" of dynamic typing simply doesn't 
exist for anything other than small/trivial programs in my 
experience.

No.. Give me a language that catches obvious bugs at 
compile-time, makes code self-documenting and doesn't let me 
worry about performance.

Of course.. It might just be that I don't "get" dynamic typing :)
Oct 15 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10/16/2013 08:46 AM, simendsjo wrote:

 No.. Give me a language that catches obvious bugs at compile-time, makes
 code self-documenting and doesn't let me worry about performance.
 ...


Why just obvious bugs?
Oct 16 2013
parent reply "simendsjo" <simendsjo gmail.com> writes:
On Wednesday, 16 October 2013 at 10:37:28 UTC, Timon Gehr wrote:

 On 10/16/2013 08:46 AM, simendsjo wrote:

 No.. Give me a language that catches obvious bugs at 
 compile-time, makes
 code self-documenting and doesn't let me worry about 
 performance.
 ...


 Why just obvious bugs?


Hehe. Sure - let the compiler catch *all* my bugs!

scope, const, immutable, pure, nothrow, safe, ... D makes it 
harder to shoot yourself in the foot, but you are aiming at your 
foot by default..

Too bad I have to add a lot of annotations
   void f(Class i) {}
to
   void f(in Class i) const pure nothrow  safe {}

I would rather have to write
   void f( (mutable, escapes) Class i)  (impure mutable throws 
unsafe) {}

If  mutable and  impure existed, I could just add some 
annotations at the top of each module, but it wouldn't help on 
parameters.
Oct 16 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 16 October 2013 at 10:52:47 UTC, simendsjo wrote:

 On Wednesday, 16 October 2013 at 10:37:28 UTC, Timon Gehr wrote:

 On 10/16/2013 08:46 AM, simendsjo wrote:

 No.. Give me a language that catches obvious bugs at 
 compile-time, makes
 code self-documenting and doesn't let me worry about 
 performance.
 ...


 Why just obvious bugs?


 Hehe. Sure - let the compiler catch *all* my bugs!

 scope, const, immutable, pure, nothrow, safe, ... D makes it 
 harder to shoot yourself in the foot, but you are aiming at 
 your foot by default..

 Too bad I have to add a lot of annotations
   void f(Class i) {}
 to
   void f(in Class i) const pure nothrow  safe {}

 I would rather have to write
   void f( (mutable, escapes) Class i)  (impure mutable throws 
 unsafe) {}

 If  mutable and  impure existed, I could just add some 
 annotations at the top of each module, but it wouldn't help on 
 parameters.


I wonder how easy it would be to write a little pre-processor 
using https://github.com/Hackerpilot/Dscanner that would 
effectively add those keywords.
Oct 16 2013
parent "simendsjo" <simendsjo gmail.com> writes:
On Wednesday, 16 October 2013 at 10:58:04 UTC, John Colvin wrote:

 On Wednesday, 16 October 2013 at 10:52:47 UTC, simendsjo wrote:

 On Wednesday, 16 October 2013 at 10:37:28 UTC, Timon Gehr 
 wrote:

 On 10/16/2013 08:46 AM, simendsjo wrote:

 No.. Give me a language that catches obvious bugs at 
 compile-time, makes
 code self-documenting and doesn't let me worry about 
 performance.
 ...


 Why just obvious bugs?


 Hehe. Sure - let the compiler catch *all* my bugs!

 scope, const, immutable, pure, nothrow, safe, ... D makes it 
 harder to shoot yourself in the foot, but you are aiming at 
 your foot by default..

 Too bad I have to add a lot of annotations
  void f(Class i) {}
 to
  void f(in Class i) const pure nothrow  safe {}

 I would rather have to write
  void f( (mutable, escapes) Class i)  (impure mutable throws 
 unsafe) {}

 If  mutable and  impure existed, I could just add some 
 annotations at the top of each module, but it wouldn't help on 
 parameters.


 I wonder how easy it would be to write a little pre-processor 
 using https://github.com/Hackerpilot/Dscanner that would 
 effectively add those keywords.


Even if it were super simple and worked fine, I wouldn't use it. 
It would in effect be a custom "Safe D" compiler that isn't 
compatible with regular D.
Oct 16 2013
prev sibling next sibling parent reply "PauloPinto" <pjmlp progtools.org> writes:
On Wednesday, 16 October 2013 at 10:52:47 UTC, simendsjo wrote:

 On Wednesday, 16 October 2013 at 10:37:28 UTC, Timon Gehr wrote:

 On 10/16/2013 08:46 AM, simendsjo wrote:

 No.. Give me a language that catches obvious bugs at 
 compile-time, makes
 code self-documenting and doesn't let me worry about 
 performance.
 ...


 Why just obvious bugs?


 Hehe. Sure - let the compiler catch *all* my bugs!

 scope, const, immutable, pure, nothrow, safe, ... D makes it 
 harder to shoot yourself in the foot, but you are aiming at 
 your foot by default..

 Too bad I have to add a lot of annotations
   void f(Class i) {}
 to
   void f(in Class i) const pure nothrow  safe {}

 I would rather have to write
   void f( (mutable, escapes) Class i)  (impure mutable throws 
 unsafe) {}

 If  mutable and  impure existed, I could just add some 
 annotations at the top of each module, but it wouldn't help on 
 parameters.



The problem, which I know well from other languages with 
annotations, is that eventually you reach annotation hell, 
specially in the enterprise world.

--
Paulo
Oct 16 2013
next sibling parent "simendsjo" <simendsjo gmail.com> writes:
On Wednesday, 16 October 2013 at 11:05:25 UTC, PauloPinto wrote:

 On Wednesday, 16 October 2013 at 10:52:47 UTC, simendsjo wrote:

 On Wednesday, 16 October 2013 at 10:37:28 UTC, Timon Gehr 
 wrote:

 On 10/16/2013 08:46 AM, simendsjo wrote:

 No.. Give me a language that catches obvious bugs at 
 compile-time, makes
 code self-documenting and doesn't let me worry about 
 performance.
 ...


 Why just obvious bugs?


 Hehe. Sure - let the compiler catch *all* my bugs!

 scope, const, immutable, pure, nothrow, safe, ... D makes it 
 harder to shoot yourself in the foot, but you are aiming at 
 your foot by default..

 Too bad I have to add a lot of annotations
  void f(Class i) {}
 to
  void f(in Class i) const pure nothrow  safe {}

 I would rather have to write
  void f( (mutable, escapes) Class i)  (impure mutable throws 
 unsafe) {}

 If  mutable and  impure existed, I could just add some 
 annotations at the top of each module, but it wouldn't help on 
 parameters.



 The problem, which I know well from other languages with 
 annotations, is that eventually you reach annotation hell, 
 specially in the enterprise world.


I don't have any enterprise experience, but with UDAs, this can 
already happen.
What I think is bad is that I have to add a lot of built-in 
annotations to get help from the compiler catching bugs.
But there would be fewer annotations if you were able to negate 
some annotations.
If 95% of your functions are pure, why should you have to say 
pure for all those rather than impure for 5%?
Oct 16 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
PauloPinto:


 The problem, which I know well from other languages with 
 annotations, is that eventually you reach annotation hell, 
 specially in the enterprise world.


There are research papers that explore the algebra of effects, 
and also contain better syntax and some better inference. With 
such ideas the control of those effects seems to improve.

Bye,
bearophile
Oct 16 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
 There are research papers that explore the algebra of effects, 
 and also contain better syntax and some better inference. With 
 such ideas the control of those effects seems to improve.


An example, from the Koka language:
http://research.microsoft.com/en-us/projects/koka/2012-overviewkoka.pdf

Bye,
bearophile
Oct 16 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-16 12:52, simendsjo wrote:


 If  mutable and  impure existed, I could just add some annotations at
 the top of each module, but it wouldn't help on parameters.


We need a general way to turn off attributes. This "! attribute" has 
been proposed before.

-- 
/Jacob Carlborg
Oct 16 2013
parent reply "simendsjo" <simendsjo gmail.com> writes:
On Wednesday, 16 October 2013 at 11:36:30 UTC, Jacob Carlborg 
wrote:

 On 2013-10-16 12:52, simendsjo wrote:


 If  mutable and  impure existed, I could just add some 
 annotations at
 the top of each module, but it wouldn't help on parameters.


 We need a general way to turn off attributes. This 
 "! attribute" has been proposed before.


How would that relate to non-binary attributes like  system, 
 trusted,  safe?
Seems like it would only work on binary built-in attributes.
Oct 16 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 16 October 2013 at 11:47:44 UTC, simendsjo wrote:

 How would that relate to non-binary attributes like  system, 
  trusted,  safe?
 Seems like it would only work on binary built-in attributes.


Still helpful.

Problem with current built-in attribute design is that any 
attribute is supposed to be special case that catches attention 
and says something about the function. I D though most of 
attributes are actually wanted as defaults which creates all the 
mess. Adding negation for most common ones will make it at least 
tolerable without any major language changes.
Oct 16 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Dicebot:


 Adding negation for most common ones will make it at least 
 tolerable without any major language changes.


I suggest to stop applying patches over patches over problems, 
and instead adopt a more principled approach to solve problems. 
The ideas of the Koka language could show a principled way to 
face the problem.

Bye,
bearophile
Oct 16 2013
parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 16 October 2013 at 14:59:19 UTC, bearophile wrote:

 I suggest to stop applying patches over patches over problems, 
 and instead adopt a more principled approach to solve problems. 
 The ideas of the Koka language could show a principled way to 
 face the problem.


tl; dr: we can't

Right now D is in similar state as C++ in that regard and not 
much can be done without revamping the spec. It is not like 
people lack the ideas to improve the design, quite the contrary.
Oct 16 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-10-16 13:47, simendsjo wrote:


 How would that relate to non-binary attributes like  system,  trusted,
  safe?
 Seems like it would only work on binary built-in attributes.


No, ! safe would be mean the exact same thing as if you hadn't applied 
 safe. In this case,  system.

-- 
/Jacob Carlborg
Oct 16 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/16/13 4:47 AM, simendsjo wrote:

 On Wednesday, 16 October 2013 at 11:36:30 UTC, Jacob Carlborg wrote:

 On 2013-10-16 12:52, simendsjo wrote:


 If  mutable and  impure existed, I could just add some annotations at
 the top of each module, but it wouldn't help on parameters.


 We need a general way to turn off attributes. This "! attribute" has
 been proposed before.


 How would that relate to non-binary attributes like  system,  trusted,
  safe?


Those would be turned off by choosing another one. The point is they are 
surjective (cover the entire domain). The binary attributes are not 
surjective - the absence of one indicates its opposite, but there is no 
way to name the opposite.


 Seems like it would only work on binary built-in attributes.


Yah.


Andrei
Oct 16 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-16 20:38, Andrei Alexandrescu wrote:


 Seems like it would only work on binary built-in attributes.


 Yah.


Why?

enum foo;

 foo:

! foo void bar ();

Just as if  foo wasn't attached to "bar". Although I don't know that to 
do with multiple attributes of the same type:

 (foo, foo) void bar ();

Remove all?

-- 
/Jacob Carlborg
Oct 16 2013
parent reply "simendsjo" <simendsjo gmail.com> writes:
On Wednesday, 16 October 2013 at 19:00:07 UTC, Jacob Carlborg 
wrote:

 On 2013-10-16 20:38, Andrei Alexandrescu wrote:


 Seems like it would only work on binary built-in attributes.


 Yah.


 Why?

 enum foo;

  foo:

 ! foo void bar ();


You're right. That would be nice for generic code for instance to 
mark that it's done processing an attribute.


 Just as if  foo wasn't attached to "bar". Although I don't know 
 that to do with multiple attributes of the same type:

  (foo, foo) void bar ();

 Remove all?


Remove all would probably be more in sync with getAttributes that 
returns all attributes, but removing only the first would allow 
greater flexibility. It's easy to remove all if you have a way to 
remove one, but the other way around isn't as easy :)
Oct 16 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-16 21:08, simendsjo wrote:


 Remove all would probably be more in sync with getAttributes that
 returns all attributes, but removing only the first would allow greater
 flexibility. It's easy to remove all if you have a way to remove one,
 but the other way around isn't as easy :)


How would you remove all? I guess something like this:

! (foo, foo)

But how can that be generalized? Unless we get a trait for removing 
attributes.

-- 
/Jacob Carlborg
Oct 16 2013
parent reply "simendsjo" <simendsjo gmail.com> writes:
On Wednesday, 16 October 2013 at 19:19:26 UTC, Jacob Carlborg 
wrote:

 On 2013-10-16 21:08, simendsjo wrote:


 Remove all would probably be more in sync with getAttributes 
 that
 returns all attributes, but removing only the first would 
 allow greater
 flexibility. It's easy to remove all if you have a way to 
 remove one,
 but the other way around isn't as easy :)


 How would you remove all? I guess something like this:

 ! (foo, foo)

 But how can that be generalized? Unless we get a trait for 
 removing attributes.


Yes, sorry. I was thinking about a new __trait and running a loop.
Is this when we should be dreaming of the all-powerful AST macros 
again?
Oct 16 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-16 21:23, simendsjo wrote:


 Yes, sorry. I was thinking about a new __trait and running a loop.
 Is this when we should be dreaming of the all-powerful AST macros again?


Yes, AST macros will solve everything :)

-- 
/Jacob Carlborg
Oct 16 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 16, 2013 at 09:26:13PM +0200, Jacob Carlborg wrote:

 On 2013-10-16 21:23, simendsjo wrote:
 

Yes, sorry. I was thinking about a new __trait and running a loop.
Is this when we should be dreaming of the all-powerful AST macros
again?


 
 Yes, AST macros will solve everything :)


[...]

Including world hunger and world peace. :P


T

-- 
Маленькие детки - маленькие бедки.
Oct 16 2013
parent reply "Tourist" <gravatar gravatar.com> writes:
On Wednesday, 16 October 2013 at 20:43:30 UTC, H. S. Teoh wrote:

 On Wed, Oct 16, 2013 at 09:26:13PM +0200, Jacob Carlborg wrote:

 On 2013-10-16 21:23, simendsjo wrote:
 

Yes, sorry. I was thinking about a new __trait and running a 
loop.
Is this when we should be dreaming of the all-powerful AST 
macros
again?


 
 Yes, AST macros will solve everything :)


 [...]

 Including world hunger and world peace. :P


 T


"I would change the world, but God won't release the source code" 
:)
Oct 16 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 16, 2013 at 10:48:03PM +0200, Tourist wrote:

 On Wednesday, 16 October 2013 at 20:43:30 UTC, H. S. Teoh wrote:

On Wed, Oct 16, 2013 at 09:26:13PM +0200, Jacob Carlborg wrote:

On 2013-10-16 21:23, simendsjo wrote:


Yes, sorry. I was thinking about a new __trait and running a loop.
Is this when we should be dreaming of the all-powerful AST macros
again?


Yes, AST macros will solve everything :)


[...]

Including world hunger and world peace. :P


T


 
 "I would change the world, but God won't release the source code" :)


Well even if you have the source code, do you have a way to compile it?
:P


T

-- 
Some days you win; most days you lose.
Oct 16 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 16 Oct 2013 13:57:50 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:


 On Wed, Oct 16, 2013 at 10:48:03PM +0200, Tourist wrote:

 
 "I would change the world, but God won't release the source code" :)


 
 Well even if you have the source code, do you have a way to compile
 it? :P
 


Compiling it shouldn't be a problem:
http://xkcd.com/224/
Oct 16 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 16, 2013 at 05:08:38PM -0400, Nick Sabalausky wrote:

 On Wed, 16 Oct 2013 13:57:50 -0700
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:
 

 On Wed, Oct 16, 2013 at 10:48:03PM +0200, Tourist wrote:

 
 "I would change the world, but God won't release the source code" :)


 
 Well even if you have the source code, do you have a way to compile
 it? :P
 


 
 Compiling it shouldn't be a problem:
 http://xkcd.com/224/


Ah but if the code were written in Perl, good luck finding the bugs...


T

-- 
Heads I win, tails you lose.
Oct 16 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-16 23:08, Nick Sabalausky wrote:


 Compiling it shouldn't be a problem:
 http://xkcd.com/224/


So, it's written in Perl. That's why we haven't figured out how the 
universe works:

"You shoot yourself in the foot, but nobody can understand how you did 
it. Six months later, neither can you"

http://www.fullduplex.org/humor/2006/10/how-to-shoot-yourself-in-the-foot-in-any-programming-language/

-- 
/Jacob Carlborg
Oct 17 2013
parent reply "Meta" <jared771 gmail.com> writes:
On Thursday, 17 October 2013 at 07:42:22 UTC, Jacob Carlborg 
wrote:

 On 2013-10-16 23:08, Nick Sabalausky wrote:


 Compiling it shouldn't be a problem:
 http://xkcd.com/224/


 So, it's written in Perl. That's why we haven't figured out how 
 the universe works:

 "You shoot yourself in the foot, but nobody can understand how 
 you did it. Six months later, neither can you"

 http://www.fullduplex.org/humor/2006/10/how-to-shoot-yourself-in-the-foot-in-any-programming-language/


So what's the D equivalent?

"You're only allowed to shoot yourself in the foot if you use 
system."
Oct 17 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-17 11:15, Meta wrote:


 So what's the D equivalent?

 "You're only allowed to shoot yourself in the foot if you use system."


 From the comments:

"D
You shoot yourself in the foot in two linse using a builtin Gun and 
Bullet[].

The experience is so enjoyable you shoot yourself again…."

-- 
/Jacob Carlborg
Oct 17 2013
parent "Meta" <jared771 gmail.com> writes:
On Thursday, 17 October 2013 at 09:49:37 UTC, Jacob Carlborg 
wrote:

 From the comments:


I had to laugh at this one:

".Net

Microsoft hands you a gun and swears blind it’s a toenail clipper

Someone throws a fucking chair at you."
Oct 17 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Oct 15, 2013 at 03:15:45PM -0700, Walter Bright wrote:

 
 http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8


It's interesting how compile times seem to always crop up in discussions
about static vs. dynamic typing, even though it's really an orthogonal
issue. I think D is a winner in this area (good job with the fast
compile times, Walter!).


T

-- 
Meat: euphemism for dead animal. -- Flora
Oct 15 2013
parent "PauloPinto" <pjmlp progtools.org> writes:
On Tuesday, 15 October 2013 at 23:53:06 UTC, H. S. Teoh wrote:

 On Tue, Oct 15, 2013 at 03:15:45PM -0700, Walter Bright wrote:

 
 http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8


 It's interesting how compile times seem to always crop up in 
 discussions
 about static vs. dynamic typing, even though it's really an 
 orthogonal
 issue. I think D is a winner in this area (good job with the 
 fast
 compile times, Walter!).


 T


C and C++ are the ones to blame here.

Before they were ubiquitous, there were already compilers in the 
Pascal family that were quite fast.

Turbo Pascal always compiled within a few seconds and it did 
compile the desired module and all related dependencies.

However many young developers only know C and C++ as languages 
with native compilers, hence the common fallacy compilers are 
slow.

--
Paulo
Oct 15 2013
prev sibling next sibling parent "brad clawsie" <brad b7j0c.org> writes:
an excellent post, thanks for linking it Walter

the relative weakness of dynamic-typed tools is compounded by the 
fact that they tend to be used to build monolithic applications, 
typical of what might emerge from rails, php etc. you take the 
whole ball of mud or nothing. with no types to define the "rules 
of engagement", management of the interior of the application 
becomes lore-oriented...i.e. application lifetime job security 
for the original developer.

but its also important to put dynamic tools in their proper 
context. in the mid-90s they vastly accelerated many industrial 
coding chores. they had their time, but I believe that time is 
over.
Oct 15 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 15 Oct 2013 15:15:45 -0700
Walter Bright <newshound2 digitalmars.com> wrote:


 
 http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8
 


Totally agree. 90+% of the argument for dynamic languages is "getting
shit done", and yet they ultimately *create* work: More unittests, more
roadblocks optimizing for memory/speed, and (the biggest IMO) much more
debugging due to statically-checkable errors being silently converted
into hidden bugs.

More of my notes on the dynamic "getting shit done" emperor having no
clothes:

https://news.ycombinator.com/item?id=6530465

http://semitwist.com/articles/article/view/why-i-hate-python-or-any-dynamic-language-really
Oct 15 2013
parent reply Sean Kelly <sean invisibleduck.org> writes:
On Oct 15, 2013, at 5:30 PM, Nick Sabalausky <SeeWebsiteToContactMe semitwis=
t.com> wrote:

=20
 On Tue, 15 Oct 2013 15:15:45 -0700
 Walter Bright <newshound2 digitalmars.com> wrote:
=20

=20
 http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_langu=




age/ccs8yr8

=20
 Totally agree. 90+% of the argument for dynamic languages is "getting
 shit done", and yet they ultimately *create* work: More unittests, more
 roadblocks optimizing for memory/speed, and (the biggest IMO) much more
 debugging due to statically-checkable errors being silently converted
 into hidden bugs.


I'm reasonably okay with dynamic languages so long as you can require a vari=
able to be declared before it's used.  Those that implicitly declare on firs=
t assignment are a nightmare however. I once spent an entire day debugging a=
 Lua app that turned out to be broken because of a typo in an assignment. Ne=
ver again.=20=
Oct 16 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-10-16 17:37, Sean Kelly wrote:


 I'm reasonably okay with dynamic languages so long as you can require a
variable to be declared before it's used.  Those that implicitly declare on
first assignment are a nightmare however. I once spent an entire day debugging
a Lua app that turned out to be broken because of a typo in an assignment.
Never again.


That can be quite annoying in Ruby sometimes:

class Bar
   attr_accessor :foo

   def bar




directory

   end
end

Bar.new.bar

Although I like that instance variables are not required to be declared.

-- 
/Jacob Carlborg
Oct 16 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/16/2013 8:37 AM, Sean Kelly wrote:

 I'm reasonably okay with dynamic languages so long as you can require a
 variable to be declared before it's used.  Those that implicitly declare on
 first assignment are a nightmare however. I once spent an entire day
 debugging a Lua app that turned out to be broken because of a typo in an
 assignment. Never again.


Implicit declaration is such a bad idea; I wonder why it keeps reappearing in 
every new dynamic language du jour.
Oct 16 2013
next sibling parent "Max Samukha" <maxsamukha gmail.com> writes:
On Wednesday, 16 October 2013 at 20:00:45 UTC, Walter Bright 
wrote:

 On 10/16/2013 8:37 AM, Sean Kelly wrote:

 I'm reasonably okay with dynamic languages so long as you can 
 require a
 variable to be declared before it's used.  Those that 
 implicitly declare on
 first assignment are a nightmare however. I once spent an 
 entire day
 debugging a Lua app that turned out to be broken because of a 
 typo in an
 assignment. Never again.


 Implicit declaration is such a bad idea; I wonder why it keeps 
 reappearing in every new dynamic language du jour.


Hail CoffeeScript!
Oct 16 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 16 October 2013 at 20:00:45 UTC, Walter Bright 
wrote:

 On 10/16/2013 8:37 AM, Sean Kelly wrote:

 I'm reasonably okay with dynamic languages so long as you can 
 require a
 variable to be declared before it's used.  Those that 
 implicitly declare on
 first assignment are a nightmare however. I once spent an 
 entire day
 debugging a Lua app that turned out to be broken because of a 
 typo in an
 assignment. Never again.


 Implicit declaration is such a bad idea; I wonder why it keeps 
 reappearing in every new dynamic language du jour.


Kind of like null : it is easy to implement.
Oct 16 2013
prev sibling next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 15 Oct 2013 15:15:45 -0700, Walter Bright  
<newshound2 digitalmars.com> wrote:


 http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8


+1

This is why I claw my eyes out every time I have to work with JavaScript.
This is why I find statically typed languages to so much more powerful for  
the work I do.

We need more D...

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Oct 15 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-16 02:45, Adam Wilson wrote:


 +1

 This is why I claw my eyes out every time I have to work with JavaScript.
 This is why I find statically typed languages to so much more powerful
 for the work I do


One big difference between Ruby and JavaScript is that when something 
fails in Ruby you'll get an exception. But with JavaScript it just 
silently fails and all your scripts on the site dies.

-- 
/Jacob Carlborg
Oct 16 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 16, 2013 at 09:19:56AM +0200, Jacob Carlborg wrote:

 On 2013-10-16 02:45, Adam Wilson wrote:
 

+1

This is why I claw my eyes out every time I have to work with
JavaScript.  This is why I find statically typed languages to so much
more powerful for the work I do


 
 One big difference between Ruby and JavaScript is that when
 something fails in Ruby you'll get an exception. But with JavaScript
 it just silently fails and all your scripts on the site dies.


[...]

Yeah, this is exactly what makes Javascript a royal pain in the neck to
work with.  I have the dubious pleasure of having to work on a large
non-trivial JS codebase at work, and it has a reputation of simply
displaying a blank page when something goes wrong. Worse yet, there is
some default error handler somewhere that swallows all JS errors, so no
errors get logged to the browser's JS console at all -- you have to
debug the entire 50k or so lines of JS with a blank page as your only
clue as to what blew up.

(And don't get me started on IE6, which used to be the de facto standard
demanded by every customer some years ago, which doesn't even *have* an
error console. Fortunately, the world has moved on since.)

Other times, when it doesn't show a blank page, the same ingenious
default error handler makes it so that scripts *continue* running after
something has gone wrong. So when you screw up and some part of the code
crashes, the rest of the page continues running as if nothing happened,
except that some buttons mysteriously do nothing, or the widget starts
acting funny.


T

-- 
Bare foot: (n.) A device for locating thumb tacks on the floor.
Oct 16 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-16 19:26, H. S. Teoh wrote:


 Yeah, this is exactly what makes Javascript a royal pain in the neck to
 work with.  I have the dubious pleasure of having to work on a large
 non-trivial JS codebase at work, and it has a reputation of simply
 displaying a blank page when something goes wrong. Worse yet, there is
 some default error handler somewhere that swallows all JS errors, so no
 errors get logged to the browser's JS console at all -- you have to
 debug the entire 50k or so lines of JS with a blank page as your only
 clue as to what blew up.


Yeah, you really need to use the browser's developer tools to have any 
chance when working with JavaScript.


 (And don't get me started on IE6, which used to be the de facto standard
 demanded by every customer some years ago, which doesn't even *have* an
 error console. Fortunately, the world has moved on since.)


Actually, just a couple of weeks ago I found Firebug Lite. It's like 
Firebug but it's a booklet in pure JavaScript (ironically). That means 
you can use it in any browser, include IE6 (yes it works in IE6), iOS 
and other browsers missing developer tools.

I have also used remote debugging when I debugged a site in the iPhone 
simulator. It uses web sockets (I think) to send the data to another 
browser where the actual developer tools are.

-- 
/Jacob Carlborg
Oct 16 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 16, 2013 at 09:14:14PM +0200, Jacob Carlborg wrote:

 On 2013-10-16 19:26, H. S. Teoh wrote:
 

Yeah, this is exactly what makes Javascript a royal pain in the neck
to work with.  I have the dubious pleasure of having to work on a
large non-trivial JS codebase at work, and it has a reputation of
simply displaying a blank page when something goes wrong. Worse yet,
there is some default error handler somewhere that swallows all JS
errors, so no errors get logged to the browser's JS console at all --
you have to debug the entire 50k or so lines of JS with a blank page
as your only clue as to what blew up.


 
 Yeah, you really need to use the browser's developer tools to have any
 chance when working with JavaScript.


Even *with* developer tools, where would you even start? I mean, the
blank page could have resulted from any one point of about 5kloc worth
of JS initialization code (which BTW dynamically loads in a whole bunch
of other JS code, each of which need to run their own initialization
which includes talking to a remote backend server and processing the
response data, all before anything even gets displayed on the page --
don't ask me why it was designed this way, this is what happens when you
take the browser-as-a-platform concept too far). I think (relatively)
recently Opera's Dragonfly added a feature to break into the debugger as
soon as an error is thrown (rather than only when it's unhandled), but
even that doesn't seem to catch all of the errors.



(And don't get me started on IE6, which used to be the de facto
standard demanded by every customer some years ago, which doesn't
even *have* an error console. Fortunately, the world has moved on
since.)


 
 Actually, just a couple of weeks ago I found Firebug Lite. It's like
 Firebug but it's a booklet in pure JavaScript (ironically). That
 means you can use it in any browser, include IE6 (yes it works in
 IE6), iOS and other browsers missing developer tools.


[...]

Nice! I'll have to keep that in mind when I next have to deal with that
horrendous JS code.


T

-- 
Political correctness: socially-sanctioned hypocrisy.
Oct 16 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-16 22:55, H. S. Teoh wrote:


 Even *with* developer tools, where would you even start? I mean, the
 blank page could have resulted from any one point of about 5kloc worth
 of JS initialization code (which BTW dynamically loads in a whole bunch
 of other JS code, each of which need to run their own initialization
 which includes talking to a remote backend server and processing the
 response data, all before anything even gets displayed on the page --
 don't ask me why it was designed this way, this is what happens when you
 take the browser-as-a-platform concept too far). I think (relatively)
 recently Opera's Dragonfly added a feature to break into the debugger as
 soon as an error is thrown (rather than only when it's unhandled), but
 even that doesn't seem to catch all of the errors.


If you get an error the developer tools will show you where. At least 
it's a start.

-- 
/Jacob Carlborg
Oct 17 2013
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
+1

What can I say? For the web I have to use JavaScript, PHP and 
Python. Imagine the amount of stupid-yet-hard-to-find bugs I've 
had to deal with. Bugs that you only become aware of at runtime.

Am much happier with D (or Java, Objective-C). As for the 
arguments concerning compile time, extra typing for typing, 
c'mon, they must be kidding.

Not to mention increased execution speed, not only in terms of 
script vs. binary, but also in terms of known type vs. 
dynamically assigned type.

Another issue I've come across is that languages like JS and PHP 
lend themselves to quick and dirty stuff, or rather seduce 
programmers to quick and dirty solutions. Languages like D guide 
you towards cleaner and better structured code.
Oct 17 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 17 Oct 2013 15:26:41 +0200
"Chris" <wendlec tcd.ie> wrote:


 +1
 
 What can I say? For the web I have to use JavaScript, PHP and 
 Python. Imagine the amount of stupid-yet-hard-to-find bugs I've 
 had to deal with. Bugs that you only become aware of at runtime.
 


I've gotten to the point where I just refuse to deal with PHP anymore
(And I've never been willing to jump on the AJAX-y train).

I believe as much as anyone in "whatever pays the bills", but even then
there's reasonable limits where you just have to draw the line for your
own sake.


 Am much happier with D (or Java, Objective-C). As for the 
 arguments concerning compile time, extra typing for typing, 
 c'mon, they must be kidding.
 


Exactly. I often get the impression the static-haters have only ever
heard of C++ and Java 2.


 Not to mention increased execution speed, not only in terms of 
 script vs. binary, but also in terms of known type vs. 
 dynamically assigned type.
 


And in terms of "cache-friendly vs ultra-cache-annihilator-3000".

And in terms of "Simple efficient array of primitives vs Let's replace
every trivial primitive of data in the entire program with a big ol'
hashtable-of-hashtables, and potentially scatter them all over
memory, all just in case some knucklehead decides he just NEEDS to go
adding members and methods to some *individual* instance of a freaking
integer."

No wonder my Apple II had more responsive text entry than most modern
web sites. Hell, I've used typewriters that were faster than some web
forms. No joke.
Oct 17 2013
prev sibling parent reply "PauloPinto" <pjmlp progtools.org> writes:
On Thursday, 17 October 2013 at 07:43:07 UTC, Jacob Carlborg 
wrote:

 On 2013-10-16 22:55, H. S. Teoh wrote:


 Even *with* developer tools, where would you even start? I 
 mean, the
 blank page could have resulted from any one point of about 
 5kloc worth
 of JS initialization code (which BTW dynamically loads in a 
 whole bunch
 of other JS code, each of which need to run their own 
 initialization
 which includes talking to a remote backend server and 
 processing the
 response data, all before anything even gets displayed on the 
 page --
 don't ask me why it was designed this way, this is what 
 happens when you
 take the browser-as-a-platform concept too far). I think 
 (relatively)
 recently Opera's Dragonfly added a feature to break into the 
 debugger as
 soon as an error is thrown (rather than only when it's 
 unhandled), but
 even that doesn't seem to catch all of the errors.


 If you get an error the developer tools will show you where. At 
 least it's a start.



Unless you are developing a f**** hybrid application targeting to 
mobiles.

No debugger there to talk to the corresponding native browser 
widgets. :( :(

--
Paulo
Oct 17 2013
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 17 October 2013 at 13:54:34 UTC, PauloPinto wrote:

 No debugger there to talk to the corresponding native browser 
 widgets. :( :(


Hm, some mobile browsers (e.g. Chrome on Android) come with 
pretty tight remote debugging integration, maybe something like 
that is available for embedded widgets as well?

David
Oct 17 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 17.10.2013 16:26, schrieb David Nadlinger:

 On Thursday, 17 October 2013 at 13:54:34 UTC, PauloPinto wrote:

 No debugger there to talk to the corresponding native browser widgets.
 :( :(


 Hm, some mobile browsers (e.g. Chrome on Android) come with pretty tight
 remote debugging integration, maybe something like that is available for
 embedded widgets as well?

 David


This is a custom enterprise framework. :(

--
Paulo
Oct 17 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-17 15:54, PauloPinto wrote:


 Unless you are developing a f**** hybrid application targeting to mobiles.

 No debugger there to talk to the corresponding native browser widgets.
 :( :(


You missed my other post about Firebug Lite:

http://forum.dlang.org/thread/l3keqg$e31$1 digitalmars.com?page=4#post-l3moi7:24ak5:241:40digitalmars.com

-- 
/Jacob Carlborg
Oct 17 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 17.10.2013 17:03, schrieb Jacob Carlborg:

 On 2013-10-17 15:54, PauloPinto wrote:


 Unless you are developing a f**** hybrid application targeting to
 mobiles.

 No debugger there to talk to the corresponding native browser widgets.
 :( :(


 You missed my other post about Firebug Lite:

 http://forum.dlang.org/thread/l3keqg$e31$1 digitalmars.com?page=4#post-l3moi7:24ak5:241:40digitalmars.com


Not when you have a custom built Java/Objective-C framework that 
controls how the requests are handled, with a few hooks for special 
behaviours.

The wonderful world of enterprise NIH frameworks. :(

--
Paulo
Oct 17 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 16 Oct 2013 10:26:37 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 
 (And don't get me started on IE6, which used to be the de facto
 standard demanded by every customer some years ago, which doesn't
 even *have* an error console. Fortunately, the world has moved on
 since.)
 


I remember going through the same hell with Safari. (I assume that's
been fixed by now, though.)
Oct 16 2013
parent "Jacob Carlborg" <doob me.com> writes:
On Wednesday, 16 October 2013 at 20:20:18 UTC, Nick Sabalausky 
wrote:


 I remember going through the same hell with Safari. (I assume 
 that's
 been fixed by now, though.)


It has similar developer tools like Chrome has.

--
/Jacob Carlborg
Oct 16 2013
prev sibling parent "Michal Minich" <michal.minich gmail.com> writes:
On Wednesday, 16 October 2013 at 17:27:54 UTC, H. S. Teoh wrote:


 some default error handler somewhere that swallows all JS errors


That would be function bound to window.onerror event. Remove it, 
or put breakpoint in it;

Also "use strict"; on new code. But it might be valuable to find 
out if it pays of putting it to use on old code (if it isn't too 
much warnings ->  refactoring needed). One benefit, among few 
others, is that assignment to undeclared variable throws 
exception.
Oct 16 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 15 Oct 2013 15:15:45 -0700
Walter Bright <newshound2 digitalmars.com> wrote:


 
 http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8
 


OMG, I just noticed that's a reddit for a comment on hacker news.

I can't wait to see a comment in that reddit get it's own posting back
over on hacker news :)

Silly Web 2.0...
Oct 15 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, October 15, 2013 15:15:45 Walter Bright wrote:

 http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language
 /ccs8yr8


I can't possibly like any language where the type of a variable could change 
based on whether the condition in an if statement is true (because a variable 
gets assigned a completely different type depending no the branch of the if 
statement). I've never seen static typing as a burden. Rather, it's finding 
bugs in your program for you.

- Jonathan M Davis
Oct 16 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 16, 2013 at 10:16:17PM -0400, Jonathan M Davis wrote:

 On Tuesday, October 15, 2013 15:15:45 Walter Bright wrote:

 http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language
 /ccs8yr8


 
 I can't possibly like any language where the type of a variable could
 change based on whether the condition in an if statement is true
 (because a variable gets assigned a completely different type
 depending no the branch of the if statement).


	auto func(alias condition)()
	{
		static if (condition())
			int t;
		else
			float t;
		return t;
	}

;-)



 I've never seen static typing as a burden. Rather, it's finding bugs
 in your program for you.


[...]

I think many people got the false impression of static typing being a
burden from historical languages where type annotations have to be
explicit all the time. With the advent of type inference, much of this
burden has been lifted, and this argument is no longer relevant.


T

-- 
Caffeine underflow. Brain dumped.
Oct 16 2013
parent reply "growler" <growlercab gmail.com> writes:
On Thursday, 17 October 2013 at 02:37:35 UTC, H. S. Teoh wrote:

 On Wed, Oct 16, 2013 at 10:16:17PM -0400, Jonathan M Davis 
 wrote:

 On Tuesday, October 15, 2013 15:15:45 Walter Bright wrote:

 http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language
 /ccs8yr8


 
 I can't possibly like any language where the type of a 
 variable could
 change based on whether the condition in an if statement is 
 true
 (because a variable gets assigned a completely different type
 depending no the branch of the if statement).


 	auto func(alias condition)()
 	{
 		static if (condition())
 			int t;
 		else
 			float t;
 		return t;
 	}

 ;-)


But if you make a mistake it is very likely that you'll see it at 
compile time, not runtime. Plus D has very explicit casting which 
also helps.
Oct 16 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, October 17, 2013 04:49:29 growler wrote:

 On Thursday, 17 October 2013 at 02:37:35 UTC, H. S. Teoh wrote:

 On Wed, Oct 16, 2013 at 10:16:17PM -0400, Jonathan M Davis
 
 wrote:

 On Tuesday, October 15, 2013 15:15:45 Walter Bright wrote:

 http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_lan
 guage /ccs8yr8


 
 I can't possibly like any language where the type of a
 variable could
 change based on whether the condition in an if statement is
 true
 (because a variable gets assigned a completely different type
 depending no the branch of the if statement).
 


 auto func(alias condition)()
 {
 
 static if (condition())
 
 int t;
 
 else
 
 float t;
 
 return t;
 
 }
 
 ;-)


 
 But if you make a mistake it is very likely that you'll see it at
 compile time, not runtime. Plus D has very explicit casting which
 also helps.


The key difference is that the type of a variable won't change on you in D. 
Sure, the return type of a function could change depending on the types of its 
arguments or the value of its template arguments, but it's all known at 
compile time, and you'll get an error for any type mismatch. In contrast, with 
a dynamically typed language, the type of a variable can actually change while 
your program is running, resulting in function calls being wrong due to the 
fact that they don't work with the new type. If you're dealing with static 
typing, the type of every variable is fixed, and the legality of code doesn't 
suddenly change at runtime.

And it's not like scripting requires dynamic typing (e.g. you can write 
scripts in D, which is statically typed), so as far as I'm concerned, there's 
no excuse for using dynamic typing. It just causes bugs - not only that, but 
the bugs that it causes are trivially caught with a statically typed language. 
I pretty much outright hate dynamic typing and expect that I will never 
heavily use a language that has it.

- Jonathan M Davis
Oct 16 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 17 October 2013 at 03:07:30 UTC, Jonathan M Davis 
wrote:

 I pretty much outright hate dynamic typing and expect that I 
 will never heavily use a language that has it.


Be careful what you say: D has dynamic typing! (see: std.variant, 
or my arsd.jsvar)

The important thing though is that D doesn't *force* you to use 
it: it is there for the cases where you want it, and not when you 
don't want it.
Oct 16 2013
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, October 17, 2013 05:12:48 Adam D. Ruppe wrote:

 On Thursday, 17 October 2013 at 03:07:30 UTC, Jonathan M Davis
 
 wrote:

 I pretty much outright hate dynamic typing and expect that I
 will never heavily use a language that has it.


 
 Be careful what you say: D has dynamic typing! (see: std.variant,
 or my arsd.jsvar)
 
 The important thing though is that D doesn't *force* you to use
 it: it is there for the cases where you want it, and not when you
 don't want it.


It's not quite the same thing. D itself is not dynamically typed. It just 
allows you to create it with your own types if you want to. But I also think 
that variants should be avoided unless they're absolutely necessary, and it's 
very rare that they're necessary. Certain specific stuff needs it (like the 
result from a database query), but the vast majority of code does not.

- Jonathan M Davis
Oct 16 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 16, 2013 at 11:07:20PM -0400, Jonathan M Davis wrote:

 On Thursday, October 17, 2013 04:49:29 growler wrote:

 On Thursday, 17 October 2013 at 02:37:35 UTC, H. S. Teoh wrote:

 On Wed, Oct 16, 2013 at 10:16:17PM -0400, Jonathan M Davis






[...]

 I can't possibly like any language where the type of a variable
 could change based on whether the condition in an if statement is
 true (because a variable gets assigned a completely different
 type depending no the branch of the if statement).
 


 auto func(alias condition)()
 {
 
 static if (condition())
 
 int t;
 
 else
 
 float t;
 
 return t;
 
 }
 
 ;-)


 
 But if you make a mistake it is very likely that you'll see it at
 compile time, not runtime. Plus D has very explicit casting which
 also helps.


 
 The key difference is that the type of a variable won't change on you
 in D.  Sure, the return type of a function could change depending on
 the types of its arguments or the value of its template arguments, but
 it's all known at compile time, and you'll get an error for any type
 mismatch.


Yes, I know that. :) I was only being half-serious. D actually "does it
right" in this case: if for whatever reason the resulting type from the
static if is incompatible with the surrounding code, then as you say the
static typing system will throw up its hands at compile-time, rather
than at runtime on a customer's production environment.



 In contrast, with a dynamically typed language, the type of a variable
 can actually change while your program is running, resulting in
 function calls being wrong due to the fact that they don't work with
 the new type. If you're dealing with static typing, the type of every
 variable is fixed, and the legality of code doesn't suddenly change at
 runtime.


	bool func(Variant x, Variant y) {
		return x < y;
	}

	func(1, 2);	// ok
	func(1.0, 2.0);	// ok
	func("a", 1);	// hmmm... ;-)



 And it's not like scripting requires dynamic typing (e.g. you can
 write scripts in D, which is statically typed), so as far as I'm
 concerned, there's no excuse for using dynamic typing. It just causes
 bugs - not only that, but the bugs that it causes are trivially caught
 with a statically typed language.  I pretty much outright hate dynamic
 typing and expect that I will never heavily use a language that has
 it.


[...]

Dynamic typing has its place... database query results, for example.

However, the trouble with today's so-called "dynamic languages" is that
you're forced to use dynamic typing everywhere, even where it doesn't
make sense (and TBH, most of the time it's not appropriate). It's great
for writing truly generic functions like:

	// Javascript
	function add(x,y) { return x+y; }

but seriously, how much of *real*-world JS code is *that* generic? Most
actual JS code looks like this:

	function checkInput(data) {
		if (data.name == 'myname' || data.age < 10 || ...)
			return 1;
		return 0;
	}

which presumes the existence of specific fields in the 'data' parameter,
which implies that 'data' is an object type (as opposed to, say, an
int), and which will fail miserably if 'data' just so happens to be a
non-object, or an object without the presumed fields, or an object with
those exact fields that just happen to be of the wrong type, etc..
There are just so many levels of wrong with using dynamic typing for
this kind of code that being *forced* to do it is simply asking for
bugs.

Not to mention that the name 'data' says absolutely nothing about
exactly what structure it must have in order for the function to work;
you have to read the function body to find out (and even then, it's not
always obvious exactly what is expected). You end up wasting so much
time trying to deduce what type(s) the function must take (where in a
statically-typed language you just read the type name and look it up) or
otherwise working around the type system (or lack thereof) in similar
ways that it completely negates the purported productivity benefit of
dynamic typing.  (And yes I know there are ways to improve code
readability -- by parameter naming conventions, for example, which are
essentially reinventing type annotations poorly -- you still won't have
the benefit of compile-time type checking.)

Static typing with automatic type inference is a far superior solution
in most cases. And in D, you even have std.variant for those occasions
where you *do* want dynamic typing (whereas in languages like C, you
have to use tricky type casts and void* dereferences, which are very
prone to bugs). Being forced one way or another never ends well.


T

-- 
Just because you survived after you did it, doesn't mean it wasn't stupid!
Oct 16 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 16 Oct 2013 23:00:04 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:


 On Wed, Oct 16, 2013 at 11:07:20PM -0400, Jonathan M Davis wrote:

 In contrast, with a dynamically typed language, the type of a
 variable can actually change while your program is running,
 resulting in function calls being wrong due to the fact that they
 don't work with the new type. If you're dealing with static typing,
 the type of every variable is fixed, and the legality of code
 doesn't suddenly change at runtime.


 
 	bool func(Variant x, Variant y) {
 		return x < y;
 	}
 
 	func(1, 2);	// ok
 	func(1.0, 2.0);	// ok
 	func("a", 1);	// hmmm... ;-)
 


from bottle import route, run, response

 route('/foo')
def index():
	response.content_type = response
	return 'Take that, HTTP!!'

run(host='localhost', port=8181)
Oct 17 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 18 October 2013 at 02:08:59 UTC, Nick Sabalausky wrote:

 On Wed, 16 Oct 2013 23:00:04 -0700
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:


 On Wed, Oct 16, 2013 at 11:07:20PM -0400, Jonathan M Davis 
 wrote:

 In contrast, with a dynamically typed language, the type of a
 variable can actually change while your program is running,
 resulting in function calls being wrong due to the fact that 
 they
 don't work with the new type. If you're dealing with static 
 typing,
 the type of every variable is fixed, and the legality of code
 doesn't suddenly change at runtime.


 
 	bool func(Variant x, Variant y) {
 		return x < y;
 	}
 
 	func(1, 2);	// ok
 	func(1.0, 2.0);	// ok
 	func("a", 1);	// hmmm... ;-)
 


 from bottle import route, run, response

  route('/foo')
 def index():
 	response.content_type = response
 	return 'Take that, HTTP!!'

 run(host='localhost', port=8181)


from bottleneck import runslow
Oct 18 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 18 October 2013 at 10:23:34 UTC, Chris wrote:

 On Friday, 18 October 2013 at 02:08:59 UTC, Nick Sabalausky 
 wrote:

 On Wed, 16 Oct 2013 23:00:04 -0700
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:


 On Wed, Oct 16, 2013 at 11:07:20PM -0400, Jonathan M Davis 
 wrote:

 In contrast, with a dynamically typed language, the type of 
 a
 variable can actually change while your program is running,
 resulting in function calls being wrong due to the fact 
 that they
 don't work with the new type. If you're dealing with static 
 typing,
 the type of every variable is fixed, and the legality of 
 code
 doesn't suddenly change at runtime.


 
 	bool func(Variant x, Variant y) {
 		return x < y;
 	}
 
 	func(1, 2);	// ok
 	func(1.0, 2.0);	// ok
 	func("a", 1);	// hmmm... ;-)
 


 from bottle import route, run, response

  route('/foo')
 def index():
 	response.content_type = response
 	return 'Take that, HTTP!!'

 run(host='localhost', port=8181)


 from bottleneck import runslow


I like bottlenecks in Blues, not in programs.
Oct 18 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 18 Oct 2013 12:44:59 +0200
"Chris" <wendlec tcd.ie> wrote:


 On Friday, 18 October 2013 at 10:23:34 UTC, Chris wrote:

 from bottleneck import runslow


 
 I like bottlenecks in Blues, not in programs.


Heh. They're very satisfying to play. Such a rich bass. Also fun to
annoy people with :)
Oct 18 2013
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 18 October 2013 at 12:22:16 UTC, Nick Sabalausky wrote:

 On Fri, 18 Oct 2013 12:44:59 +0200
 "Chris" <wendlec tcd.ie> wrote:


 On Friday, 18 October 2013 at 10:23:34 UTC, Chris wrote:

 from bottleneck import runslow


 
 I like bottlenecks in Blues, not in programs.


 Heh. They're very satisfying to play. Such a rich bass. Also 
 fun to
 annoy people with :)


Yeah, you can do some weird stuff with bottlenecks alright. Maybe
we should have a module in phobos that helps detecting
bottlenecks.

std.bottleneck

struct Slide {
    int frets = 22;
    int strings = 6;
    string E;
    string A;
    string D;
    string G;
    string B;
    string e;
}

struct Amp {
    int volume = 11;
}

struct Neighbor {
    int annoyed = 911;
}
Oct 18 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8


I have found one of the several voices that reminds us of the 
advantages of dynamic typing:

http://www.srl.inf.ethz.ch/workshop2013/eth-vitek.pdf

(I was away for few days.)

Bye,
bearophile
Oct 28 2013
parent reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Monday, 28 October 2013 at 08:59:59 UTC, bearophile wrote:

 Walter Bright:


 http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8


 I have found one of the several voices that reminds us of the 
 advantages of dynamic typing:

 http://www.srl.inf.ethz.ch/workshop2013/eth-vitek.pdf

 (I was away for few days.)

 Bye,
 bearophile


I started getting suspicious at the slide where (s)he claimed
that 9.3% of the world's software uses Objective-C while 9.1% of
the worlds software uses C++.  Thats a lot of people writing apps
for iPhones....

I find that hard to believe, and I don't think that is what TIOBE
is even claiming to begin with. Looking at the current index I
wonder how much stock you can put in those rankings anyway.

Craig
Oct 28 2013
parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Monday, 28 October 2013 at 13:06:43 UTC, Craig Dillabaugh
wrote:

 On Monday, 28 October 2013 at 08:59:59 UTC, bearophile wrote:

 Walter Bright:


 http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8


 I have found one of the several voices that reminds us of the 
 advantages of dynamic typing:

 http://www.srl.inf.ethz.ch/workshop2013/eth-vitek.pdf

 (I was away for few days.)

 Bye,
 bearophile


 I started getting suspicious at the slide where (s)he claimed
 that 9.3% of the world's software uses Objective-C while 9.1% of
 the worlds software uses C++.  Thats a lot of people writing 
 apps
 for iPhones....

 I find that hard to believe, and I don't think that is what 
 TIOBE
 is even claiming to begin with. Looking at the current index I
 wonder how much stock you can put in those rankings anyway.

 Craig


While I am at it, I should point out that 3 of the top 5
languages according to TIOBE are static.  Not that I put any
stock in what TIOBE claims :o)



Craig
Oct 28 2013