davelnewton

IMO that's an explicitly different issue than a comparison between Promises/async/await and Ruby's metaprogramming, though.

Not to mention that part of the issue with Promises is the various polyfills invented before broad acceptance, which is a separate can of worms, and a different type of complexity than the (relatively) heavy use of metaprogramming in Ruby (relative to JS).

Promises/async/await seem very different than Ruby's (and Rails') metaprogramming to me. I'd need an example of a cryptic stack trace to know exactly what you're referring to--half the problem is because of the overuse of anonymous functions that bork the trace. There's an easy solution to that (and it makes the resulting code easier to test as well).

Couldn't disagree more, but I think you're taking the term "magic" too literally.

There is a ton of magic in Rails. It consists primarily of magic. I've been doing Rails since <1yr of introduction (Ruby for longer than that, and Lisp for longer than either). I'm very familiar with metaprogramming. Metaprogramming fits the canonical definition of magic in this context.

Ruby, and Rails, also makes it very easy, and seductive, to add more magic. This is powerful, but dangerous. Like Lisp macros. Understanding the magic is not just a matter of "understanding the conventions" and reading the docs.

DI/IoC is a separate thing from the ecosystem; the benefits are just as strong in JS or Ruby--it's just that in JS/Ruby some of the benefits aren't as noticeable because of language malleability and openness.

> Python already exists as a dynamically-typed server language.

Ruby isn't new; it's only slightly younger than Python, and brought things to the table. Rails and Django are roughly the same age (and Django started off more as a CMS). That Python exists isn't an argument against Ruby. Lots of other languages exist, each with their own cost/benefit tradeoffs.

> [...] writing server-side web stuff in JS does make sense given it's what you're using in the client.

I don't understand the argument. Matching client/server language is a different goal than matching task/language, and the task isn't the only driving factor.

There's some crossover in that the language is the same, which means you could standardize on JS developers, but the ecosystems are not the same, and the required overall skillset is different. In wee shops the tradeoff may be worth it, but at scale, the benefit is oversold.

Of those three? Python. Why? Lots of stuff built in or well-known.

But it's almost entirely irrelevant: reasonable companies will either (a) expect you to code in the language they're hiring for or something at least used within the company, or (b) not care (within reasonable bounds, e.g., don't do your interview in Piet).

Winter is coming.

I don't know why not; IIRC FireWire was LVDS (4+m), and LVDS doesn't specify ("care about") distance, just loss between driver and receiver. I vaguely recall lossless transmissions between 10-30m, which is more than enough for a vehicle.

Trivial hacking is probably unlikely. Vehicles generally use CAN bus, but whether or not the camera data is available on the bus... I have my doubts, but if it's there, that'd be pretty cool. My guess would be there's a dedicated image channel off the main bus--but that's just a guess. I'd be interested in knowing if it's on the general network. It is peer-to-peer so in theory it can be deterministic, so maybe it is.

I disagree. This doesn't "diminish the person's feelings", it's saying that feelings aren't always relevant. Not being motivated is part of life. If something must be done motivation (or its lack) doesn't matter. Sometimes the suck must be embraced, feelings be damned.

> Your remarks here strongly suggest my conclusion was spot on.

I believe it suggests what I said in the comment above: you're putting the onus on women to "know what works" instead of on men/whoever.

> Your remarks here are simply convincing me that your ideology and mine are fundamentally incompatible.

That is why the world is in the state it's in.

But it is more or less what you said:

> [...] women need to know what works and what doesn't.

I think men and women need to not treat people as sex objects regardless of how they dress. Saying that "women need to know 'what works'" is precisely victim-blaming, because it puts the onus on women, not men, to be responsible for men's behavior.

(Any genders above can be replaced with any other gender classification; it's irrelevant to the point.)