jcizzle

Sorry, but a $1.2m house, including mortgage, taxes, insurance and the general cost of owning a home is not affordable to someone making 200k/yr, much less the $180,000 down payment you are suggesting. That isn't to say it is impossible, but the house would own you.

I got the same impression that this guy did from your article, as well. It sounds like you are taking your limited experience and projecting it through the lens of various media (which includes places like this) to come up with an understanding of what 'the industry' is. You may be 35 years old, but in the same way 'number of years experience' doesn't make someone a good programmer, number of years living doesn't necessarily make someone wise. It's OK to fire off some thoughts, but don't be surprised when people with a different perspective and more wisdom let you know you're missing some pieces.

I'm a programmer. Written 4 programming books - all Amazon best sellers. Just happened to also start running a company. After enough growth, bringing in a business partner to focus on non-engineering tasks was an important step. Having been on both sides, I value both as different skills. One is not inherently better than the other, but I've found that a person who is either and respects the other is often successful. A few million dollars later, I'd say I've been right.

If I may ask, what have been your successful ventures? How successful? What would you say your net worth is? In other words, to make your argument resonate with me, I'm more interested in how well your belief system has worked for you, as opposed to "number of years experience."

It doesn't make much sense that I've provided you with anecdotal evidence, as I have not provided you with any evidence at all. My suggestion was that you do real research on the topic. You've made a number of generalizations that you should really research. Factor out just one of your statements and describe each item in it. 'These people HAVE TO HAVE MONEY' - who are these people and how much money should they have? How much are their jobs paying them and how much tax payer money is making up the slack? What is the slack? How do health care and food stamps go away with higher wages? What are 'higher wages' in this context? How are we giving money to the corporations? Who is we in this sentence? Once you start to answer those questions with real evidence, then you can come up with solutions to each of those problems, create models for how those solutions will impact other problems and existing solutions. I won't tell you what you'll find, and I doubt you'll actually follow through, but it is unlikely that you'll persuade anyone with the current form of your argument.

I think you should put some time and effort into researching who in America works for a minimum wage, how long they work for minimum wage, what economists think about minimum wage. I typically find that if I find something 'crazy', and can't believe that 'the other side' would have such an ignorant view, it just means I don't understand the problem.

I think the important thing about Erlang (the system as a whole) is that you really have to understand what it does first. It's not one of those platforms you just jump into and start toying around and then maybe things work 'good enough.' Once you do understand what it does, though, it is exceptionally good at that.

This post does a great job of explaining what Erlang, as a whole, does and why it does it.

This is true of all subjects, though. The purpose isn't to train world class engineers out of high school, it is to expose more people to the subject and the thought processes that go into it.

It's true of iOS as well, it's just that the default function pointer logs then terminates instead of just logs.

He can't solve this problem without using a base class, so he wants to go back to Objective-C where he will use a base class? Objective-C does not have a better solution - it has the same solution here. The only difference is that ObjC will let you do what he is trying to do where the actual result is incorrect. That doesn't make Swift inherently better, it means he is wrong. OP is not making a convincing argument, and this isn't a point about Swift vs. ObjC. OP is just complaining because they don't understand what it is they are doing.

Not saying Swift doesn't do that, saying he's doing it wrong. Protocols can still be interfaces (what he and you are describing), there is no loss. Two types that simply implement a similar protocol are by definition not necessarily equatable. The 'standard' way that Objective-C implements isEqual: is on a base class, which is a totally possible implementation in Swift as well.

This is all possible - the issue is that you still must define equality if you want to put it in a collection that cares about equality.

This isn't a limitation of Swift, this is someone trying to write Objective-C in Swift.

Let's say he gets what he wants - a distinct collection of instances that fulfill the 'Account' contract, but are different types. The approach so far is that to fulfill 'Account' by providing an accountID. That accountID is what indicates if two 'Account's are equal. What if a Twitter account and Hacker News account have the same id? According to this protocol, they are equal.

The error message he is seeing about Self requirements is telling him this. That error message doesn't exist because Swift is having a hard time understanding the code, it exists because Swift understands that his code is wrong.

