dub: should we make it the de jure package manager for D?

[H. S. Teoh]

On Wed, Sep 11, 2013 at 05:11:38PM -0400, Nick Sabalausky wrote:
> On Wed, 11 Sep 2013 13:06:05 -0700
> "H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote:
> 
> > On Wed, Sep 11, 2013 at 03:17:22PM -0400, Jonathan M Davis wrote:
[...]
> > > Well, I hate that about python too, but what I _really_ hate about
> > > python is that it's dynamic. It shouldn't be possible to do things
> > > like change the type of a variable based on whether an if
> > > condition was true or not (or change the type of a variable at all
> > > for that matter).
> > 
> > Yeah, this is something oft touted as being 'convenient' and 'easy',
> > but then in production code, you find yourself writing type checks
> > anyway just to make sure what's passed in is what you expect. (And
> > things blow up in horrible ways when some stray code passes in
> > something with the wrong type.) Which defeats the purpose of having
> > a dynamic language in the first place.
> > 
> 
> My feelings on it exactly. I also found the implicit member declarations
> and its inability to match software to the correct runtime (like Java
> does) to be major problems, too:
> https://semitwist.com/articles/article/view/why-i-hate-python-or-any-dynamic-language-really

Yeah I remember reading that. I haven't had Python blow up on me like
that (yet), but I first ran into this problem while writing some JS
code.

That was when I had to write some complex code to handle client-side
dialogues (yeah, *those* ugly things), and, in an effort to prevent the
code from becoming one long, winding spaghetti noodle, I decided to
factor out common bits into functions -- you know, typical structured
programming textbook exercise. Then things stopped working, and I
couldn't figure out why. Eventually, after many hours of hair-tearing
frustration, I found out that some stray code was passing in the wrong
object to one of the functions.  But of course, the JS interpreter
couldn't care less -- there's no type system for a type mismatch to
happen, so it just barged ahead and did who knows what with that object
of the wrong type, until it tried to look up a non-existent field, which
*conveniently* returns null. This gets assigned to another field in
another object, and *then* when that other object is finally used much
later on, it gets a null dereference exception.

But this is JS we're talking about. What happens, boys and gals, when
the JS interpreter encounters an uncaught error? That's right, it logs
an error message to the error console (which is hidden by default in
most browsers), and silently fails without any warning, and then the
rest of the site's scripts (hooked to various event handlers) CONTINUE
RUNNING AS IF NOTHING HAPPENED.  I'd really like to know which genius
came up with this totally dainbramaged idea, because I'd *really* like
to slap him upside the head.  Can you imagine the kind of field day the
blackhats would have if, say, C code running on enterprise servers were
to blindly continue running after dereferencing a null pointer?  And now
they want to put JS on the *server*? Gives me the shudders...

Seriously, this is just like writing assembly code in 1975. Screw up a
single opcode, and the computer just blindly barges onward interpreting
random bytes as instructions, wreaking havoc to your entire system while
you stare at the screen believing that it's still computing what you
think you told it to. Who knew that JS was an underhanded way of getting
people to write assembly code by hand again? :-P



> > > > But I've never used YAML, so I can't say whether or not I'd like
> > > > it.
> > > 
> > > JSON is a subset of YAML 1.2, so they're very similar. Probably the
> > > most obvious differences are that you don't need as many quotes in
> > > YAML, and whitespace matters. I've had to deal with it some at work,
> > > and I hope to never have to deal with it elsewhere.
> > [...]
> > 
> > Wait, how can JSON be a subset of YAML if whitespace in YAML is
> > significant, but it isn't in JSON?
> > 
> 
> Whitespace is only sometimes significant in YAML. On the JSON
> constructs, it's not significant. On certain (all?) of the non-JSON
> YAML-specific things, then it's significant.

Yikes. So whitespace is neither always significant nor always
insignificant, but *sometimes* significant? Then I have to agree with
Jonathan that YAML is truly evil!


T

-- 
All problems are easy in retrospect.