flipgimble

My experience is that “talent” in a superstar city jumps around between major companies every year or three in search of better salary. There is an expectation then that each new hire is immediately put to work and depending on your level, you are coding almost 100% of the time.

I’ve now lived in a much smaller city for the past 5 years. My company hires both senior developers tired of the mercenary treadmill as well as many recent grads that stay for longer than three years since we invest in their career growth and provide much more mentorship. Also the biking distance commute to work are a big selling point.

I loved living in a big city in my 20s but don’t regret moving away in my 30s. my quality of life and financial freedom is immeasurably improved. This regularly surprises my acquaintances that stayed.

Like many others posting here I’ve followed John’s work frOm the mid 90’s so here is my take:

* he has an exceptional quality of cutting through the bullshit and shipping practical software, which is arguably what the vague and uncertain field of AGI needs. If you listen to AGI conference talks in recent years they are focused on aspirational single-idea academic frameworks that haven’t produced results in decades.

* he is still connected to Facebook with billions in resources, and a world class ML team with Yann LeCun at the head.

* his personal brand has been strong enough to have world class developers flock to Oculus. When he is ready to expand his “Victorian Gentleman” alchemy lab with a team, I have no doubt it would be a field-changing think tank.

My hope is that he continues to be open and brutally honest with his progres and learnings as he’s been with game development and rocketry.

In reading comments about Swift on this and other HN threads I see a lot opinions that in my experience are completely off the mark: a) "Apple cares only about iOS so thats all Swift will be used for" b) "Swift is in fact slow, look at this (naive) swift code vs. this (heavily optimized) c/c++ code".

While for people who take time to really work with Swift (yes those are often iOS and Mac developers by necessity) come away with an opinion that Swift is really a diamond in the rough, a new generation of a language co-evolving along with Kotlin and Rust. One distinction is that Apple can afford to hire top-tier compiler developers (including the founder of Rust) and invest heavily in tooling and growing the Swift ecosystem. They can pull off projects like ABI stability which took more than a year of focus for the whole team.

I point this out because the is always some sort of opportunity where widespread public perception is so mismatched against reality. I predict in the future there will be some tech startup that will go all in on the Swift ecosystem and be able to run circles around the competition.

Note for responders: I'm not saying the languages aren't just as good, or better. I'm not excusing the fact that Apple definitely dictates the priority of where the compiler team invests their time.

Related to the post, I highly recommend reading "The Knowledge: How to Rebuild Our World from Scratch" [1] if you are interested in foundational technology that underpins our civilization. This type of information is often forgotten or taken for granted in our highly dependent late-capitalism society.

[1] https://en.wikipedia.org/wiki/The_Knowledge:_How_to_Rebuild_...

Agreed, this tradition needs to die a quick and quiet death. I actively avoid the internet on April 1st because of it.

The problem is that the April Fools "sense of humor" is mostly of the "amateur thinks they are funny" quality. The pranks are mostly tech geek inside jokes that look embarrassing to anyone outside that social bubble. I admit I'm inside the same geek bubble but at least notice the outside reactions. Ask yourself who cares about the clippy resurrection referenced in the article?

How does one day of willful misinformation work in a medium used as indefinitely persistent storage of human knowledge?

If your whole world is asm and C, then I take it you don't care much about type systems. Bless your heart, you lonely programmer of ephemeral software, may you be employed gainfully fixing your own bugs for decades. The saltiness if mostly for entertainment, please don't take too much offense. For everyone else working at a level of complexity where mistakes are inevitable and costly, types are an essential bicycle for the faulty minds of programmers.

The article is not arguing that we shouldn't express or model the absence of a value. It is arguing that all types having to support "no-value" case leads to error prone code that has historically cost immeasurable amount of money and much credibility and respect. If everything can be null then it takes too much effort to null check every reference, so developers routinely forget or think they know better. Instead it argues that we should model the idea a possible empty values as a separate composable type. Then you can write a large percentage of your code with a guarantee that objects/type/values are never going to be nil, while still handling that possibility in the smaller error checking parts of your code base.

