Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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 hst...@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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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 hst...@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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Fri, 18 Oct 2013 12:44:59 +0200 Chris wend...@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 :)
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Friday, 18 October 2013 at 12:22:16 UTC, Nick Sabalausky wrote:
On Fri, 18 Oct 2013 12:44:59 +0200
Chris wend...@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;
}
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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!
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
+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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Thu, 17 Oct 2013 15:26:41 +0200 Chris wend...@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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wed, 16 Oct 2013 23:00:04 -0700
H. S. Teoh hst...@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)
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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 :)
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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?
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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%?
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Oct 15, 2013, at 5:30 PM, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Tue, 15 Oct 2013 15:15:45 -0700 Walter Bright newshou...@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. 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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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 :)
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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?
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wed, 16 Oct 2013 10:26:37 -0700 H. S. Teoh hst...@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.)
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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 -- Маленькие детки - маленькие бедки.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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 :)
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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!
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wed, 16 Oct 2013 13:57:50 -0700 H. S. Teoh hst...@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/
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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 hst...@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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Tue, 15 Oct 2013 15:15:45 -0700 Walter Bright newshou...@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
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Tue, 15 Oct 2013 15:15:45 -0700, Walter Bright newshou...@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/
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Tue, 15 Oct 2013 15:15:45 -0700 Walter Bright newshou...@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...
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
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
