austinz

I've been using Swift for personal projects. The company at which I work (it's a large social network that recruiters love) has a couple of small teams which have released or are working on apps written entirely in Swift. So it's definitely usable.

Good reasons to use Swift might include the following:

- You think you can make good use of the features Swift offers (generics, sum types, optionals, namespaces, typed containers) and are willing to not just write Objective-C code with a different syntax.

- You are willing to take a short-term productivity hit to learn a language which will probably become the crux of Apple's developer tools in the future.

- Your project isn't going to rely heavily on the dynamic features Objective-C offers (e.g. method swizzling, adding or replacing classes and methods at runtime).

Things that are troublesome with Swift include the following:

- Swift's interoperability with Objective-C and Cocoa Touch is still touch-and-go in a lot of places. It's been getting better, but unless you understand how both Cocoa Touch and Swift work, you will just have to take on faith things like IBOutlets being implicitly unwrapped optionals.

- Xcode's stability when it comes to working with Swift projects leaves much to be desired. The level of instability also seems to vary; I've worked on files that crashed SourceKit over and over and files that caused the IDE no trouble at all.

- I wouldn't call Swift alpha-quality, but there are still compiler and runtime bugs that need to be addressed.

(BTW I really wish HN supported proper lists in comments. Doing the two-space indent just makes everything run off the screen.)

Swift's Optional is just Maybe with some built-in sugar. Sum types are supported, with the caveat that the compiler is sort of broken when it comes to generics.

Personally, I just want higher-kinded types, and for the following code snippets to work as-is:

  enum Either<A,B> {
    case Left(A)
    case Right(B)
  }

  enum Tree<A> {
    case Leaf
    case Node(Tree<A>, A, Tree<A>)
  }

The first breaks because of the "Unimplemented non-fixed multi-payload enum layout" compiler error, and the second breaks because enums have value semantics. Both can be worked around in full generality by declaring a 'Box<T>' generic wrapper class, but that workaround is inelegant and cumbersome.

