1,283 karma · joined July 25, 2013
If you haven't already, look into Certificates of Deposit ("CD") at your local bank. They're FDIC insured (so if the bank goes under, you're covered, up to something like $250k) and you don't have to worry about losing the principal amount you put in. If you ever need to withdraw that money in case of an emergency, you only risk losing out on the interest. Instead of dumping a ton of money into a single CD, look into CD laddering wherein you setup multiple CDs that expire in 3 months, 6 months, etc or some other cadence that you're comfortable with.
The fact that this was once the norm but has since been done away with saddens me. I've always been fascinated with "live environments" but felt they only went half way if they didn't include the source code itself. If I'm going to be updating something in a running system, I want to know what source code was used to get the system to the state its currently in, and preferably be able to query that source code as data. Of course, that code could be kept within source control, but then it's a shadow of the running system -- a map of the territory and not the territory.
As far as I know, the only languages/environments where this functionality is still available are Tcl, Smalltalk, and to some extent stored procedures within an RDBMS.
Guns aren't the root problem but their accessibility is an enabler -- a multiplying force for opportunistic carnage.
>Any reasonable person will understand that making such judgments is an ongoing process.
This goes against what we've seen with mass killers and the third parties involved: Average, every-day people convince themselves that their loved one / friend will get over whatever they're dealing with. We also know that many of these mass killers are sociopaths and have no difficulties in acting normal and hiding their motives.
Gun violence solved: Just don't have an irresponsible person in your home.
It's not like people have mental breakdowns or have an onset of a mental illness, right? Of course not, once responsible, always responsible.
>With the Sandy Hook shooting, was the owner of the gun prosecuted for allowing the shooter to have it?
No, because she was the first person killed by the very weapon.
I don't think you're arguing in good-faith here. The Misdeeds of criminals? It's not like mass shootings are carried out by felons. They're carried out by mentally ill people that have access to guns they should not have access to. They're not criminals until they take action.
The problem is that guns are so readily available that even those that cannot use them responsibly can still get their hands on them. Three of the four guns used in Columbine weren't even purchased by the killers but by a fellow school mate who had turned 18 and could buy them for the killers. Similarly, with the Sandyhook shooting -- it wasn't even the shooter's gun that was used.
Ah yes, the classic example of little old ladies defending themselves. This is pretty much a "think of the children" trope.
PHP, Perl and Swift all have first-class functions, lambdas and closures although I'd agree that that's not "most." This is probably getting too much into semantics, but aren't functions in JS just objects themselves? ;)
>People stress about "writing unit tests" because technically correct types doesn't mean your program actually works. In my time writing JS vs TS, I've seldom found that type errors were the problem aside from making the type checker happy. Most errors are in what the code actually does or does not do. The instant feedback from the entire system is far superior to unit tests because it can catch things that your unit tests might not be testing for.
I don't think having a "live" system like CL precludes the need for unit tests. Sure, it's beneficial to be able to play around with code right away, but unless you're planning on manually running through the same tests again and again, how do you know you've not introduced a regression at some point?
Edit: The two threads of execution I mentioned above are likely what the combination of SLIME + Swank are doing.
This sounds very similar to how Verdox[0] is approaching the problem. What sets your approach apart?
I worked for a company that microserviced themselves into a pit. We had a huge layoff which completely killed the morale of the remaining engineering staff. Over the next 3 years, more and more engineers left and the company refused to replace them. What started out as teams (~5 people) responsible for ~3 microservices ended up as teams of ~3 people responsible for ~6 microservices.
It was kind of cool to be responsible for more architecture and see how it all fit together, but the sad reality was that too many of the microservices that had been stood up were stitching together disparate data from other microservices to then perform what a single SQL query against a RDBMS was doing.
>A good Java API wouldn't have many Setters/Getters that do nothing but set/get references to internal objects, but rather ones that parse and make sense of it's internal state.
I completely agree. Getter/Setter obsession often leads to breaking the Law of Demeter in most Java code bases I've seen.
I think it's interesting to think of the receiving side of this as well: how stable are democratic allies when their foreign policy can change election cycle to election cycle?
I'm not the GP, but I think this is off the mark. There's a big difference in purposefully choosing boring technology and purposefully taking pride in not knowing things.
>...Java software is designed as big C-style procedures which call into APIs using object methods.
Do you mind going into more detail regarding those two styles in Java? I wouldn't exactly say that Java shepherd's its programmers towards the message passing style at all.