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 # And then in some seldom-executed branch.. 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 # do something with i ^ - 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 puts foo # calls the getter foo = "asd" # declares a local variable self.foo = "foobar" # calls the setter foo = "barfoo" # bypasses the setter and set the instance variable directory puts foo # prints the local variable 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) And #5 is everyone's favorite PHP (for October 2013)! Craig
Oct 28 2013