Had the same thought. I don’t show up on this leaderboard, but I’m #42 on the “more complete” leaderboard. I’m #8 when sorting by max in a single comment—which makes even me think I may have overdone it. Finally—HN top 50 and top 10 in something I love!
Yeah. I was there and this demo was a jolt. More so was the phrasing we were witnessing the end of our punchcard era. I don’t know if it’s the history nerd in me or what, but that thought has been living in my head ever since. Looking forward to playing with Phoenix.new—and keeping an eye out for looms to smash. Kudos, Chris.
Is this another in the string of 737 MAX issues? Or would other aircraft have experienced the same event under the same conditions?
Edit: Aplogies for asking about content that was obvious, but behind a paywall. Thanks to the archive link shared, it sounds like it was (inexperienced) human error.
Seriously, after seeing several Boeing engineers saying they wouldn't fly on a Boeing aircraft, and seeing how their management has handled their crises, I'm not flying Boeing. That company needs a major restructure and "come to Jesus" moment before I'll ever trust them again. So far, that isn't even on the horizon.
I'm all for backing the regulatory pressure that has allowed this constant improvement (consider that flights per year have increased while the trendlines in those graphs have decreased) but I'm going to need to see that accident number reach about 100x what it is right now before I care about it enough to personally switch flights. The commercial aerospace side of Boeing has over 10,000 engineers, several of them have probably said we didn't land on the moon too. The way their management has handled decline in their record is at least a fair point just not nearly bad enough yet for me to really care as often as articles about it get posted here or enough to switch flights yet.
Was just playing with some other NTSB statistics and noticed the graph range doesn't shrink to fit, here's the continued risk decline: https://i.imgur.com/gKomsVa.png
I've had similar thoughts, but how does that work for you in practice?
If you book a flight that says it's an airbus plane and then you show up and the airline had to sub in a boeing plane, do you just cancel your trip?
If you don't have the expensive tickets that allow same-day rebooking, I can't imagine any airline would humor an attempt to get a refund or to have them waive a rebooking fee.
Similarly if you're traveling for business and your company has paid for the ticket, some companies let you book your own travel and then get it reimbursed, but presumably you're needed at the destination so if the day of travel comes and the plane is an airbus and you "nope" out of there, you're going to have to hope that your work is okay with your explanation.
All of this is because "if it's boeing, I ain't going" can seem alarmist or reactionary since the FAA has so far declined to drop the hammer on them.
In practice, you can only (reasonably) minimize your odds of flying on Boeing. That means "no" to Southwest Airlines. It means "yes" to Frontier Airlines, whose entire fleet consists only of Airbus planes. Thank goodness where I'm located and often need to go to are well-served by Frontier Airlines!
BUT - many airlines operate a mixed fleet. Book on an Airbus. They rarely change planes, but if they do, say your prayers! Unless you have tickets easily allowing you to re-book, which most of us aren't purchasing.
It’s often possible to take a suboptimal route to avoid a Boeing. For example, if I fly Austin to San Francisco, it could well be a MAX, but if I go to SJC via LAX instead it is almost guaranteed not to be.
How much more dangerous is it to take two flights (and two different planes with varying ages and maintenance records, plus two landings and take offs), than to take one Boeing?
I am ok with older Boeing airplanes. While I am skeptical of the company's current safety program, and attention to detail, I think the older planes - with many C checks done - are safe to fly. Something happened with the 737 Max, clearly a management decision, that increased risk or perhaps inattention to detail.
My opinion is that the company was run by bean counters instead of engineers, and the stock market convinced the business people that changing the way they made airplanes, made sense.
As I mentioned, older Boeing's. The Dreamliner been flying since 2011, that's an older Boeing for me, compared to the 737 Max which has only been flying commercially since 2016.
My bad. The article makes that clear behind a paywall. I could only read the first two paragraphs before I asked the question. Luckily the archive link shared had the full text and I was able to read the full incident description. Thank you!
That was determined after an independent investigation by both the FAA and NTSB. This incident hasn't been investigated by anyone but Southwest Airlines.
> The captain opted to put the “newer” first officer in command on the short flight to Lihue despite the forecasts, according to the memo.
The less-experienced first officer “inadvertently” pushed forward on the control column, then cut the speed causing the airplane to descend. Soon after, a warning system sounded alarms the jet was getting too close to the surface and the captain ordered the first officer to increase thrust. The plane then “climbed aggressively” at 8,500 feet per minute, the memo said.
My apologies for asking the question when I could only read the first two paragraphs due to paywall. The archive link shared cleared up my concern, and makes it clear that it was human error during a weather-related re-approach. Thanks, though!
> We present a gradual type system for Elixir, based on the framework of semantic subtyping ... [which] provides a type system centered on the use of set-theoretic types (unions, intersections, negations) that satisfy the commutativity and distributivity properties of the corresponding set-theoretic operations. The system is a polymorphic type system with local type inference, that is, functions are explicitly annotated with types that may contain type variables, but their applications do not require explicit instantiations: the system deduces the right instantiations of every type variable. It also features precise typing of pattern matching combined with type narrowing: the types of the capture variables of the pattern and of some variables of the matched expression are refined in the branches to take into account the results of pattern matching.
sounds like what typescript does, I'm not clear if the Elixir approach is different from "structural typing" (as TS calls it) or if they're rediscovering the same thing. Either way, I'm happy it's the way they're going
While both Elixir and TypeScript are structural, they are different type systems. A set-theoretic type system is not one that has unions, intersections, negations, but rather one where the foundation of the type system is represented on top of unions, intersections, and negations. Even relations such as subtyping, compatibility, etc. are expressed as set-theoretic. We also have a very different approach to dynamic/gradual typing (which is sound): https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradua...
I recommend reading Giuseppe Castagna's work for those who want to dig deeper: https://www.irif.fr/~gc/
I did read your article, and it’s actually how I came out with the idea that Elixir had come up with the same idea as TS haha!
I’m sure I’m missing something as I have no doubt you’re by far more knowledgeable than I am, but TS also represents types as sets (semantically, dunno about internal implementation), structural typing seems to inherently map to set theory
For example, about bounded polymorphism the article says “Of course, we can provide syntax sugar for those constraints”: seems like this sugar could be ‘a extends number’ to me, like typescript does. I don’t see how TS does _not_ map to set operations
Sorry for the late reply but I wanted to double check before following up. And I am glad I did because I was told my first response was inaccurate. :)
It is fair to call both TypeScript and Elixir as set-theoretic type system. The big difference is that Elixir's implements semantic subtyping. Here is the paper you can use to dig deeper. I hope it helps: https://www.irif.fr/~gc/papers/lics02.pdf
Elixir is going to be fundamentally different from TS though. The base set of datatypes is quite well defined, and function activities are rather composable unlike JS where "basically anything can happen".
For more information about what that means, see this playground [0] from the TypeScript docs. PL people often make a big deal about TypeScript's lack of soundness as though it was some kind of mistake, but it was very much an intentional choice given the trade-offs they were making at the time.
If Elixir can pull off soundness without compromising expressivity that will be a huge feat, and I'm excited to see it!
Yea I never bought this assertion from the TS team, saying “given the trade-offs at the time” is the same as saying “we’re already backed into a corner by previous decisions” - the decision(s) may have been intentional at each step but the design itself probably was not. Given the choice of sound or unsound, considering that the purpose of a type system is to give certain guarantees, a type system design must always choose soundness to be considered reasonable.
That being said, I don’t think it’s possible to “pull off soundness without compromising expressivity” because the expressivity in this context is self-referential types which equate to non-terminating unification logic (and thus, unsoundness). Still, I’m excited to see what they do with this type system! Reminds me a bit of Shen’s type system.
Is the TypeScript team correct in explaining that soundness would exclude functions accepting subtypes as laid out there? If so, it seems like any type system that was meant to be able to type common JavaScript idioms would have to be unsound.
Yes and no - you can't have bi-variant argument types as shown here and be sound, but that does not mean you can't type those idioms. You just need the type system to be able to express a dependency between the name of the event handler and the type of the associated function. It is not exactly straightforward (this is a complex type system feature) though, I don't blame the TS devs for going for an escape hatch there.
(Edit: to be clear, allowing to refine function types in the way they do is part of the solution, the unsound part is that it is not checked afaik)
Sub-types can be represented with algebraic types so I’m not sure that’s necessarily true, for example an abstract class with subclasses can be represented as a sum type
I always find myself sitting down to read Out of the Tar Pit[0] at least a couple times per year. It has been—and continues to be—one of the most seminal texts in my career. I still remember the first time I read the following passage on complexity, and how it just turned on all the mental light bulbs:
>> Essential Complexity is inherent in, and the essence of, the problem (as seen by the users).
>> Accidental Complexity is all the rest — complexity with which the development team would not have to deal in the ideal world (e.g. complexity arising from performance issues and from suboptimal language and infrastructure).
>> Note that the definition of essential is deliberately more strict than common usage. Specifically when we use the term essential we will mean strictly essential to the users’ problem (as opposed to — perhaps — essential to some specific, implemented, system, or even — essential to software in general).
The best skill I've learned, and continued to practice and improve, is the ability to strip how we talk about problems we want to solve with software down to what's truly essential to the problem. Making a habit of doing so helps clarify the contours of the problem itself, and improves discussions around solving because the boundaries of what's truly essential become clear—and then everyone involved knows that every choice we make from that point is additional, accidental complexity we are adding to the problem ourselves.
Far too often I have seen even greenfield software quickly ratchet up the overall complexity because the people making choices don't take the time to really isolate the problem from the software—but instead frame the problem within the context of languages, frameworks, architecture, infrastructure, and so on, and then just start slinging code at the problem.
If you haven't yet read Into the Tar Pit, it truly changed the way I look at and think about software and problem complexity. You may find value in it, as well.
This rings so true. I noticed a consistent level-up in my abilities once I started to seek the essence of the problem. I ask myself: “I start with this information. The desired output is X. What is the essence of the data transformation that takes me from the input to X?”
When I boil down the task to its nature as a data transformation, the solution flows from my understanding of the problem, and I’ve found that my choice of tools flows transitively from there pretty easily. The problem is “isolated” from the software as you said which makes it so much easier to reason about things.
I sadly have not gotten much traction when I try and advocate for this mindset in our industry.
As an aside: It reminds me of a funny point from secondary education. Did you take AP tests in high school? If you did, you might remember as I do a consistent refrain that teachers used to beat into students preparing for the tests: “Answer the question” Over and over we heard this ad nauseam until it became second nature, whether for AP English or AP Physics - and it was good advice! Because the number one mistake students make on those exams is not actually answering the question asked, which even when couched in the most wonderful prose, results in a failing mark.
I think software engineering is often pretty similar. Even the best, most sophisticated tools will not produce a working solution if you don’t understand the problem.
> I sadly have not gotten much traction when I try and advocate for this mindset in our industry.
Yeah, I know what you mean. It's become a bit of a primary signal for how I evaluate a company's engineering culture. I've been lucky to work with some fantastic people who really get it, and I've also struggled and suffered through working with those who do not.
> Even the best, most sophisticated tools will not produce a working solution if you don’t understand the problem.
I'm sure we've all seen some awful monstrosities—or created them ourselves—that we could call a technically working solution to a given problem ... but it doesn't mean anyone wants to work on it. Keeping complexity at bay requires finding the simplest solutions that isolate essential and accidental complexity. Simplicity is hard, and it requires doing this well, constantly. It is [ahem] essential to spend the time required to isolate the problem and articulate it clearly. If you can't isolate and articulate the problem without referencing your tech stack and tooling, or your explanation gets all muddy and convoluted, you haven't actually identified the essential complexity of a problem. You're still stuck in accidental complexity territory. And that's a horrible place to be designing and architecting your software from.
It's also critical to note that over the lifetime of any piece of software, as new things come up—new bugs, new features, etc—you have to keep re-engaging the same process, and evaluating/reflecting on how new things fit (or don't!) within your existing architecture/design. Failing to do so is what drives toward infinite complexity and endless "tech debt" in poorly designed software. Well-designed software isolates and encapsulates all the accidental complexity into its own space(s), leaving open avenues to adjust and expand the software. Well-designed interfaces allow you to refactor, reshape, and grow the internals of a problem domain in isolation from its callers. This requires discipline from a software team—and its leadership—to take the time necessary to adjust and refactor as priors change. Such work should always be moving the needle toward greater team velocity and individual productivity.
> Did you take AP tests in high school?
Yep, sure did! I definitely remember what you're describing here.
> If you can't isolate and articulate the problem without referencing your tech stack and tooling, or your explanation gets all muddy and convoluted, you haven't actually identified the essential complexity of a problem
100%. I don't have much to add but I've really enjoyed our discussion.