One interesting anecdote is that our team, working in Swift, had to integrate a crash reporting tool and verify that it works. The challenge was that we haven't seen a runtime crash in several months in production.

> A "nullpo crash" is one of the more trivial things to debug

If it happens in your debugging environment in front of your eyes then maybe. Some of us work on software that is used by millions over decades and would never get to see any reports from a majority of crashes.

The one killer feature I'm hoping some GUI client implements is the ability to seamlessly search and filter branches by just typing the way most IDE's implement search for symbols or files. I work on large active projects that use git flow and inevitably there are dozens of branches. Sourcetree in particular is slow and painful in this scenario and I would love to replace it.

Sublime Merge is looking very responsive and cleanly organized. Great job!

Tantrum-Driven Development, also know as spitting in the wind.

And yet despite your criticism they are selling more devices than during Steve Jobs by a large margin. My iphoneX is by far the most usable and comfortable form factor of a smart phone I’ve used in the past decade. I’m just glad Apple has far better ways to decide on their device strategy than internet hot takes to so reliably and predictably miss the boat.

It's important to remember that you can always make it look like you are ahead of Moore's Law curve if you are willing to spend more for silicon and the energy to power it.

This appears to be a GPU design for those applications where extreme (by mobile and desktop standards) power consumption and cost can be justified. Correspondingly NVIDIA has been trying to move into the data center for deep learning and rendering. They pushed out a lot of good research on how to do the computationally expensive parts of rendering on the server, and leave the client to do the last interactive part locally.

The market allows for this silicon giant because of the current Deep Learning and VR hype. If there were to be another AI and VR winter I'd expect NVIDIA's marketing to re-focus on power efficiency and architecture tweaks once again.

> Swift really does not support quickly iterating on a design.

I find the opposite to be the case. You assume that compile errors are a net negative for speed of development and expressivity. Instead I find that the compiler reminds me upfront of all the places I would need to update anyway in due time. In a dynamic language those inconsistencies would be found hours/days later and usually after lengthy debugging. Instead I find myself making large sweeping changes in the design very frequently, because I trust the compiler to warn of any logical inconsistencies.

You have to admit at that this point it boils down to subjective preference. You sound averse to the swift style of doing the right thing up front, and using the compiler to help you stay consistent. I personally tired of the hidden and unacknowledged costs of unsafe language, and compilers that allow your design to degenerate into an unmaintainable ball of mud over time. I'm ok with swift being an acquired taste and a technical advantage of folks who get it.

The critical difference is that in swift your have to override safe behavior by using special syntax. This means you can search for it to fix it, you can have compiler/linters enforce certain rules, you can catch it easily in code reviews. No professional team I've worked on would allow forced unwrapped code except in special well documented cases.

The default code you write in swift is safe. You spend less time worrying about its correctness, which means you can focus on solving higher level problem and less time debugging.

When people call swift pedantic, for example, and I take time to ask for the specifics, I mostly get "not familiar to me", or "I'm used to shooting myself in the foot and unwilling to consider alternatives". So my patience has run out.

Lattner takes "working" software to mean something that can be shipped to production and used in the real world, as opposed to the classic "works on my machine" definition that second rate developers hide behind. It takes a certain maturity and experience shipping to recognize the long term benefit that approach. As the head of Apple developer tools (at the time), his job is not to cater to the hobbyist working on his fun software project, but improve quality of software on his company's platform.

When people criticize C as a language they are usually referring to the fact that it easily and frequently allows for many classes of bugs that riddle C code. For decades, as an industry we've been apologizing and fixing critical exploits and bugs (ex HeartBleed), that can be traced to the fact that C allows for mistakes. If a bug is allowed, someone will perpetrate it sooner or later. Sacrificing correctness and safety for the speed and complicity of C is not a valid tradeoff for the industry in my opinion.

A major feature of Swift is that it forces you to deal with error conditions and missing values. In practice you do the right thing once and early in your code, and you can write the majority of your code with guarantees that prevent major classes of bugs. Swift is not perfect, still changing, and many complain about being forced to write safe code, but it is absolutely the right move of Apple to make for their platform.