Some of this is just poor style/naming conventions, some of it is simply implemented incorrectly and the rest of it removes necessary distinctions from important functionality.

It is just a simple example to convey that a portion of foo/1 contains a case statement, and that case statement is being replaced with a function. There could be more lines in foo/1. The point is that both the case statement and the multi-clause function are identical in behavior, but the function prevents nesting at the call site.

I view it differently. In the same way a lot of online forums shadowban people, I look at Nextdoor as a shadowban from real life. Here these crazies are, thinking they're having this change-making dialogue with their neighbors, but in reality, they're just posting to a void on the internet while the real life version of their neighborhood continues on. (Also, the forum moderator was deleting posts from anyone that was kindly pointing out "hey, this isn't real neighborly of you.")

We recently deactivated our account. We were excited about the idea of being able to informed of our entire neighborhood, not just our street. Instead, we found out that in our neighborhood of 8000, there are about 50 crazies that spend all day posting on Nextdoor, and everyone else had basically given up. In the real human interactions I have with neighbors, 'How's the weather?' has been replaced with 'Did you see that Nextdoor post? That was hilarious!'

Some gems in recent memory:

1. Someone posted an urgent 'BOLO black men with what appears to be a weapon or something to be used to break in to houses' accompanied by a picture of a man with a rake. Another neighbor commented, "That's my landscaper and he's been my landscaper for 10 years".

2. A heated debate over tearing down old houses and replacing them with bigger ones ended up with a guy crawling into someone's backyard, taking pictures of their house, and posting them and critiquing their design choices on the forum.

3. A neighbor created a small sculpture of stacked stones, each stone being about fist-sized. Another neighbor posted photographs and personal information, asking that he take the stones down, because if they fell on a kid, he would sue him.

4. Multiple occurrences where someone posted 'surveillance' video of dog poop not being cleaned up, which always resulted in another neighbor identifying the dog owner, and the dog owner almost always being an elderly woman, who embarrassingly had to indicate she ran out of poop bags but went back later to clean it up.

Huh, I thought the 'Reformat to Dart Style' option in IntelliJ was using dartfmt and I was so disappointed at its output I stopped using it. Just went and tried dartfmt from the command line after reading this - dartfmt is significantly better. Fun to hear the approach that went into it.

For anyone that hasn't tried it, grab the Dart SDK and the IntellIJ Dart plugin. Takes less than 5 minutes to setup. It's been a great platform for building server side stuff - I haven't tried it for front end web stuff. It took about 3 reads of the language tour (https://www.dartlang.org/docs/dart-up-and-running/ch02.html) and about a week and I already felt very comfortable with the entire platform.

1. This happened in rural Georgia, far away from Atlanta.

2. The suspect was later arrested for dealing meth. This isn't a little dime bag situation as the clearly biased writer would have you believe.

3. This isn't the suspect's first arrest, he was arrested before for distribution. Police found an AK-47 in his house.

Here are things that could have been done to prevent this situation. 1. The homeowner could have not dealt meth. 2. The parents could have not moved in with their AK-47 owning, meth dealing nephew.

Here are some likely other outcomes even if the SWAT raid didn't occur: 1. One of homeowner's guns could have accidentally discharged and killed the child. 2. Criminals could have robbed the house (a higher likelihood when you are running a drug ring out of your house) and killed the child.

That poor child's situation is a direct product of irresponsible parenting. There was a reason the police were at this house. Their tactics and the damage they did would have not been remotely possible if this guy wasn't armed with illegal weaponry and dealing drugs.

This isn't reddit. America is not out to get you. Don't be a criminal and don't associate with criminals and this doesn't happen to you.

Little is known, but here is an interesting writeup on the topic: http://www.eswick.com/2014/06/inside-swift/

It's really not that big of a deal.

It was a tradeoff, for which they provide functions (unshare and copy) for opting out of the default behavior if you so choose.

You aren't hamstrung here. In fact, this Array behavior is going to be absolutely great for manipulating image and other fixed buffer operations. It's a week in, what looks like a wart today can be a great feature in the future.

