As a white midwesterner working in CA, I can sympathize with the idea that CA tech companies have toxic cultural problems. I can only imagine what it's like to be a black dude.
CA runs on passive aggresive behavior. It can be psychologically damaging to someone who grows up and has worked with real people their whole life.
While I wouldn't want to program in a pure functional, no side effect language, a good mix of differing paradigms seems to me to be the way to go. Java and.NET went overboard on the OOP, and it leads to these poor abstractions in many cases (I.e. AbstractFooProcessor), which are much better approached with some FPd
Pure functional code is super easy to reason about, though, especially asynchronous code. OOP has its role, but oftentimes you find yourself on loose footing, with its focus on always changing state. This can be addressed with good practices, which leads you down class hiearchy hell. Throwing some FP in the mix gives you (mostly) the best of both worlds.
Seems pretty relevant since the question "who sells Linux PCs" comes up on/. every two months, and the response is always "System 76" to which someone always replies, "they just rebrand Company X's laptop, why not just buy one of those instead?"
No one has to set prices. You simply set emission standards by granting a certain number of carbon credits which can be spent to pollute. The price is determined by free trade of said credits.
Still a dumb idea, because using markets to solve environmental issues (especially global ones) is terribly inefficient and subject to abuse.
We COULD solve water quality issues with no regulation on pollutants, but by slicing up the waterways with private rights. Most people rightly see this as a horrible idea that only works on paper.
For some reason, those people seem to think it will work for carbon, though.
Ahhh, but there is a distinction between a nutritionally healthy product and a health food product. One is defined by science and physiology, the other is defined by how it appears when you post about your consumption on Facebook.
Their business model appears to be effectively based upon self-driving vehicles. Human drivers are just a stop-gap for bootstrapping the business, so the investors subsidize your ride to get market share now, and later they will reap the profits when they can fire all their drivers.
I do not understand what is hard about encapsulating code. There are no hoops. Module encapsulation just works. What am I not understanding?// readval.js module.exports = () => 42;// other.js const readval = require("./readval"); const otherreadval = require("someone-elses-readval"); console.log(readval()); console.log(otherreadval());
Re: K&R, just pretend you're at a REPL. If what you're doing would confuse a REPL, then it's not going to work as expected in JS.
That said, very little JS uses K&R for anything because it is an absolute mess when you start using inline callbacks. If you want to be a special snowflake, then you can use whatever format you like by using a var/const instead of a literal, but perhaps you should get over yourself and just do it the "normal" way.
Here's a quick study guide, if this is too hard to mentally map type checks:
* if it's a degenerate value, such as null or undefined, use ===
* if it's a scalar like a number or string, use typeof
* if it's an object (yes an array is an object), use instanceof for classically inherited types (which includes all buit-in types), and isPrototypeOf for prototypally inherited types.
Tough to say. Global-everything is a valid paradigm for tiny projects. If tasked with re-doing JS, I'd think long and hard about invalidating a legitimate paradigm, even if it's a paradigm I wouldn't use. That said, until using JS, the thought would not have occurred to me that you might want that.
Says someone who doesn't write JS for a living. Any problem "namespaces" are intended to solve are addressed trivially with just module names, and the paths inside them. If you feel like you need a namespace in JS, it's probably because you made everything global.
I'm typically targeting an older version of the language which doesn't support block scoping yet. Every once in a while, I kind of wish I could block scope a for loop counter. But 99 times out of 100, I'm using something like.forEach(), or.map(), or.reduce(), which give you a function scope, anyway, so it's not too bothersome. And block scoping IS available in the newer version of the language, so it's really an annoyance I push on myself. I certainly can't blame the language for not using a feature it actually supports.
So, if you have no use for a sloppy equality test, why would you use it? I personally can't remember the last time I've used it, but having an operator I never really have a use for has never once impeded my ability to get shit done. Do you have some sort of arthritis that makes that third "=" painful to type, or is the arthritis in your head?
Slashdot Mirror
As a white midwesterner working in CA, I can sympathize with the idea that CA tech companies have toxic cultural problems. I can only imagine what it's like to be a black dude.
CA runs on passive aggresive behavior. It can be psychologically damaging to someone who grows up and has worked with real people their whole life.
Who are you to dictate to others to ignore a biological imperative? You sound like all those scientists who thought eugenics was going to be awesome.
Google Fi.
Because the cost of care is driven by the non-single payor market, leaving VHA underfunded.
While I wouldn't want to program in a pure functional, no side effect language, a good mix of differing paradigms seems to me to be the way to go. Java and .NET went overboard on the OOP, and it leads to these poor abstractions in many cases (I.e. AbstractFooProcessor), which are much better approached with some FPd
Pure functional code is super easy to reason about, though, especially asynchronous code. OOP has its role, but oftentimes you find yourself on loose footing, with its focus on always changing state. This can be addressed with good practices, which leads you down class hiearchy hell. Throwing some FP in the mix gives you (mostly) the best of both worlds.
Seems pretty relevant since the question "who sells Linux PCs" comes up on /. every two months, and the response is always "System 76" to which someone always replies, "they just rebrand Company X's laptop, why not just buy one of those instead?"
No one has to set prices. You simply set emission standards by granting a certain number of carbon credits which can be spent to pollute. The price is determined by free trade of said credits.
Still a dumb idea, because using markets to solve environmental issues (especially global ones) is terribly inefficient and subject to abuse.
We COULD solve water quality issues with no regulation on pollutants, but by slicing up the waterways with private rights. Most people rightly see this as a horrible idea that only works on paper.
For some reason, those people seem to think it will work for carbon, though.
Ahhh, but there is a distinction between a nutritionally healthy product and a health food product. One is defined by science and physiology, the other is defined by how it appears when you post about your consumption on Facebook.
Loved Event Horizon. Easily the best horror sci-fi movie next to Alien.
No true Scotsman would agree with your assessment.
Network effects, deals, name recognition: the usual. Even if they only dominate the world market for a half decade, it could be worth a shit ton.
Their business model appears to be effectively based upon self-driving vehicles. Human drivers are just a stop-gap for bootstrapping the business, so the investors subsidize your ride to get market share now, and later they will reap the profits when they can fire all their drivers.
I am terribly sorry about the formatting.
I do not understand what is hard about encapsulating code. There are no hoops. Module encapsulation just works. What am I not understanding? // readval.js // other.js
module.exports = () => 42;
const readval = require("./readval");
const otherreadval = require("someone-elses-readval");
console.log(readval());
console.log(otherreadval());
I agree. Working with shitty devs sucks. You can write Fortran in any language.
Re: K&R, just pretend you're at a REPL. If what you're doing would confuse a REPL, then it's not going to work as expected in JS.
That said, very little JS uses K&R for anything because it is an absolute mess when you start using inline callbacks. If you want to be a special snowflake, then you can use whatever format you like by using a var/const instead of a literal, but perhaps you should get over yourself and just do it the "normal" way.
If you don't know what types you're working with, why don't you just cast them?
String(a) + String(b) or Number(a) + Number(b) is pretty easy.
If you're arguing that JS exposes you to your own sloppy conventions, then I agree.
Here's a quick study guide, if this is too hard to mentally map type checks:
* if it's a degenerate value, such as null or undefined, use ===
* if it's a scalar like a number or string, use typeof
* if it's an object (yes an array is an object), use instanceof for classically inherited types (which includes all buit-in types), and isPrototypeOf for prototypally inherited types.
Tough to say. Global-everything is a valid paradigm for tiny projects. If tasked with re-doing JS, I'd think long and hard about invalidating a legitimate paradigm, even if it's a paradigm I wouldn't use. That said, until using JS, the thought would not have occurred to me that you might want that.
Says someone who doesn't write JS for a living. Any problem "namespaces" are intended to solve are addressed trivially with just module names, and the paths inside them. If you feel like you need a namespace in JS, it's probably because you made everything global.
If you declare all your vars at the beginning of a scope, how is it different than outer-inner scoping?
I'm typically targeting an older version of the language which doesn't support block scoping yet. Every once in a while, I kind of wish I could block scope a for loop counter. But 99 times out of 100, I'm using something like .forEach(), or .map(), or .reduce(), which give you a function scope, anyway, so it's not too bothersome. And block scoping IS available in the newer version of the language, so it's really an annoyance I push on myself. I certainly can't blame the language for not using a feature it actually supports.
Fuck I almost never use bitwise or, either, but god damn, it doesn't bother me that it's available.
So, if you have no use for a sloppy equality test, why would you use it? I personally can't remember the last time I've used it, but having an operator I never really have a use for has never once impeded my ability to get shit done. Do you have some sort of arthritis that makes that third "=" painful to type, or is the arthritis in your head?
Idiosyncratic? Sure. But it takes literally an afternoon to learn the entire language. Unless you're a moron.