Threads for harlanhaskins

  1. 4

    Working on the LLVM backend for the dependently-typed functional language compiler I’m working on, silt.

    It’s super fun, and incredibly challenging as someone who’s unfamiliar with dependent types in general.

    1. 17

      I took a job at a hospital a number of years ago building applications for internal clinical use. I get to talk to physicians, see how they’re using my applications, and how they improve outcomes for the patients. Knowing that the apps I work on directly affect patient care makes the work feel a lot more meaningful than any other job I’ve done previously.

      1. 5

        Been thinking about OP’s question and people who work close to the medical field for some time. Glad to know it’s fulfilling.

        1. 7

          I just left a small startup in the Rochester, NY area called Bryx (https://bryx.com), and we’ve gotten some incredible feedback from people saying how much easier their lives are that they don’t have to sit, blocked, waiting for pagers and faxes to be able to get routed to fires and EMS calls.

          It’s incredibly fulfilling.

          1. 3

            Awesome. The feedbacks help a ton.

            1. 3

              That sounds amazing. Would you mind going into a bit more detail about Bryx? If you’re allowed to say, what sort of technology/languages/stack does it use?

              1. 1

                Just saw this reply. The API is entirely implemented in Kotlin, the backend receiving jobs from departments and putting them into our (for better or worse) MongoDB instance is all Python. The Android app is a mix of Kotlin and Java, and the iOS app is entirely Swift. We have a desktop Electron app and a management site that are written in TypeScript. We’re really big fans of the new developments in programming languages and we’re huge fans of type safety. Specifically, we like type safety because our old PHP API caused so, so many bugs in production from accidentally misspelling variables and a lack of enforced structure.

                1. 2

                  Thank you, that’s really interesting.

          2. 3

            Please could you describe the applications a bit more? In particular, what sort of languages/software stack/environment do you use? I have occasionally thought about doing something similar - mostly when I get depressed about working for morally dubious people - but my skills and experience never seem to be a good fit.

            1. 2

              I actually did an interview about my work recently here.

              1. 2

                Cool, thank you.

          1. 5

            Would be nice to see a before and after…

              1. 2

                Interestingly, Preset omits all the Normalize fixes for MS Edge, which seems surprising to me.

                1. 1

                  Ah, I thought the parent meant a before/after comparison of old resets versus this new rest. Not a before/after comparison of the reset applied to a page.

                2. 2

                  Sure! Here’s a before/after: https://imgur.com/a/QjZl2

                  And they’re online at:

                1. 1

                  This was an excellent overview! I’d love if the author could go into details comparing the code output by Swift vs. C++.

                  1. 1

                    Thanks! I’ll probably do Swift some day, but right now I haven’t looked at Swift since its original release.

                  1. 4

                    Damned if you do, damned if you don’t. Swift has been making breaking changes that improve the language based on developers' feedback; they’ve just come to a point that they’re comfortable claiming source stability. Still, it’s a massive headache for developers, and they’re right to complain.

                    ¯\_(ツ)_/¯

                    1. 4

                      If you fix the problem, the headache of people changing their code to accommodate lasts a few weeks for your current users. If you leave the problem there, that headache is for every user, current and future, forever. Fix the problems. People are going to complain either way, so might as well leave them complaining about a good language, right? :)

                    1. 3

                      Joe Groff, the owner of the 2011 repository, now works for Apple on Swift.

                      1. 3

                        Ahhhhhh. That makes a lot of sense if wondering why his development would halt or slow. I’d definitely choose to work on Swift over Clay2011 if I had a choice given money and momentum behind Swift. More impact, too. Explains him but not Clay labs. I might just email them.

                      1. 18

                        You see, when a Java programmer gets used to TDD, they start asking themselves a very important question: “Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything?”

                        That was not my experience. Rather, I often thought: “why am I wasting my time writing tests for this, which could be avoided if the language had better type constraints?”

                        And that’s exactly what happened in second half of the first decade of the current millennium. Tons of Java programmers jumped ship and became dedicated dynamic typers, and TDDers.

                        This seems unsubstantiated, IMO. Bob implies, IMO, that all these Java developers “left” Java for dynamic languages, in order to become TDD developers which seems to me just a teensy bit absurd.

                        How will this all end?

                        My own prediction is that TDD is the deciding factor.

                        IMNSHO that is Uncle Bob’s prediction because Uncle Bob’s income relies on harping on about TDD like a broken record. Often nonsensically—like in this post.

                        You don’t need static type checking if you have 100% unit test coverage.

                        This is just plain false. Making sure your function has 100% unit test coverage does nothing to help you if someone calls your function with unexpectedly typed data. Say your function expects two integers, but are called with a dictionary and a list. Or another function. Sure, you can add type checks to your function, and more unit tests to verify that those type checks catch the unexpected types, but that’s a lot of boiler plate to add everywhere.

                        “Oh, but my function is not useful enough to be included in a library used by others, and I do have 100% coverage of my app, so I assert that it is not called with unexpected types.” Right. Does your app get data from anywhere? Input from a form? Environment variables that people can set before running your app? Are you sure that the input to the function does not come from inadequately sanitised data? If you were using Perl you could activate taint mode, but it looks like the equivalent in Python was rejected in 2009. I don’t know if Ruby has anything equivalent. And even if you are using Perl, there’s a lot of ways your function can fail that taint mode won’t help you catch.

                        1. 1

                          Ruby does have taint mode; I’ve never seen anyone ever use it.

                        1. 2

                          The Linux support is something interesting in this release, something I’ll probably play with. It’d also be nice (albeit it probably won’t happen) for Swift to support other UNIX-likes, such as OpenBSD.

                          1. 4

                            It supports FreeBSD now, after some contributions from external developers. There are only official pre-built releases for Ubuntu 14.04 and 15.10.

                            1. 1

                              Linux support was in the initial open source release I think.

                            1. 13

                              I think that, once it becomes Open Source, Swift could easily be a contender for this list:

                              • Huge adoption in a little over a year of existence
                              • Lots of memory safety guarantees by a strong, LLVM-backed compiler
                              • Near-C++/C performance
                              • Very mature and well-implemented C (and Objective-C) interop
                              • Automatic Reference Counting
                              1. 18

                                I think if Apple were serious about making Swift open source they’d have done it already. They’ve broken these kind of promises before (Facetime protocol). We should treat it as a proprietary language unless and until it gets an actual OS release.

                                1. 8

                                  There was an issue with patent encumbrance that prevented Apple from going ahead with their original plans for FaceTime. The last few Swift releases have focused on interop with relatively obscure C features that Cocoa/iOS developers almost never use, which I take as (admittedly circumstantial) evidence that they are indeed serious about making it work on other platforms such as Linux.

                                  1. 3

                                    As a note, Apple (Chris Lattner really) said the end of the year for open source swift.

                                    https://twitter.com/clattner_llvm/status/641697365003341824

                                    So while you’re right, you’re also premature in the assumption they would have done it already. We don’t know their timelines or schedules outside of that twitter post. Even then, things could slip.

                                    1. 2

                                      They took their time with Webkit. I just hope with Swift they don’t dump a massive intractable hairball like the initial Webkit release which caused much animosity between the KHTML community. Let’s hope this time they do a better job.

                                    2. 11

                                      The problem of Swift is its master, as it was with Objective-C. While using Swift outside of the Apple ecosystem might become feasible, much example code still assumes Cocoa as some kind of de-facto stdlib, which is not going to be open sourced.

                                      1. 2

                                        I think this issue is surmountable. Much of the Swift sample code that exists is code for writing applications with GUIs that run on OS X or iOS devices. Swift applications on non-Apple platforms would either be non-GUI based (command line tools, web services) or GUI applications with bindings to non-Cocoa widget toolkits. In that case the lowest common denominator is the Foundation framework, a significant part of which is subsumed by the Swift standard library; the functionality that’s missing could be reasonably satisfied by an open-source replacement. (If nothing else, OpenStep’s Foundation implementation exists.)

                                        1. 2

                                          Have you ever tried to work with OpenStep and Foundation side by side?

                                          I admit I did it years ago, but it was the most horrible experience ever (beginning with the fact that OpenStep’s foundation did not build properly on OS X, which made side-by-side testing hard).

                                          Still, having Foundation under control by a party that might do whatever they want with it is a mayor issue. Surmountable, but an issue.

                                          1. 1

                                            I agree with you. Swift’s best hope for widespread adoption outside its original iOS/OS X application development use case probably hinges on the creation of a parallel community writing software that isn’t tied to Foundation, Apple open-sourcing some subset of Foundation (apart from what CF provides), or some combination of the two. I am definitely interested in seeing how much of an adverse effect Cocoa/Foundation dependence proves to be in the future, though.

                                          2. 2

                                            Cocotron also has an implementation of Foundation (along with many other Apple APIs). I’m not sure how well it works with Swift, since it’s implemented in ObjC.

                                            1. 1

                                              Cocotron also has an implementation of Foundation (along with many other Apple APIs). I’m not sure how well it works with Swift, since it’s implemented in ObjC.

                                              Well, Swift <-> ObjC is not an issue.

                                              1. 1

                                                Okay. :) I don’t currently have a Mac to develop on, so I wasn’t sure.