You make my point for me when you say that you already suspect the result and this proves it. Let’s not bring truth into this when it clearly using statistics to advocate your point of view.

This was interesting because all other evidence from large scale longitudinal studies points to the opposite conclusion. But there is the bold tag "Accurately Reported" on straighttalkonevidence.org after all

Reading through it appears authors have, maybe deliberately, misrepreented causality. The pre-k program was discontinued and kids were sent to poorly performing public school, they noticed a decline in academic achievement and blamed this on the pre-k program. Is it me or is this a good case of using statistics to tell whatever story fits your agenda?

Digging into further, looks like the website if funded by Laura and John Arnold Foundation [1]. Another billionaire (hedge fund manager) has found a way exploit the economy to siphon obscene amounts of money and as a result is the only one qualified to fix all of society.

[1] https://en.wikipedia.org/wiki/Laura_and_John_Arnold_Foundati...

yes, this does join today's festival of obscure languages. But why is this one note worthy you might ask yourself?

1. it appeared almost out of nowhere with no warning from its mysterious author _why the lucky stiff who then later disappeared off the face of the internet.

2. despite its sophistication (JIT, custom vm, full mixing based language) the source is very readable and accessible to anyone interested in non-trivial compiler construction.

3. it has a certain idealism not sullied by being a large project trying to become famous.

Seems to me you are into promoting conspiracy theories if they confirm your own world view, instead of withholding judgement until more information is available.

The article omitted the critical detail about which private API was used. I have received one of those letters before and they should contain those details. The fact that the article omitted that information makes it sound like they want to start a controversy instead of admitting a library developer probably made an easily remedied mistake. They were hoping for low-information-high-opinion internet audience to drive traffic.

I don't want to worry you, but on a mobile device with a screen the GPU is always spinning. That is where the pixels come from after all.

I get your point that there are energy efficiency tradeoffs to consider. However for massively data parallel tasks like image operations, 3d graphics, machine learning, vision etc, I haven't seen SIMD implementation come close to GPU compute in terms of efficiency. Perhaps short lived text pressing and file compression where data access is more random could benefit from SIMD.

I don’t think it’s conflating anything but trying to explain to you the difference between the two concepts. It’s saying that Null for all references types by default is a bad idea, and representing “missing” in a tagged union (sum type, whatever) leads to better code. Your worry about inconsistent type use for the same concept doesn’t really apply when combined with syntactic sugar for optionals.

This is also how Swift implements it support for optional. So far I don’t see a difference in expressive power between the two languages. A user never has to actually type out Optional, when adding ? is enough. Swift also has optional chaining and nil coalescing operators as syntactic sugar. Under the hood there is still an Optional type for the type checker to work with.

I think this is becoming a trend in modern language design. However as this comments section demonstrates it’s hard to understand its benefits or why it’s an important improvement, if your only experience is from C/C++/C#/Java etc

I think you misunderstood something about the languages mentioned like Swift or Haskell. They do have a way to represent the concept of "nothing", or "missing" using an enumeration (called Optional in Swift, Maybe in Haskell).

What they don't have is the global concept of Null that sits at the root of the type hierarchy. This means every type in a language like C# or Javascript has to have Null as one of its members. If you want to define some operators/functions on the members of the type, have have to always consider Null as a member. Like the author listed: How do you compare Null, how do you negate Null? Those questions shouldn't even be asked because Null is not negatable or comparable. Maybe the problem is that Null shouldn't have been admitted as member of a type that you consider comparable or negatable.

So in Swift/Haskell, when you define a type you don't consider "nothing" as one of its members.

The mental model in Null-using-languages is that a Type is a sort of blueprint that can be stamped out to make instances of that type. From that point of view its natural to consider you may be missing an instance.

In language like Swift or Haskell the concept of a Type is closer to a set in math; in this case the set of all possible values of that type. This is why I said above that Null has to be considered as a member of a type. I’m using math language to re-interpret the type-as-blueprint world view, to show why it leads to illogical results.

Seriously, Swift demoting of the concept of “nothing” to just another enum is alone worth the price of admission. This has cascading consequences that lead to safer code. You also get simpler code as you strive to resolve the uncertainty of a missing value as early as possible in your code. Swift is the most impressive language I've seen in a while, but think its origins at Apple have overshadowed the its incredible technical value.