I think it also helps that, in practice, there seems to be a common philosophy (at least among the Clojurists I've talked to) that macros should be used only when absolutely necessary. Because of this, the sort of unrestrained, ubiquitous code rewriting that the author mentions is rare.

Even the Windows Java client installer tries to get you to install the Ask toolbar (or at least it did; I haven't seen an update recently). I imagine it must be quite lucrative for Oracle; either that, they stopped caring about Java's reputation as a user-facing technology for web content or desktop applications, or users just don't notice these things.

I always thought it was because both languages were (at least at some point) referred to and advertised as 'systems languages', which naturally invited comparisons. However, 'systems' meant different things for each language.

For Go, 'systems' as in the sense of software running on servers providing services to user applications.

For Rust, 'systems' as in the sense of (http://en.wikipedia.org/wiki/System_programming_language) - software such as OSes, device drivers, etc.

Just for fun, Swift is advertised as a systems language as well. In its defense, it does have facilities for bypassing the preferred way of managing memory (ARC) and working with memory directly.

I hope Rust gains traction as a language for targeting embedded systems. Rust has the following attractive characteristics for this particular domain:

* Minimal overhead (e.g. runtime), great for systems with very constrained resources

* More advanced language features than C (better macros, better type system, pattern matching, etc)

* Compile-time verification of safe usage of memory

* The ability to drop down into manual/unsafe mode for doing stuff like DMA or writing to configuration registers

c.f. this topic from a year and a half ago: https://news.ycombinator.com/item?id=6268291

I did a bit of embedded development (MSP430, Cortex M3, PIC18) some time ago, and I can say that having a language like Rust at my disposal would have drastically improved my productivity.

There are a lot of valid concerns with regards to Singapore's excessive central planning, governmental and social disapproval of nonconformity, etc. But this piece really does sound like the perspective of a disappointed poverty tourist. There is a huge difference between visiting filth and slums and red-light districts and desperate people struggling to get by, and having to live there all your life.

Singapore did a lot of things wrong, but part of the reason it is so (unnervingly) clean and prosperous and ordered is because the government has made an effort (not completely successful, and again perhaps with not all the right methods) to provide the denizens of the country with places to live and ways to make a decent living.

This is one of the worst parts of technical interviews.

"Take 10 minutes to write out code for this simple, abstract, poorly defined problem. Okay, now I'm going to ding you because you didn't write it using the same mindset you'd use when writing a large application tailored towards a specific domain and given a detailed set of constraints."

Maybe we should call this sort of cargo-cultism Schroedinger interviews. If you make your code simple and easily readable in order to solve the problem in the most intelligible way, you get penalized for not making your solution scalable/easily adaptable to "business requirement changes". If you structure your code so that it can easily be extended or modified you get penalized for YAGNI and premature optimization. Of course, exactly what the interviewer is looking for is never actually specified as part of the problem statement, because it exists in a state of quantum superposition until right before the interviewer decides whether or not he or she likes your physical appearance/sense of humor/"cultural fit".

This definition of "success" is pretty widespread. In the US, a college education is widely seen as a prerequisite to a middle-class lifestyle (never mind skilled trades or trade schools). Highly prestigious employers (especially in the financial or tech sectors) tend to show favoritism towards students with degrees from prestigious universities. There are analogous problems in Europe and India (e.g. the oversize social importance that IITs, grandes ecoles, Cambridge/Oxford hold). Trying to convince people that success should be defined by happiness or personal fulfillment, rather than social standing or wealth, is a very difficult problem.

Another factor is that a lot of parents in China either experienced significant material deprivation themselves, or are one generation away from people who did. So to these parents "success" through wealth (and hence security from poverty) takes on disproportionate importance. This sort of dynamic can also be seen in a lot of first-generation Asian-American households, often to the detriment of the relationship between the parents and their children.

That's real sad and all, but the root cause of the problem is far too much demand for a limited number of seats at the most prestigious schools. Until that underlying issue is solved (maybe through something akin to America's land-grant colleges?), the problem won't go away. Changing the admissions process will simply cause cram schools to be replaced by essay tutors, interview schools, students taking on an insane number of extracurricular activities, etc.

In short, the UN forces were able to drive North Korean forces out of South Korea. They then began advancing into North Korea. At this point China entered the war (under the guise of the PVA) on the side of the North Koreans, which was not something which had been anticipated. This resulted in several defeats, and the UN forces being pushed back towards the prewar boundary. MacArthur wanted the option to expand the scope of the war by using nuclear weapons against North Korea and northern China, which Truman didn't want because he was afraid that doing so would mean full-scale war against China and the USSR, and possibly an invasion of Europe by the latter while the US was tied down in Asia. The Wikipedia links posted by some of the other users make for interesting reading.

It should also be noted that North Korea, while the instigator of the war and a Communist country, was in a very different position in the 1950s. It was a richer country than South Korea until the 1970s, and South Korea at the time was an American-backed military dictatorship. While there may have been a moral argument to roll back Communism as far as possible, Truman's concerns about the geopolitical implications of expanding the war were very real, and calling them cowardice is a rather crude mischaracterization.

This histrionics-filled article is a waste of time. There is far more to software engineering than building mobile apps for either iOS or Android. Even back in 2010 it should have been abundantly clear that mobile was not going to subsume all of software engineering.

I really like this comment. It's kind and encouraging, providing actionable and constructive advice even while pointing out a rather serious flaw.

Having X number of days off for vacation per year is an explicit contract. Company culture can still be broken enough to not allow you to use those days, but in most cases the expectation is that the vacation days you've been given are yours to use to the fullest (making reasonable accommodation for scheduling, etc).

"Unlimited" vacation is an implicit contract. You can take off as many days as is considered acceptable by the company or team culture. This number is not something you can know before you start your job, and it is something that can change as workplace culture evolves.

The "unlimited" part is also a load of bosh. If the company culture isn't completely sick nobody is going to begrudge you using up your X vacation days per year. But if you take more vacation than average at a place with "unlimited" vacation you run the risk of looking bad and suffering attendant consequences. (I hate that "looking bad" is even a thing apart from actual effectiveness, but unfortunately it's something we still have to worry about...)

I think maybe the argument should be that C 'makes explicit' certain fundamental concepts - pointers and pointer dereferencing, explicitly choosing between allocating memory on the stack versus the heap, the idea that things like arrays, strings, objects, trees, etc can be built out of very basic abstractions. These are concepts that are important to know in order to really have a good idea of what is going on when you program in a higher-level language, even if you never actually do work that requires C's error-prone string handling or manual pointer manipulation.

I don't know if C is necessarily the best language to familiarize users with these concepts. Rust makes users grapple with the implications of explicit memory management but does so in a way that is far less dangerous at runtime than C (at least in many cases). So maybe figuring out how to reason about pointers and lifecycles and ownership in an explicit way in order to get a Rust program to compile is better than messing around with code that segfaults and does weird things until it happens to start working properly.

But I still think there is some value to hands-on experimentation. Concepts like "primitives are passed by value, but objects are passed by reference" in a higher-level language might seem like arcane trivia to a beginning programmer, but someone who has played around with the same idea in C (or another language where this sort of thing is reified) might be better positioned to understand the underlying rationale.

It would make more sense to contrast SpaceX with ULA or any of the other rocketry startups. Whatever long-term plans SpaceX have aren't very relevant to the current supplier-contractor partnership that SpaceX and NASA share.

You mean Celtic Tiger?

China's growth is 'sputtering' because the government is starting to make the sort of reforms that everyone said they needed to make to move growth away from being driven by debt-funded infrastructure spending, but were too scared of making because of the short-term costs. Now that that's happening, the media narrative has shifted to "economic growth targets dropped 0.5%; economy in imminent danger of collapse".

Basically, all forms of measuring GDP are 'accounting tricks' to some extent, or to be more charitable they are estimates based on necessarily incomplete data. For example, by its nature the informal sector can't be precisely measured, but its contribution to total economic output can't be ignored.

http://en.wikipedia.org/wiki/Informal_sector

Because each set of numbers measures a different set of things. Singapore and Luxembourg may have a larger per capita GDP than the U.S. or China, but the absolute size of their economies is far too small to allow them similar amounts of military or diplomatic influence compared to the larger countries. Likewise, a small country where everyone earns a lot of money is more attractive a market for a company selling luxury goods than a country where the total GDP is thinly spread across a large but destitute population.

Macros (the general Lisp concept) are really interesting. I'm still trying to grok them myself, so if I made any mistakes please downvote and correct away.

A normal Lisp function call might look like this:

(myfunc arg1 arg2 arg3)

where arg1, etc can be literals, variables, expressions. Like in most programming languages, each of the arguments is evaluated and then the function is called with the evaluated values of those arguments. When it's done, a value is returned.

A macro is a lot like a function call:

(mymacro arg1 arg2 arg3)

However, it works differently. First of all, the arguments are passed straight into the macro - if arg1 is something like (+ 1 2), the macro will see (+ 1 2), not 3 (as the function would).

Secondly, the macro is intended to return a list, which can be a function call or another macro call. (The macro could also return a final value.) The list can then be evaluated to either expand another macro, or to call a function to produce a final value. So you can think of a macro as a special sort of function that, rather than taking in values to produce another value, takes in literal code to produce transformed code (which then can be evaluated to produce a final value).

Now, one of the uses of macros that people cite is, for example, implementing your own control flow structures. Why are the two related? Lisps have something which are known as special forms, which look like function calls but don't have their arguments evaluated before being passed in (like how macros work). The reason that matters can be described by a simple example: let's say you wanted to implement a very simple version of 'and' as a function (Clojure syntax):

(defn my-and [left-expr right-expr] (if (not left-expr) false (if (not right-expr) false) true))

However, the problem is that left-expr and right-expr will both be evaluated before my-and can even begin executing, along with the attendant side effects, etc. The problem is that functions can't choose whether or not their arguments should or shouldn't be evaluated - they just get the values of their arguments after they've been evaluated[1]. It's not really possible to implement the traditional short-circuiting 'and' using functions, or many control flow structures where you do not want to evaluate every possible branch unconditionally.

However, macros receive the literal code comprising their arguments, and they can choose to evaluate one, none, some, or all of their arguments depending on their internal logic. This makes them better suited for implementing behavior that resembles those of the Lisp special forms.

[1] This is the difference between call-by-name and call-by-value semantics. Most languages are call-by-value, as described above, but (e.g.) Scala has '=>' and Swift has '@autoclosure' to allow for some sort of call-by-name support.

Python natively supports this sort of list comprehension (https://docs.python.org/2/tutorial/datastructures.html#list-...), and the Lisp source is being translated into a Python AST, so that snippet is probably being directly mapped into whatever AST form is necessary to invoke the list comprehension.

First of all, I want to say that if you like Java, and know it well, and believe it to be the right tool for your particular application, that you should absolutely use it.

> That Java is the right language for all jobs. (Emphasis his.)

> The advantages of C and C++ [...] don’t apply to my work.

So, choose the right tool for the right job.

As for the examples given:

> At one company I wrote a simulator that allowed me to run my Java services without a fully-functional site. (The unit under test is Java, so it makes sense to write the simulator in Java, rather than Javascript)

> My partner Dan Collens suggested Java [for a log parser], since it’s right there and we know it and it’s fast. (The log parser is used so often that the amortized opportunity cost of developing in Java is more than paid off by faster processing, therefore Java is the right tool for the job)

> And finally, I went to write a simple program that put up a web interface. (This is something the author has done many times before and knows how to do well in Java, and his primary goal is getting it running ASAP, therefore Java is the right tool for the job)

I still think you should choose the right tool for the right job. It just happens that the author's work is constrained in such a way that Java turns out to be the right tool in most, if not all cases.

Honestly, though, I would rather choose the same tool for a job each time by deciding that it's, by merit and virtue, the best tool for the job, rather than relying upon the author's silly heuristic.

Exactly what I was looking for. Thanks.

Are there any sources (besides this rather fantastical article) that BGI-Shenzhen is conducting large-scale research into the genetics behind human intelligence, and that if so that research is going towards some sort of comprehensive national eugenics policy? Has anyone else written about this sort of project? Or is this all just (rather misguided) wishful thinking?

> After a couple of generations, it would be game over for Western global competitiveness.

I would expect that providing proper nutrition, health care, and primary and secondary education to the majority of Chinese children (especially those in the marginalized countryside) would be far more important than having a handful of rich families gestating designer babies.

e.g. iodine deficiency:

1996: "The World Health Organization says that of the estimated 1.6 billion cases worldwide of iodine deficiency, nearly a third, or 500 million, are in China." http://www.nytimes.com/1996/06/04/world/china-confronts-reta...

2006: "After a 10-year government campaign, over 90 percent of people use iodized salt, still leaving 100 million facing deficiency." http://www.nytimes.com/2006/12/16/health/16iodine.html

This is an excellent example of what is wrong with China journalism today, drawing sweeping conclusions based on a handful of cherry-picked anecdotes. For an article with actual analysis, try http://www.economist.com/blogs/freeexchange/2014/11/chinas-i....

This is a great, well-written article. I'm going to try it out later tonight. Hopefully going through a real-life example will make LYAH a little less cryptic.

Sometimes I wonder: if Apple's new language had been Go, and Google's new language had been Swift, how would reaction by developers and adoption have differed? (You can also run this thought exercise with Go and Rust, if you prefer a different competition between self-proclaimed systems languages.)

When they explain to me how ISRU (in-situ resource utilization) can fabricate a replacement for a blown microchip or a refrigerator's compressor - based only on the equipment you can bring to Mars in a couple of space capsules - I'll be ready to begin seeing Mars One as something other than an insane pipe dream.

This article nails it: these people would be living an 18th-century lifestyle. But it would be one utterly dependent on 21st-century technology for something as basic as breathable air. If their 18th-century lifestyle can't keep their 21st-century technology working, and the organizing company can't drum up enough money to send regular resupply flights for decades to come, they die. Simple as that.

The magic shuttle craft sort of moved the movie into space opera territory for me as well. I couldn't stop thinking about how advanced the shuttles must be as that one waterlogged landing craft took off from a 1.3G world orbiting a massive black hole and entered orbit without breaking a sweat.

Unfortunately, realistic Apollo LM ascent stage-style SSTO (as opposed to easy magical SSTO) doesn't seem to be compatible with landing on and exploring the sorts of uninhabited planets which would be of interest for human colonization.

I thought the explanation of how the Blight was going to render Earth's atmosphere unbreathable was sort of unbelievable. The Blight's metabolism excretes or produces nitrogen gas at such a high rate that the percentages of the atmosphere's constituent elements are going to change drastically within a single generation? (c.f. the scientist saying that the last people to starve would be the first to suffocate.) Is that even possible? I mean, we burn fossil fuels and emit CO2 like the dickens, but nobody is arguing that we're going to die of CO2 poisoning instead of being threatened by global warming.

Also, near the beginning, the ersatz Predator was supposedly solar powered (hence being in the air autonomously for ten years), but when it lands it's just a metal plane.