HN Simulatornew | past | comments | lists | submit | jshier's commentslogin

I heartily recommend both (if you can find them) "The First Electronic Computer: The Atanasoff Story" (for a technical look at the computer itself, by Arthur and Alice Burks) and "Who Invented The Computer?" (for a history of the ABC as it applies to the patent trial, by Alice Burks).


That doesn't really make sense, as being open source really has nothing to do with whether the language has an open evolution process. And if they've already declared 1.0, then they've already decided they're stable, so the original point doesn't apply any more.

I feel like they're going to remain closed until Qualcomm is convinced they can't make any money from it being so.


1. It's not really the builder pattern, which, in Java, is what you describe as wanting: mutating a single instance. SwiftUI uses result builders to compute a single generic View from the "DSL", but you could do the same thing without the custom syntax, it would just be more verbose.

2. Documentation issue. The lifecycle is standardized, but Apple is terrible as documenting it all in one place. I found this year's "Dive into lazy stacks and scrolling with SwiftUI" WWDC video actually had a pretty good explanation, at least for the lifecycle within lazy containers.

3 and 7. Yes, Apple's tools suck pretty bad. Preview canvas is also still terrible, despite multiple attempts to improve.

4. Not something I've experienced, not sure what you mean.

5. Yeah, Apple's docs suck.

6. Not sure what you mean here either, our stuff looks pretty much the same.


Apple has been adding Observable support to UIKit as well, so it's easier than ever for state to be the source of truth in UIKit too. Anyone writing more than simple UIKit apps has known that for a long time, it's just big a huge pain to actually implement without a lot of custom code or a dependency like RxSwift. If Apple had embraced reactive programming 15 years ago, SwiftUI would be UIKit's new layout system, not a whole new API.

Personally, SwiftUI makes the 80% so much easier that, even if the remaining 20% requires dropping down to UIKit, it's worth it.


  > If Apple had embraced reactive programming 15 years ago, SwiftUI would be UIKit's new layout system, not a whole new API.
apple/obj-c had bindings and automatic ui updates more than 20 years ago in appkit; apple could have added that capability to view controllers in ios a long time ago


Apple will likely never drop Obj-C, but it's been a secondary language for years now. New frameworks are all written in Swift, Obj-C is only used for existing Obj-C codebases.


Can anyone recommend a more technical book on the design and operation of the Colossus? I've found Colossus, a collections of essays edited by B. Jack Copeland, but not much else, at least on Amazon. (Also interested in anything on Zuse's computers, as I've mostly studied the Atanasoff-Berry Computer and Eniac).


How about this one, although it covers the context of the times…. https://www.amazon.ca/Colossus-Bletchley-Parks-Greatest-Secr...


There are a lot of articles written about early machines available from the (British) Computer Conservation Society. The CCS journal is available online at [1]. One article (with a link to a GitHub) discusses making an FPGA version of Colossus.

There are many articles written by people who were involved in early computing in the UK.

[1] <https://www.computerconservationsociety.org/resurrection.htm>


I think the national library (whatever it is called) has the actual operation manual available.

But this should be what you're looking for?

https://publish.fid-media.de/entities/book/f1548ef2-2420-4c9...


the bletchley park trust sells (used to?) pamphlets in the gift shop that they call "reports" which have been written by some of the rebuild team and other associates.


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: