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.
Etc. It's either happening, or would like to happen, all over.
Why? You can't understand what you can't measure. From city planning to business locations to traffic signals to targeted law enforcement to... If you don't know where people are you can't do anything except guess what should be done.
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).
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.
Knowledge is good. You may not have meant the onus on women--but to me it really sounded like it. By saying "women need to know what works" (again, to me) it sounds like "women need to understand that there is a certain way the world is, and if you want to fit in to that world, you must play by the world's rules".
My point of view is that if men are being assholes because BOOBIES!!1! then men are being assholes, and it's men who need to know "what works." The world's rules are skewed at the moment: IMO telling women that they need to know "what works" attacks a symptom, not a problem.
> [...] 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.)
... By writing, like you said. It's no more complicated than that.
That you're asking this here leads me to believe there's some unknown (to me) internal resistance holding you back: start writing. Write some more. Then write some more.
You might be interested in books like "Bird by Bird" (Lamott) or "Do the Work" (Pressman) etc. (I've read BbyB a few times, and am re-reading/-listening to DtW again as I plow through some drudge work that's necessary, but irritating.)
I suppose it'd depend on the definitions of "great" and "work". Original moon shots? Latex? In general, once you reach a critical mass of code, it stops being "great" and starts being "mundane", because "mundane" works.
This brings back memories... One of the greatest heads-down hacking I did was back in the day, running some variant of Common Lisp, working myself through Koza's _Genetic Programming_ book. The designs arrived at were literally non-human. The story of the FPGA tone recognition circuit (spoiler: lot-specific design) was delightful.
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).