At a certain point, we'll collectively have to realize that the people who jump to write opinionated articles on a technology that is 2 days old probably don't have a lot of facts or an opinion worth reading.

Until that day, this guy will have a job.

Lock-in? This argument - which we've heard before - makes the assumption that a programmer can only know one language at a time.

I get that some folks are fearful of change. You're in the wrong industry, then.

Thanks for the followup. Item #2 is a point very well taken and I'll be exploring that route, appreciate the response.

Great article, very much appreciate this guy and his blog as I continue to learn Erlang.

A question: the pattern of let it crash makes sense to me. However, I struggle with it when implementing RESTful web services. Letting the process crash will typically yield a 500 - the monitor on the connection process in the web server library ensures that. Clearly though, a status code and some additional information is a more appropriate response to the client. An example is returning a 400 for "missing arguments". In a contrived example of idiomatic Erlang, I feel like I'd write this:

    handle_request(Request) ->
        % username and password are required
        {ok, Username} = request:get_argument(<<"username">>, Request),
        {ok, Password} = request:get_argument(<<"password">>, Request),

        UserRecord = db:find(my_database, users, #{<<"username">> => Username}),
 
        Password = maps:get(<<"password">>, UserRecord),

        request:respond(200, UserRecord, Request).

And if the key username did not exist in Request, request:get_argument/2 would return undefined or {error, Reason}, giving me a bad match error. Or if the password didn't match, I'd get the same. In order to intercept that and return a reasonable status code, I would have to catch that in handle_request. My question, then, is am I missing a best practice on how to handle this? Or is this just the place where I do need to catch errors and process them? And if that is so, isn't it at odds with the whole concept of writing intentional code?

While I admire the goal, this solution makes me sad. If a dog needs more exercise, then it should be exercised more often. A responsible pet owner should know their schedule and lifestyle, and choose a dog whose exercise needs match that.

I find it unfortunate that some pet owners would absolve their responsibility towards their pet with a machine. There is great value to the relationship between a pet and its owner during both feeding and training. While it's neat that we live in an age where technology allows us such "conveniences", I think there is a point where you must ask yourself what is the point of life if you don't actually do anything meaningful? Bonding with a dog, if you have not experienced it, is a lot more meaningful than just making sure they don't shit on your rug while you're gone.

I cashed out my 401k to start a company. I was in a unique situation where I started contributing to my 401k at the very bottom of the recession (luck). The returns on my 401k contributions were greater than 100% by the time I cashed out because the market had fully recovered. The company I previously worked for had 100% matching up to 15k. So, I looked at the penalty and figured since I had quadrupled my money, 10% didn't seem like a concern next to the possibility of creating a successful business.

Ended up working out. Was able to make that money back 5x in 6 months. It was a risky move and I could see it not panning out more often than not. But, to go against the grain here: there is no such thing as 'never'.

Yes, it does. The number that matters is number of available black and hispanic tech workers versus the number of employed black and hispanic tech workers. If there was a large discrepancy between unemployment rates for technology workers along racial lines, then we could claim discrimination by companies.

Instead, what you and this article are talking about is that perhaps not enough black and hispanic people are being exposed to technology as an industry. In which case, the failure would be on a lot of variables: community, family, schools, socioeconomic status, etc.

Blaming a company for not hiring non-existent people is sure great for Jesse Jackson's business model, though.

Because the average reader may be inclined to think the numbers are reasonable, and then they'd be less likely to spark an outrage, and then this newspaper wouldn't get as many ad impressions.

You have to translate your strings to binaries before you try to encode to JSON. A JSON encoder has no way of determining whether it should be encoding an array or a string without this. Instead of one string type, you have "strings" and <<"strings">>, and due to the lack of typing, it is actually pretty tough to keep track of which one you have. It also is an exercise in finger acrobatics to <<>> all your strings.

JSON doesn't solve every problem. It does solve the problem, quite elegantly, of creating a 'endianless' interchange format that is easily consumed, constructed, and debugged.