One of the co-founders of shader toy is a legend in the field and has the most relevant resources for procedural generation and distance field ray-marching: http://iquilezles.org/www/index.htm

While the article has a some good points about not over-engineering unless you need it, I’m really put off by the pissed off and dismissive attitude. Ex “here’s another wannabe who never bothered to learn”, “This pisses me off“, “I’ve spent 15 years” etc.

This shows the author doesn’t really understand why you might decide to use an architecture that departs from the apple MVC orthodoxy, and despite “years of experience” never worked on a large, multi platform project, that tried to avoid 1st party tool lock-in, or actually implemented in-depth testing beyond the anemic xcode support.

The truth is that Apple mostly cares about providing a good UI SDK with general platform services, but is agnostic about how any one app is architected. It makes sense they will preach the simplest and most general pattern: MVC.

Or how about not pissing on other people’s valid ideas because you are offended and want to show off your own contrarian cleverness?

Or more realistically and less dramatically, some these big features took a lot of effort and engineering investment before they were ready for production.

Apple tends to re-think the current technology and implements their ideal solution. This takes longer but avoids the duck tape approach I've seen in various iterations of Visual Studio. As a concrete example the refactoring tools in Xcode9 work for both C++ (for the first time!), Objective-C and Swift using the same framework.

Best of all the API to write your own refactoring tools has been carefully designed, and there have been some high quality external contributions already to the refactoring tools.

This is something that can be largely fixed by the software, but it requires 3rd part developer coordination, that honestly only Apple can pull off. In iOS11 there is a concept of a safe area that UI should respect. With constraint based layout you can have a single layout that moved critical UI components outside of the notch area if its present.

The problem is that the AR game was most likely built with Unity, which has its own 4-5 different UI systems, and my guess none of them are aware of a safe area.

The problem is fixable, but why did Apple allow demo that was not polished enough to work well with their flagship phone?

This is an admirable effort and thanks for doing it.

Have you experienced problems related to the lack of active support from AMD or Intel for OpenCL drivers? Thats been my experience with OpenCL several years ago. On a related note drivers for OpenGL on Linux and Windows from AMD and Intel have been a huge problem for developer for years. Somehow only NVidia cares and invests enough in non-windows driver support. This may be changing with Vulkan however and more focus on GPU compute.

AMD and OpenCL have fallen desperately behind NVidia and CUDA in terms of industry adoption. CIDA is so far the industry standard for machine learning on GPUs. For example tensor flow had a GPU backend using CUDA. Last time I looked OpenCL support was in alpha stages.

This software platform dominance fueled a lot of hype around NVidia, but I'm not sure how much it contributed to revenue. Research and specialized data centers may still be a small percentage of sales compared to mass market. But Intel and AMD both understand that if they don't catch up they will never recover. They are gearing up for a future where every customer device needs some efficient machine learning inference hardware. Then data centers will need to purchase mind boggling amounts of throughput computing for training from streams of incoming data. I'm sure each company is planning hardware derived from current GPUs but more power efficient for the type of number crunching ML algorithms.

If by huge you mean that in its current state it will be a nice novelty experience for some interested and tech savvy people, then I agree completely. On one hand cardboard VR is a huge success with likely millions of people who have tried it or heard about it. On the other hand it hasn't registered in most people's lives as more than a novelty, compared to the habit forming technology and life changing experience of mobile phones.

At the same time I have to acknowledge that ARKit is just the initial developer interface to future hardware products in the Apple ecosystem. When they announce Apple AR sunglasses with the same portability and form factor as your Ray Bans, then we can start talking about huge.

The significance of this achievement is that microcode and its update mechanism has been historically undocumented and hidden from public scrutiny by processor vendors (AMD and Intel in this case), while at the same time the lowest level of abstraction in a computing platform and thus extremely powerful. However it is not unreasonable to consider that well funded state actors have developed microcode exploit technology that would make their control over a system undetectable and impossible to remove. The recent leaks have shown exploits that target hard drive firmware for example.