[HN Gopher] Porting Graphing Calculator from C++ to Swift
___________________________________________________________________
Porting Graphing Calculator from C++ to Swift
Author : mooreds
Score : 57 points
Date : 2022-07-01 12:27 UTC (1 days ago)
(HTM) web link (www.swift.org)
(TXT) w3m dump (www.swift.org)
| viktorcode wrote:
| > When I ported individual sections of functionality, the Swift
| source typically measured 30% the size of the corresponding C++
| code.
|
| This is impressive.
| GeorgeTirebiter wrote:
| Well... there are other metrics besides code size in some
| sections, such as the total code size for all sections; the
| speed of compilation/linking; and ultimately, the user
| experience --- is it as fast or faster than C++ ?
|
| When people make 'size' comparisons, I sometimes wonder if
| they'd best be done using lzip or something on the two code
| bases -- because the compressors are trying to remove
| redundancy in coding, and if one uses lots of whitespace in C++
| to enhance readability, this should not punish C++ in the size
| department.
|
| You generally want some 'system' ('language' seems too
| restrictive) to enable one to capture the algorithms rapidly
| and accurately in some notation (again, 'language' seems not
| quite the right word), and to as quickly as possible convert
| said notation into working binary (compiler, interpreter, JIT,
| etc all fair game) that satisfies the user need.
|
| I claim (wrongly?) that these days, we generally only need a
| decent 'glue' notation that allows us to mash together existing
| libraries/classes/etc to produce the final product. Some of
| this glue would be sort-of templates, lispish macros, some
| would just be e.g. an FFT routine. But only by burying
| complexity in well-tested, lower-level chunks will we be able
| to build big systems that don't collapse.
|
| Sorry, enough soapbox. I guess I'm suggesting that it's
| interesting to compare Swift to C++. It sort of begs the
| question: what is 'the best' way to get some functionality
| (e.g. this cool calc app) written?
| gumby wrote:
| Curious what boilerplate is common in C++ that isn't needed in
| Swift. I find the repetitive boilerplate level of C++ pretty
| minimal, especially compared to languages like Java.
|
| Template specification used to need a lot of decoration but with
| auto most of that is gone.
| jcelerier wrote:
| if the code started in the 80s, I doubt there's many autos or
| templates
| unnouinceput wrote:
| That makes 2 of us. When I've read "So much of the repetitive
| boilerplate code that was necessary for C++ melted away in
| Swift" my eyes rolled over. For me Swift repetitive boilerplate
| is on par with the one in C++. Clearly the author never touched
| Ada nor Python, if that's the number one reason he wanted
| another language to eliminate the repetitive boilerplate.
|
| I suspect he just wanted to learn Swift and that's a good
| reason enough to make this rewrite, as he admits in the final
| paragraphs of the article: "I've enjoyed learning Swift and am
| much happier with the state of the code now"
| heavyset_go wrote:
| Old code is going to have long implementations of things we
| take for granted now.
| snovv_crash wrote:
| I wonder how a rewrite of the core algorithms in modern C++ and a
| Swift wrapper + UI would have compared. This also would have
| allowed easy porting of the core to other platforms.
| KerrAvon wrote:
| Very difficult to do that in practice, because there's
| currently no way to bridge C++ directly to Swift. You could
| bridge it via C, but any reasonable implementation would have
| to severely limit the amount of direct Swift interaction with
| the core code, or you'd be spending infinite time maintaining
| the bridge.
| danappelxx wrote:
| There's partial support which is under active development.
|
| https://github.com/apple/swift/tree/main/docs/CppInteroperab.
| ..
|
| https://forums.swift.org/t/swift-and-c-interoperability-
| work...
| omar0226 wrote:
| Actually C++ could be bridged thru Objective-C++ which at the
| same time can be bridged to Swift. A little bit manual, but
| possible
| avitzur wrote:
| Yes, precisely. I looked into bridging to C++ initially, but
| it was impractical.
| krallja wrote:
| Graphing Calculator was one of the delightfully "impossible"
| things I discovered in the hard disk of our brand new iMac back
| in 1998. I had just started using a TI-83+ at school, so seeing a
| 3D full-color animatable graphing calculator with a beautiful
| equation editor slotted directly into my brain as "this shouldn't
| be possible! yet here it is!!" I have never found a real use for
| it, but always wish I could. I bought the iOS version when I
| found out about it to pay back the authors for my teen-aged
| delight.
|
| The origin story is cool as heck, too. As discussed many many
| times on HN: http://pacifict.com/Story/
| codetrotter wrote:
| > Since the '80s, I've intended to eventually open source my
| code. As I considered doing that with the C++ code base, I
| realized that would not be a useful contribution due to the
| decades of accumulated technical debt making the C++ code
| unmaintainable. I am confident now that the new code can be made
| into useful stand-alone Swift Packages for mathematical
| typesetting, editing, numeric and symbolic computation, and
| graphing.
|
| I hope he decides to also open source the C++ version. It would
| be interesting to be able to see both versions, and to compare
| them.
|
| Perhaps one of the greatest benefits of open sourcing both
| versions, that I can see, is that others could then look at the
| two versions of Ron's code for inspiration on how to go about
| porting their own legacy applications from C++ to Swift.
|
| Aside from that, it also provides historical context that future
| programmers and future programming language creators could learn
| from. Both in terms of good things and any of the lesser good
| sides.
| tambourine_man wrote:
| > When SwiftUI works it is a nigh-magical delight, but when it
| behaves unexpectedly or when behavior outside the prescribed path
| is desired, it can be difficult to understand and work around its
| limitations.
|
| The author is being kind. Once outside the prescribed path,
| you're in deep trouble. And that's the thing with declarative
| code. There must be a great escape hatch. The framework can't
| foresee all possible use cases.
___________________________________________________________________
(page generated 2022-07-02 23:00 UTC)