1. 0

    Please turn off justified text. It looks like ass. There’s too much space between the words.

    The rule of thumb for traditional typesetting is that the column of text should be wide enough to fit the whole alphabet twice, and your column isn’t quite wide enough by that rule. But since you’re not using LaTeX, but rather the dumb* text layout algorithm built into the web browser, you really need a wider column than that.

    * If the LaTeX algorithm were used in a browser, the text would jump around horribly during progressive loading, so it’s probably the right call. But it does make CSS text justification rather useless, since you usually don’t want to use a wide enough column for it to look good anyway.

    1. 3

      These seems rather needlessly picky and nonconstructive.

      1.  

        I think GP formulated a bit too confrontational but I agree. I really liked how thoughtful the author of the article was for all kinds of things but the text column is infuriatingly narrow so for a better experience I would need to switch into Reader mode (which does very little to the site except make the text more readable). A shame since the rest is very nice and could be easily improved.

    1. 9

      I’ve been considering taking on a project in this line for a while but haven’t had the need for it recently - I’ve got a Kodak Pakon, which is a bulk film scanner that drug stores used back in the days of 1 hour photo development. Unfortunately the driver is Windows XP only, and I’d really love to use it without running a VM.

      1. 1

        Can I ask where you got that device? Is the quality of the scans good?

        1. 3

          I got mine on the second hand market from someone who got it from whichever drug store liquidated it - Walgreens, I think? - and yeah! It scans at 6MP, which is a little low by modern standards but meets all my requirements from film, and it has really excellent color reproduction. The real killer feature is that it can scan an entire roll of 35mm film without any interaction. You see them on ebay pretty frequently, there’s a couple different versions but the most common is the F135 that I have.

        2.  

          The lack of drivers is exactly what has kept me away from acquiring a Pakon, hoping someone will write a FOSS driver of some kind.

        1. 11

          I wonder how much of the issue is people being unwilling to pay versus people being unwilling to go through the effort of paying. Probably more the former, but if the latter has an impact, there might be ways of addressing that too. Maybe something like the Spotify model, where you donate 5 dollars a month and it’s split among many different projects?

          1. 5

            where you donate 5 dollars a month and it’s split among many different projects?

            And then you have effectively https://www.patreon.com/

            1. 7

              You kinda do, but the model of Patreon is to donate a significant sum to a specific recipient, while this model would be a chosen sum split across several receivers. I imagine it would be easier to only commit $5-10 a month knowing that all the projects you enjoy will get a small sum from you rather than choosing only one or two projects you want to support the most.

              1. 7

                So, exactly like Flattr.

                1. 3

                  That does indeed look exactly like what I would want embraced in the FOSS community. It seems difficult to find creators to support via their page, so the creators would have to promote their presence on Flattr on their project pages.

                  I would imagine this is the kind of thing that the GitHub sponsor system could employ to great effect as well. GitHub is already fairly well trusted (inb4 zomg M$!) and many developers already have a relationship to the platform.

            2. 3

              This sounds like a good idea actually, but what would be the difference between subscribing to a service like that versus setting up a recurring donation to your favorite projects?

              1. 6

                I only have to do it once, as opposed to for every project I want to donate to. Also it can have sensible defaults, where important transitive dependencies also get money.

                1. 3

                  Automatically donating to dependencies is a very interesting concept!

                  1. 4

                    Yeah it is! Seems like subscribing to a service that takes $5 each month, and trawls my dev directory tree to figure out who to send it to would be super useful.

                    1.  

                      Problem is that as soon as something like that takes off, all your dependencies are going to start changing in an effort to game the system.

                      1.  

                        Not sure what you mean? Who is it who has the motivation to game anything and how would they do it?

                        1.  

                          Once there’s money involved, everybody has motivation to game it, and how they’ll game it depends on how it works. The only surety is that it’ll happen.

            1. 4

              punkt phones may be an option.

              1. 4

                Why would you build one of those on top of AOSP?

                1. 2

                  Because there is no alternative; the baseband based dumbphone OSes went away in LTE, so now pretty much everything that’s a dumbphone, let alone a featurephone, is running Android.

                  1. 1

                    Well, that’s just sad.

                2. 3

                  I have one of these too, and while the hardware is really nice to hold and use, the software has been incredibly buggy. (not to mention that you really have to consider whether nothing but phone calls and texting are enough for you) There was a recent software update that purports to have fixed most issues, but I haven’t had a chance to really put it through its paces yet.

                  1. 6

                    It’s silly that this is using Android, and has 4G, since it seems to only to phone/sms.

                    1. 3

                      This.

                      It seems interesting at first glance, and it looks like they nailed the desire for minimality. Then you look at what’s below minimality and you find it’s not minimal at all :)

                      1. 3

                        Having 4G is probably good to be future-proof. Taiwan for example has sunset GSM in 2018 and in 2019 UMTS was completely turned off, with LTE the only remaining option. Other countries are following suit over time.

                        1. 3

                          It’s also for the tethering. If you want to be intentional about internet usage, what better than having to get out a purpose built device?

                        2. 1

                          IIRC the MP02 didn’t support group texting when it launched, but they said they might support it with a future software update. Does it support group texting now?

                          1. 1

                            I can’t say, I’ve never tried group texting. Sorry.

                        3. 2

                          It’d be perfect if it came with a QWERTY keyboard (and shipped to India).

                        1. 3

                          I was just reading about init-system diversity within NixOS. I was wondering if anyone could provide a few links detailing the Red Hat connection to systemd? Thanks in advance!

                          1. 9

                            Lennart Poettering, the principal author of systemd works for Red Hat. Yes, the same Red Hat that has been running a Linux distribution since 1995 and contributes a lot of code to the Linux kernel.

                          1. 18

                            I applaud the attempt, but given how annoying those websites already make themselves to use (get fucked, new Reddit) I’m skeptical of its efficiency.

                            1. 23

                              the day they break old.reddit.com is the day i will finally be free

                              1. 10

                                Same with new Twitter, it is as if the website got worse to race this project to completion.

                                1. 3

                                  I’m curious what work they do that requires Reddit and Twitter though.

                                  1. 7

                                    So does their employer.

                                1. 17

                                  Further to this point. Strive to design your data structures so that ideally there is only one way to represent each value. That means for example NOT storing your datetimes as strings. This will imply that your parsing step also has a normalization step. In fact storing anything important as a string is a code smell.

                                  1. 9

                                    A person’s name should be stored as a string. City names. Stock symbols. Lots of things are best stored as strings.

                                    1. 3

                                      Names of things are best stored as strings, yes.

                                      1. 1

                                        What I recommend though is to encode them in their own named string types, to prevent using the strings in ways that they are not meant to be used. We often use that to encode ID references to things which should be mostly “opaque BLOBs”.

                                      2. 3

                                        Should stock symbols contain emojis or newlines, or be 100 characters long? Probably not. I assume there are standards for what a stock symbol can be. If you have a StockSymbol type constructed by a parser that disallows these things, you can catch errors earlier. Of course then the question is what do you do when the validation fails, but it does force a decision about what to do when you get garbage, and once you have a StockSymbol you can render it in the UI with confidence that it will fit.

                                      3. 3

                                        Interesting. If you don’t mind, I’d like to poke at that a bit.

                                        Why should you care what anything is stored as? In fact, why should you expect the rest of the universe, including the persistence mechanism, to maintain anything at all about your particular type system for your application?

                                        1. 7

                                          They can maintain it in their own type system. The issue is information loss. A string can contain nearly anything and thus I know nearly nothing about it and must bear a heavy burden learning (parsing or validating). A datetime object can contain many fewer things and thus I know quite a lot about it lowering the relearning burden.

                                          You can also build and maintain “tight” connections between systems where information is not lost. This requires owning and controlling both ends. But generally these tight connections are hard to maintain because you need some system which validates the logic of the connection and lives “above” each system being connected.

                                          Some people use a typed language with code generation, for instance.

                                          1. 3

                                            @zxtx told the reader trying to leverage type systems to design their own program a certain way that derives more benefit from type systems. The rest of the universe can still do their own thing.

                                            I’m not sure the string recommendation is correct. There’s several languages that are heavily based on strings powering all kinds of things out there successfully. I’ve also seen formally-verified implementations of string functionality. zxtx’s advice does sound like a good default.

                                            We probably should have, in addition to it, verified libraries for strings and common conversions. Then, contracts and/or types to ensure calling code uses them correctly. Then, developers can use either option safely.

                                            1. 3

                                              Sure some things inevitably have to be strings: personal names, addresses, song titles. But if you are doing part-of-speech tagging or word tokenization, an enumerative type is a way better choice than string. As a fairly active awk user I definitely sympathize with the power of string-y languages, but I think people new to typed languages overuse rather than underuse strings.

                                              1. 2

                                                Unfortunately, even folks who have used typed languages for years (or decades) still overuse strings. I’m guilty of this.

                                            2. 3

                                              I admit to going back and forth on this subject….

                                              As soon as you store a person name as a PersonName object…… it’s no longer a POD and you’re constricted to a tiny tiny subset of operations on it…. (With the usual backdoor of providing a toString method)

                                              On the other hand Bjarne Stoustrup’s assertion that if you have a class invariant to enforce… that’s the job of an object / type.

                                              Rich Hickey the clojure guy has an interesting talk exactly on this subject with an interesting different take….

                                              Instead of hiding the data in a type with an utter poverty of operators, leave everything as a pod of complex structure which can be validated and specified checked and asserted on using a clojure spec.

                                              ie. If you want something with a specific shape, you have the spec to rely on, if you want to treat it as ye olde list or array of string….. go ahead.

                                              1. 11

                                                I stuck to simple examples of the technique in my blog post to be as accessible as possible and to communicate the ideas in the purest possible way, but there are many slightly more advanced techniques that allow you to do the kind of thing you’re describing, but with static (rather than dynamic) guarantees. For some examples, I’d highly recommend taking a look at the Ghosts of Departed Proofs paper cited in the conclusion, since it addresses many of your concerns.

                                                1. 1

                                                  Ok. That took me awhile to digest…. but was worth it. Thanks.

                                                  For C++/D speakers it’s worth looking at this first to get the idea of phantom types…

                                                  https://blog.demofox.org/2015/02/05/getting-strongly-typed-typedefs-using-phantom-types/

                                                2. 4

                                                  As someone who worked professionally with both Clojure (before spec but with Prismatic Schema) and OCaml and I have to say I utterly prefer to encode invariants in a custom type with only a few operations instead of the Clojure way of having everything in a hashmap with some kind of structure (hopefully) and lots of operations which operate on them.

                                                  My main issue writing Clojure was that I did apply some of these (really useful and versatile) functions on my data, but the data didn’t really match what I had expected so the results were somewhat surprising in edge cases and I had to spend a lot of brain time to figure out what was wrong and how and where that wrong data came to be.

                                                  In OCaml I rarely have the problem and if I want to use common functions, I can base my data structures on existing data structures that provide the functions I want to over the types I need, so in practice not being able to use e.g. merge-with on any two pieces of data is not that painful. For some boilerplate, deriving provides an acceptable compromise between verbosity and safety.

                                                  I can in theory do a similar thing in Clojure as well, but then I would need to add validation basically everywhere which makes everything rather verbose.

                                                  1. 3

                                                    I’ve used Clojure for 8 years or so, and have recently been very happy with Kotlin, which supports sealed types that you can case-match on, and with very little boilerplate—but also embraces immutability, like Clojure.

                                                    With Clojure, I really miss static analysis, and it’s a tough tradeoff with the lovely parts (such as the extremely short development cycle time.)

                                                  2. 3

                                                    The ability to “taint” existing types is the answer we need for this. Not a decorator / facade sort of thing, just a taint/blessing that exists only within the type system, with a specific gatekeeper being where the validation is done and the taint removed/blessing applied.

                                                    1. 2

                                                      In Go, wrapping a string in a new type is zero-overhead, and you can cast it back easily. So it’s mostly just a speedbump to make sure that if you do something unsafe, you’re doing it on purpose and it will be seen in code review. If the type doesn’t have very many operators, you might have more type casts that need to be checked for safety, but it’s usually pretty easy to add a method.

                                                      On the other hand, the Go designers decided not to validate the string type, instead accepting arbitrary binary data with it only being convention that it’s usually UTF8. This bothers some people. But where it’s important, you could still do Unicode validation and create a new type if you want, and at that point there’s probably other validation you should be doing too.

                                                      1. 1

                                                        The last one is the best.

                                                        Instead of scaling out code, we should be scaling out tests. We’re doing it backwards.

                                                        I’ve been meaning to put together a conference proposal on this but haven’t gotten around to it. It’s the kind of thing that blows people’s minds.

                                                        1. 1

                                                          Can you expand a little on this? Sounds interesting.

                                                          1. 3

                                                            People don’t understand what tests do. If you ask them, they might say they help your code be less buggy, or they show your business customers that your program does what they’re paying for.

                                                            That’s all true, but horribly incomplete. Tests resolve language.

                                                            That is, whether it’s science, programming, running a business, or any of hundreds of other areas where human language intersects science, tests are the only tools for determining what’s true or not in unambiguous terms. Come up with some super cool new way of making a superconductor? Great! Let’s have somebody go out and make it on their own, perform a test. If the test passes, you’re on to something. Yay! If the tests fails? Either you’re mistaken or the language and terms you’re using to describe your new process has holes the reproducer was unable to resolve. Either way, that’s important information. It’s also information you wouldn’t have gained otherwise without a test.

                                                            In coding, as I mentioned above, we have two levels of tests. The unit level, which asks “Is this code working the way I expected it to?” and the acceptance level, which asks “Is the program overall performing as it should?” (I understand the testing pyramid, I am simplifying for purposes of making a terse point). But there are all sorts of other activities we do in which the tests are not visible. Once the app is deployed, does it make a profit? Is your team working the best way it can? Are you building this app the best way you should? Are you wasting time on non-critical activities? Will this work with other, unknown apps in the future? And so on.

                                                            We’ve quantitized some of this with things like integration testing (which only works with existing apps). Frankly, we’ve made up other stuff out of whole cloth, just so we can have a test, something to measure. In most all cases, when we make stuff up we end up actually increasing friction and decreasing productivity, just the opposite of what we want.

                                                            So how do we know if we’re doing the best job we can? Only through tests, whether hidden or visible. How are we doing at creating tests? I’d argue pretty sucky. How can we do tests better? More to the point, if we do tests correctly, doesn’t it make whatever language, platform, or technology we use a seconary-effect as opposed to a primary one? We spend so much time and effort talking about tools in this biz when nobody can agree on whether we’re doing the work right. I submit that this happens because we’re focusing far, far too much on our reactions to the problem than the problems themselves. If we can create and deploy tests in a comprehensive and tech-independent manner, we can then truly begin discussing how to take this work to the next level. Either that or we’re going to spend the next 50 years talking about various versions of hammers instead of how to build safe, affordable, and desirable houses, which is what we should be doing.

                                                            There’s a lot missing in my reply, but once we accept that our test game sucks? Then a larger and better conversation can happen.

                                                            1. 1

                                                              It will take me some time to digest this properly… it’s a completely different angle to which I usually approach the matter. (I’m not saying you’re wrong, I’m just saying you coming at it from such a different angle I’m going to have to step back and contemplate.)

                                                              To understand where I’m coming from let me add…

                                                              I regard tests as a lazy pragmatic “good enough” alternative to program proving.

                                                              If we were excellent mathematicians, we would prove our programs were correct exactly the way mathematicians prove theorems.

                                                              Except we have a massive shortage of that grade of mathematicians, so what can we do?

                                                              Design by Contract and testing.

                                                              DbC takes the raw concepts of program proving (pre-conditions and post conditions and invariants) and then we use the tests to setup the preconditions.

                                                              Writing complete accurate postconditions is hard, about as hard as writing the software, so we have a “useful subset” of postconditions for particular instance of the inputs.

                                                              Crude, very crude, but fairly effective in practice.

                                                              My other view of unit tests is closer to yours…

                                                              They are our executable documentation (proven correct and current) of how to use our software and what it does. So a design principle for tests is they should be Good, Readable understandable documentation.

                                                              Now I will shutup and contemplate for a day or two.

                                                              1. 1

                                                                We are saying the same thing. Heck we might even be agreeing. We’re just starting from completely opposite sides of the problem. Formally validating a program proves that it matches the specification. In this case the formal specification is the test.

                                                                I think when I mention tests you may be thinking of testing as it was done in the IT industry, either manual or automated. But I mean the term in the generic sense. We all test, all the time.

                                                                What I realized was that you can’t write a line of code without a test. The vast majority of times that test is in your head. Works for me. You say to yourself “How am I going to do X?” then you write some code in. You look at the code. It appears to do X. Life is good.

                                                                So you never get away from tests. The only real questions are what kinds of tests, where do they live, who creates them, and so forth. I’m not providing any answers to these questions. My point is that once you realize you don’t create structure without some kind of tests somewhere, even if only in your head, you start wondering exactly which tests are being used to create which things.

                                                                My thesis is that if we were as good at creating tests as we were at creating code, the coding wouldn’t matter. Once again, just like I don’t care whether you’re an OCAML person or a Javascript person, for purposes of this comment I don’t care if your tests are based on a conversation at a local bar or written in stone. That’s not the important part. The thing is that in various situations, all of these things we talk about doing with code, we should be doing with tests. If the tests are going to run anyway, and the tests have to pass for the project to be complete or problem solved, then it’s far more important to talk about the meaning of a successful completion to the project or a solution to the problem than it is to talk about how to get there.

                                                                Let’s picture two programmers. Both of them have to create the world’s first accounting program. Programmer A sits down with his tool of choice and begins slinging out code. Surely enough, in a short time voila! People are happy. Programmer B spends the same amount of time creating tests that describe a successful solution to the problem. He has nothing to show for it.

                                                                But now let’s move to the next day. Programmer A is just now beginning to learn about all of the things he missed when he was solving the problem. He’s learning that for a variety of reasons, many of which involve the fact that we don’t understand something until we attempt to codify it. He begins fixing stuff. Programmer B, on the other hand, does nothing. He can code or he can hire a thousand programmers. The tech details do not matter.

                                                                Programmer B, of course, will learn too, but he will learn by changing his tests. Programmer A will learn inside his own head. From there he has a mental test. He writes code. It is fixed. Hopefully. Programmer A keeps adjusting his internal mental model, then making his code fit the model, until the tests pass, ie nobody complains. Programmer B keeps adjusting an external model, doing the same thing.

                                                                Which of these scale when we hire more coders? Which are these are programs the programmer can walk away from? Formal verification shows that the model meets the spec. What I’m talking about is how the spec is created, the human process. That involves managing tests, in your head, on paper, in code, wherever. The point here is that if you do a better, quicker job of firming the language up into a spec, the tech stuff downstream from that becomes less of an issue. In fact, now we can start asking and answering questions about which coding technologies might or might not be good for various chores.

                                                                I probably did a poor job of that. Sorry. There’s a reason various programming technologies are better or worse at various tasks. Without the clarification tests provide, discussions on their relative merits lack a common system of understanding.

                                                            2. 1

                                                              ADD: I’ll add that most all of the conversations we’re having around tech tools are actually conversations we should be having about tests: can they scale, can they run anywhere, can they be deployed in modules, can we easily create and consume stand-alone units, are they easy-to-use, does it do only what it’s supposed to do and nothing else, is it really needed, is it difficult to make mistakes, and so on. Testing strikes me as being in the same place today as coding was in the early-to-mid 80s when OO first started becoming popular. We’re just not beginning to think about the right questions, but nowhere near coming up with answers.

                                                              1. 1

                                                                Hmm… In some ways we hit “Peak Testing” a few years back when we had superb team of manual testers, well trained, excellent processes, excellent documentation.

                                                                If you got a bug report it had all the details you needed to reproduce it, configs, what the behaviour that was expected, what was the behaviour found, everything. You just sat down and started fixing.

                                                                Then test automation became The Big Thing and we hit something of a Nadir in test evolution which we are slowly climbing out of…

                                                                This is how it was in the darkest of days…

                                                                “There’s a bug in your software.”

                                                                Ok, fine, I’ll fix how do I reproduce…..

                                                                “It killed everything on the racks, you’ll have to visit each device and manually rollback.”

                                                                (Shit) Ok, so what is the bug?

                                                                “A test on Jenkins failed.”

                                                                Ok, can I have a link please?

                                                                “Follow from the dashboard”

                                                                What is this test trying to test exactly?

                                                                “Don’t know, somebody sometime ago thought it a good idea”.

                                                                Umm, how do I reproduce this?

                                                                “You need a rack room full of equipment, a couple of cloud servers and several gigabytes of python modules mostly unrelated to anything”.

                                                                I see. Can I have a debug connector to the failing device.

                                                                “No.”

                                                                Oh dear. Anyway, I can’t seem to reproduce it… how often does it occur?

                                                                “Oh we run a random button pusher all weekend and it fails once.”

                                                                Umm, what was it doing when it failed?

                                                                “Here is a several gigabyte log file.”

                                                                Hmm. Wait a bit, if I my close reading of these logs are correct, the previous test case killed it, and the only the next test case noticed…. I’ve been looking at the wrong test case and logs for days.

                                                        2. 1

                                                          Because throughout your program you will need to do comparisons or equality checks and if you aren’t normalizing, that normalization needs to happen at every point you do some comparison or equality check. Inevitably, you will forget to do this normalization and hard to debug errors will get introduced into the codebase.

                                                          1. 1

                                                            Ok. Thank you. I figured out what my hang up was. You first say “Strive to design your data structures so that ideally there is only one way to represent each value.” which I was completely agreeing with. Then you said “In fact storing anything important as a string is a code smell” which made me do a WTF. The assumption here is that you have one and only one persistent data structure for any type of data. In a pure functional environment, what I do with a customer list in one situation might be completely different from what I would do with it in another, and I associate any constraints I would put on the type to be much more related to what I want to do with the data than to my internal model of how the data would be used everywhere. I really don’t have a model of how the universe operates with “customer”. Seen too many different customer classes in the same problem domain written in all kinds of ways. What I want is a parsed, strongly-typed customer class right now to do this one thing.

                                                            See JohnCarter’s comment above. It’s a thorny problem and there are many ways of looking at it.

                                                            1. 1

                                                              I think ideally you still do want a single source of truth. If you have multiple data structures storing customer data you have to keep them synced up somehow. But these single sources of data are cumbersome to work with. I think in practice the way this manifests in my code is that I will have multiple data structures for the same data, but total functions between them.

                                                              1. 2

                                                                Worked with a guy once where we were going to make a domain model for an agency. “No problem!” he said, “They’ve made a master domain model for everything!”

                                                                This was an unmitigated disaster. The reason was that it was confusing a people process (determining what was valid for various concepts in various contexts) with two technical processes (programming and data storage) All three of these evolved dramatically over time, and even if you could freeze the ideas, any three people probably wouldn’t agree on the answers.

                                                                I’m not saying there shouldn’t be a single source of data. There should be. There should even be a single source of truth. My point is that this single point of truth is the code that evaluates the data to perform some certain action. This is because when you’re coding that action, you’ll have the right people there to answer the questions. Should some of that percolate up into relational models and database constraints? Sure, if you want them to. But then what do you do if you get bad incoming data? Suppose I only get a customer with first name, last name, and email? Most everybody in the org will tell you that it’s invalid. Except for the marketing people. To them all they need is email.

                                                                Now you may say but that’s not really a customer, that’s a marketing lead, and you’d be correct. But once again, you’re making the assumption that you can somehow look over the entire problem space and know everything there is to know. Do the mail marketing guys think of that as a lead? No. How would you know that? It turns out that for anything but a suite of apps you entirely control and a business you own, you’re always wrong. There’s always an impedance mismatch.

                                                                So it is fine however people want to model and code their stuff. Make a single place for data. But the only way to validate any bit of data is when you’re trying to use it for something, so the sole source of truth has to be in the type code that parses the data going into the function that you’re writing – and that type, that parsing, and that function are forever joined. (by the people and business that get value from that function)

                                                                1. 2

                                                                  I suspect we might be talking a bit past each other. To use your example, I might ask what it means to be a customer. It might require purchasing something or having a payment method associated with them.

                                                                  I would in this case have a data type for Lead that is only email address, a unique uuid and optionally a name. Elsewhere there is code that turns a Lead into a Customer. The idea being to not keep running validation logic beyond when it is necessary. This might mean having data types Status = Active | Inactive | Suspended which needs to be pulled from external data regularly. I can imagine hundreds of different data types used for all the different ways you might interact with a customer, many instances of these data types created likely right before they are used.

                                                        3. 1

                                                          Mostly agree, but I’d like to add that the ability to pass along information from one part of the system to another should not necessarily require understanding that information from the middle-man perspective. Often this takes the form of implicit ambient information such as a threadlocal or “context” system that’s implemented in library code, but as a language feature it could be made first-class.

                                                        1. 9

                                                          With Python 3 being out for so long and the Python 2 deadline being delayed I think it is somewhat embarassing Mercurial still doesn’t use it as default. Sure, 3rd party plugins are not up to date, but the longer they wait with the migration, the longer Python 2 will need to be kept alive.

                                                          1. 13

                                                            Python 3 has been especially difficult for Mercurial because Mercurial does not use encodings. It’s an application to store your bytes and your bytes are just bytes. You don’t want Mercurial (or git, for that matter) to start having opinions about how to interpret the bytes you give it. All the data that hg deals with – all of it – is just bytes.

                                                            The Python 2 deprecation deadline was mostly extended by 5 years for Mercurial. A bunch of us (not just Mercurial, but probably we were the loudest ones) crowded around Guido at Pycon 2014 and told him about how difficult Python 3 was for Mercurial. In response, Guido later announced that day that we would have 5 more years. The bare minimum we needed was PEP 461, which wasn’t available back in 2014, and once that was done, the rest was just a lot of hard work.

                                                            I am not at all embarrassed by the gargantuan effort that my fellow Mercurial maintainers have made to port Mercurial to Python 3. Quite the contrary, I’m proud of them and have gotten a little resentful that the Python 3 upgrade path has not been nearly as easy as its proponents claim.

                                                            1. 6

                                                              Oil is the same way – it doesn’t use Python’s unicode object. it uses bytes, since libc calls all take and return bytes (e.g. execve, chdir, listing directory entries, etc.)

                                                              http://www.oilshell.org/blog/2018/03/04.html#faq

                                                              Right now the Python 2 interpreter is bundled with Oil. I removed at least half of the interpreter, which I’m not using [1] (e.g. the whole front end, unicodeobject.c, complexobject.c, etc.)

                                                              Eventually I want to get rid of the dependence on the interpreter. But I think this was a decent way to make progress quickly and have a working program the whole time.

                                                              Since hg is already a mature and working program, I imagine bundling the interpreter might also have been a worthwhile strategy.

                                                              It would also largely fix the startup time issue (which I think got worse in Python 3) since you’re not dependent on the system PYTHONPATH and you can modify the startup sequence with some #ifdefs.

                                                              People always talk about maintenance of Python 2 but I don’t really think it’s a problem. It’s a very mature and understandable codebase. I’ve made dozens of small, localized modifications to it.

                                                              And if Python 2 has a security issue in say the tempfile module, well it doesn’t affect a program that doesn’t use that module.

                                                              [1] http://www.oilshell.org/blog/2018/11/15.html

                                                              1. 6

                                                                We’re actually vaguely planning to bundle Python with Mercurial via PyOxidizer - it should be a one-file binary at that point.

                                                                I’m sure Greg would be interested in Oil doing it too, but I think it can’t be done on Python 2 for a variety of reasons.

                                                                1. 1

                                                                  People always talk about maintenance of Python 2 but I don’t really think it’s a problem. It’s a very mature and understandable codebase. I’ve made dozens of small, localized modifications to it.

                                                                  So you’ve made dozens of small modifications to it (python) and are now carrying those changes, and you don’t see a problem with many people doing the same thing? It seems like you’ll quickly end up in a situation where one implementation of python2 used by/included in one program is not the same as another used by/included in another, and that is a bigger maintenance problem.

                                                                  1. 1

                                                                    Why is that a maintenance problem? There can be N different forks of Python 2, e.g. one used for hg, one used for Oil, and I don’t see the problem. Each team maintains it separately.

                                                                    Python 2 is a stable, well-tested, and well-understood codebase.

                                                                    It’s somewhat analogous to there being N forks of the BSD kernel. In that case I’d say it’s also a feature and not a bug.

                                                                    Although you could argue why they don’t combine their efforts (though I don’t think it makes sense to argue). Either way, that argument doesn’t make sense for hg or Oil or dozens of other programs that are written in Python and may want to make small, local, backward incompatible modifications.

                                                                    1. 1

                                                                      The problem is that you have a bunch of different teams maintaining essentially (but not quite) the same thing in their own gardens. So when a vulnerability is found, you have to rely on them all to 1) notice it then 2) fix/deploy. And users now have N number of “python 2” installs on their one system that are in all sorts of different states. How do you know if you have something using a broken “version” of python 2? When a CVE is posted, how can you possibly tell if you’re affected in all the different “versions” of python 2 on your system?

                                                                      1. 2

                                                                        On balance, I think using Python 2.7 and statically linking it reduces the number of vulnerabilities. (Although it’s not ideal for other non-security reasons, which is why it’s not a permanent solution).

                                                                        If you rewrite the functionality from scratch rather than reusing well-tested pieces of code, you’d have as many or more vulnerabilities in your own code. Unless of course there is something you’re doing that the Python team isn’t (possible but not that likely).

                                                                        I’d say Python 2.7 more solid than the average piece of code simply because it’s undergone a lot of testing and usage. There have been a lot of eyeballs on that code.

                                                                        And as mentioned, the vulnerabilities in stdlib modules that Oil don’t use don’t matter because they’re not even in the binary (e.g. I see CVEs in XMLRPCServer, which has nothing to with Oil). On top of that, I also remove around 150K lines of other interpreter code, leaving somewhere around 100K. That’s more than I would like, but it’s not a problem to maintain.


                                                                        On a related note, I think there is some cargo culting of the “CVE treadmill”. Newer code isn’t always better. If the development team isn’t careful about security, you can patch one CVE and introduce another one. In fact I think that’s pretty common because software tends to get larger over time.

                                                                        I’d rather move to a model where there is actual reasoning about security from first principles rather than “I heard about this CVE so I need to update all the places where it occurs, and now I did, so the problem is gone”. It’s kind of where the industry is now, but it doesn’t reflect the underlying reality.

                                                                2. 2

                                                                  bare minimum we needed was PEP 461

                                                                  Can you expand on that? That request looks just like some convenience feature that could have just been a normal method.

                                                                  1. 1

                                                                    It’s because mercurial used % formatting on python2 strings heavily to encode the mercurial wire protocol. Before pep 461, % formatting on bytestrings was not allowed, so they would have needed to carefully rewrite the wire protocol code in a way that would have left the code less readable.

                                                                    1. 2

                                                                      Isn’t that pretty much a basic refactoring operation in any typed language?

                                                                      1. 7

                                                                        If you take a stroll through the gargantuan effort of hundreds of commits I linked above, I think you’ll see that it wasn’t a basic refactoring operation.

                                                                        1. 4

                                                                          Not sure what you mean, regardless it doesn’t matter much for Mercurial because it’s not written in a typed language.

                                                                          Also I think the aspect of rewriting the code for no gain but leaving the code less readable is a big deal, readability counts.

                                                                    2. 1

                                                                      It’s an application to store your bytes and your bytes are just bytes.

                                                                      Python 3 has a “just bytes” type. One that’s actually far better than Python 2’s, because Python 2’s was overloaded by also needing to be the default string object. For example, a while ago I went back and did the first couple sets of cryptopals challenges again using Python 3 instead of 2, and it was night-and-day how much nicer Python 3 was for working with “just bytes”.

                                                                      And the fact that Mercurial was apparently utterly blocked by not being able to use % on bytes objects indicates Mercurial was not treating these bytes as “just bytes” – the % operator is there to let you do string formatting operations with printf()-style syntax, which only makes sense if the bytes are in fact being treated as strings (which in turn means you need to “use encodings”, because formatting operations on byte sequences of unknown encoding are a ticking time bomb in the code).

                                                                      1. 6

                                                                        Please read PEP 461. Its use cases are explained there and apply to Mercurial.

                                                                        1. 4

                                                                          I have read it. I’m not disagreeing that the Mercurial team says PEP 461 makes the their lives easier. I’m disagreeing that use of % on str in Python 2 was a “just bytes” operation.

                                                                          Even the rationale in the PEP, and the discussion on python-dev when the PEP was being drafted, acknowledged this – the whole purpose for this is to allow treating some bytes as actually being encoded text, and manipulate them in ways that only make sense for encoded text. Which in turn carries an assumption about what encoding was used to produce the bytes, etc.

                                                                          Which means that all of your insistence on “just bytes”, “no encodings”, “no interpretation”, and so on in your original comment was, to be charitable, a red herring. Mercurial didn’t need % formatting for “just bytes” operations; it needed it for operations on bytes that Mercurial assumes are ASCII-encoded text.

                                                                          I don’t doubt it’s perceived as easier for Mercurial to continue doing things that way. I do doubt whether it’s the right approach to wire protocols which consist of mixed encoded text and “just bytes”.

                                                                    3. 4

                                                                      Actually with the latest release (Mercurial 5.2), Python3 is the default.

                                                                      1. 1

                                                                        …except on Windows, unless I missed something, correct?

                                                                        1. 3

                                                                          Yep. Windows has a little ways to go yet. :(

                                                                    1. 7

                                                                      Signal: It straight up sucks on Android.

                                                                      That’s completely not my experience. It does everything I want or know I need from a messaging client.

                                                                      I completely agree regarding the lack of federation though.

                                                                      1. 3

                                                                        I completely agree regarding the lack of federation though.

                                                                        That said, IRC is no better in this regard; I can’t just federate with Rizon or freenode, since IRC is not set up for a distributed system of untrusted server instances.

                                                                        1. 1

                                                                          IRC was originally a single network, but an incident occured, because the net was too trusting…

                                                                      1. 9

                                                                        I am not sure what in the Signal client on Android sucks? Could you elaborate? I’ve been using it for years to communicate with friends and family and I don’t have any big frustrations with it.

                                                                        1. 5

                                                                          I find the mobile client acceptable (iOS in my case) but my real problem is when using both mobile and desktop clients, I get very erratic behavior on desktop: messages very often get reordered or dropped. Like, the conversation will be seriously scrambled. This doesn’t seem acceptable to me—I can imagine it leading to serious confusion, even danger.

                                                                          1. 2

                                                                            I use the Android app and the desktop app every day and have never seem messaged dropped, and only very rarely seem misordering. Hopefully they can address whatever’s causing the issues you’re seeing.

                                                                            1. 2

                                                                              I think it’s more likely to happen if you use the desktop client occasionally so it has to sync a batch of messages… I’ve seen GitHub issues about it but no solution.

                                                                          2. 4

                                                                            This is just my opinion, mind you, but I’m not a big fan of the UI. Maybe Telegram’s UI has spoiled me.

                                                                            1. 2

                                                                              I do agree with @icyphox. It is not as smooth as the Telegram GUI. You can’t use gestures for example.

                                                                              1. 1

                                                                                Pardon me for being out of the loop but what gestures do you need for for communication with people?

                                                                                On the contrary, I found using IRC on the phone to be some of the worst experiences with regards to UI.

                                                                                1. 2

                                                                                  The fact that you can “swipe” from the settings menu to the home menu. You don’t have to reach with your thumb the button in the left upper corner, which is quite inconvenient with today’s screen sizes. You can do the same from conversations to the homscreen and from the contacts detail window.

                                                                              2. 2

                                                                                I don’t think it sucks, I think that SMS is a tough problem. In my experience on Signal, “MMS download failed” and “Error downloading MMS, tap to retry” was really frustrating. It’s still my default SMS client, but I’d rather not SMS.

                                                                              1. 9

                                                                                When I read their announcement tweets on Twitter, it was pointed out that this is awesome for preservation of games that require proprietary hardware.

                                                                                What confuses me though is how that is a fix, as this hardware itself is proprietary, so is prone to precisely the same problem a decade down.

                                                                                1. 2

                                                                                  But at least this is hardware you can buy right now that is expected to last for a while.

                                                                                  Plus the intellectual property issues (patents) should be sorted out by now, so given enough effort, anyone can try to make a new, open source one themselves. Hardware is, however, expensive, so I’m not really upset that they’re trying to make money.

                                                                                  1. 3

                                                                                    But at least this is hardware you can buy right now that is expected to last for a while.

                                                                                    That said, if you compare the complexity of these devices I am pretty sure the original Gameboy (DMG) will easily outlive this device. The DMG has a very simple construction with rather low complexity (even for its day, 1989) and runs of AA (or AAA in the case of the Pocket) batteries and is pretty rugged.

                                                                                    There is a point of being able to buy the hardware right now, but the games you’d need to buy second hand anyway, since the only thing left are a few indie releases.

                                                                                    1. 3

                                                                                      There is a point of being able to buy the hardware right now, but the games you’d need to buy second hand anyway, since the only thing left are a few indie releases.

                                                                                      That part, however, can’t be avoided without the cooperation of copyright holders. Good luck with that.

                                                                                      Most likely, none of us alive right now will see a Game Boy title enter the public domain because of the rather long expiry times (plural, since you have to keep track of the death date of every member on the team) involved.

                                                                                    2. 2

                                                                                      You can totally make money with non-proprietary hardware.

                                                                                      From a utility perspective, you are right.

                                                                                      From a preservation perspective, it’s not very useful to replace one undocumented thing by another.

                                                                                    3. 1

                                                                                      I think they’re leveraging “preservation” for marketing, you’re right, it’s not really a proper solution for that.

                                                                                    1. 7

                                                                                      So now product placement is allowed and even gets more upvotes than actually interesting content? mmmm

                                                                                      1. 11

                                                                                        I was thinking of posting an article to the various announcements on different sites but decided to post the product page instead to avoid the complaint about blogspam.

                                                                                        Here’s why I think that thing is interesting:

                                                                                        • A complete reimplementation of a Gameboy in FPGA. If I posted a Github link to that it would’ve been exciting for the hack-value of that alone
                                                                                        • An insanely hi-res screen (that some commenters here including me didn’t know existed)
                                                                                        • A second FPGA that might be useful for programming and is meant to be programmed
                                                                                        • A seller with a reputation of shipping good products, so it is not just vaporware and pretty renders
                                                                                        • A niche product that many people might miss. If I had posted the new iPhone, that would’ve been pretty boring

                                                                                        I am sorry you don’t find it interesting and I agree that this is a borderline post, but rest assured I used my best judgement to post something that is actually interesting at least to and a few other fellow crustaceans.

                                                                                        1. 11

                                                                                          There’s no code on this page, there’s no link to Github, and the thing isn’t even being sold until 2020.

                                                                                          It’s product dev-washing.

                                                                                          1. 2

                                                                                            Maybe, but it wasn’t posted by their company dev (see leonidas’s comment above), it’s kinda cool, it looks closed source anyway so I doubt there’s a github .. I mean you’re probably right, but it was still posted in good faith as something tech peeps would be interested in.

                                                                                          2. 2

                                                                                            What surprises me the most is that even though your comment is even more in the realm of advertising, it still got upvoted.

                                                                                            I am not saying you are doing it in bad faith but you should be aware that you are still doing advertising, whether you are paid or not (at this point I hope you are), that is the exact same practice.

                                                                                            I will not counter any of your points as it will only lengthen the discussion about this specific product.

                                                                                            My point is that here you get many articles with some vague value, surrounded by self-promotion of whatever company/product/job the author is working on, and they are not well received, how can an actual product page be any better?

                                                                                            1. 1

                                                                                              It would (have been) great to have put the contents of this comment in the original post.

                                                                                            2. 5

                                                                                              Some people, me included, get excited about new handheld gaming devices, specially if it is not emulation.

                                                                                              1. 5

                                                                                                I mean, it’s still emulation, in the sense that it’s Analogue’s best guess at how the Game Boy Advance worked, rather than licensing the original hardware design from Nintendo. It’s just not software emulation, so it can be more power-efficient than a general-purpose CPU.

                                                                                                1. 3

                                                                                                  Makes you wonder what edge cases it might fail on with some of those crazy cartridges with their co-processors and other weird chips onboard. I doubt there were as many of these in the portable space as with the SNES (with games like StarFox), but there are probably a few out there.

                                                                                                  1. 1

                                                                                                    Really good point. I found this list on reddit, certainly for the newer gameboy types (GB color or GBA) there seems to be a variety of stuff; less with the original hardware, but jumping out at me is RTC. It was common enough I hope they’ve tested at least that.

                                                                                                  2. 2

                                                                                                    it’s still emulation

                                                                                                    If anything it’s simulation. The hardware isn’t faked, it’s real transistors and everything else. That’s a huge difference.

                                                                                                    1. 1

                                                                                                      It’s a huge difference in technology, but does it make any perceptible difference to the user?

                                                                                                      1. 1

                                                                                                        This is a good question.

                                                                                                        Obviously, “perfect emulation” will not be any different.

                                                                                                        The main difference is, it’s a LOT easier to simulate the system at a lower level, offering better “high level” support, than the other way around. That’s why FPGA systems have generally been better than emulators.

                                                                                                        You are right though, this is aimed at enthusiasts and homebrewers. It was the same story with Analogue’s other products. I know the creator of these FPGA cores and it is a niche market, but one that pays well. They are extremely intelligent and the company is super smart too. Actually I think this is their “secret” project that’s been in the works as a side project for a long time.

                                                                                                        As soon as I saw this I signed up to the newsletter. This device is going to be sold out for a long time.

                                                                                                      2. 1

                                                                                                        It’s useful to distinguish “produce the same results, following the same method” (say, a hardware recreation of a hardware device) and “produce the same results, following a different method” (say, a software recreation of a hardware device).

                                                                                                        While some people use “simulation” and “emulation” respectively to mean those things, other people define them the other way around. For example, a “flight simulator” follows a very different method from a real aircraft, and “fluid simulation” generally aims to “look right” rather than throw billions of tiny particles around.

                                                                                                        To avoid confusion, I stick with “hardware emulation” to describe reverse-engineered devices like the Pocket, and “software emulation” to describe reverse-engineered programs.

                                                                                                    2. 3

                                                                                                      I think Nesh’s aversion comes from the content being an attempt to sell you this device in exchange for your hard-earned cash, not that it’s about video games

                                                                                                      1. 2

                                                                                                        I see. Yes, it makes sense. I saw the post from a different angle which is best summed by the bullet list in this previous comment by the op

                                                                                                      2. 2

                                                                                                        I am a gamedev and I also love gaming hardware but advertising is advertising.

                                                                                                        Some people get excited with new iPhones releases, a new Raspberry Pi version and other such IT products, should we now allow all those product pages because some people enjoy them?

                                                                                                    1. 3

                                                                                                      Are these hardware designed to play the original cartridges?!

                                                                                                      1. 1

                                                                                                        Yeah

                                                                                                        1. 3

                                                                                                          Without emulation?… How cool :O :O

                                                                                                          1. 4

                                                                                                            The original cores are implemented on the FPGA, so depending on how you look at it, sort of without emulation. But also unlike e.g. the Super Game Boy, without using the original parts.

                                                                                                            1. 1

                                                                                                              Yeah. which is pretty cool :)

                                                                                                      1. 8

                                                                                                        Well that looks pretty cool, but so far I’m happy enough with ODROID-GO and LSDJ.

                                                                                                        1. 5

                                                                                                          That one is nice too, but it is basically a single-board computer running presumably Linux and some software emulators. The Analogue Pocket is emulating the CPU cores.

                                                                                                          Also it comes with Nanoloop so I am hoping that the sound quality will be good and usable for LSDJ, so I don’t have to keep modding DMGs.

                                                                                                          1. 1

                                                                                                            One of my favorite things about ODROID-GO is that it doesn’t run Linux, it’s an ESP32 device with a custom OS. Way more power efficient and less hassle to maintain than (e.g.) EmulationStation on a Pi Zero. You just put roms on an SD card and done. Runs CircuitPython too but I haven’t played with that. The buttons feel pretty good, and you get to put it together yourself with a screwdriver in like 5 minutes. It supports all the major 8-bit platforms (not just handheld), and you don’t need physical carts. The display is nothing fancy, but its resolution is well matched to the emulated systems; I don’t need fake scanlines on such a small display! Ditto for the actual play: I can’t detect any latency or jitter. If I have good control feel, 60fps and all the pixels, why should I care whether I’m using software or hardware emulation?

                                                                                                            But I’m sure the Pocket will sound much better. The ODROID-GO has a buzzy little speaker and three volume levels, all too loud, not even a headphone jack. I don’t mind; when I want to play 8-bit audiophile (sort of a silly thing to do, honestly) I use my C64 rig.

                                                                                                        1. 1

                                                                                                          In a way I am sort of sad that Oldnewthing now looks like any bog-standard enterprise blog and not this 1998-looking trove of obscure knowledge that it used to be. But yes, Raymond Chen’s writing is as excellent as ever.

                                                                                                          1. 2

                                                                                                            I’m a bit sad too but otoh it looks as if the blog team at MSFT did a decent job migrating old content to the new platform. They’re trying to combat bitrot.

                                                                                                          1. 18

                                                                                                            It’s nice to see someone else abusing Python for the sake of fun. I’ve blogged in the past about many hacks, including: let, attempting to make call/cc, worlds, pattern matching with with, and dispatching with with. Basically, yes, yes, yes, more of this kind of stuff! It makes languages really fun.

                                                                                                            1. 6

                                                                                                              I’ll join this party :) I figured out how to make Rust-like macros in Python by stuffing things in type-annotations, which you can read here.

                                                                                                              1. 1

                                                                                                                I don’t write much Python these days, but as a Schemer interested in macros, I used to try out all sorts of stuff. There was one really good attempt: MetaPython which hasn’t had a release since 2009. I think that was the one I felt worked best, so if you’re still interested, you might play with it.

                                                                                                                Also, this is awesome! And, I don’t know much rust, but I did not realize that what I would call “pragmas” are powered by macros (in hindsight this makes total sense!), making them accessible for all sorts of hackery and wizardry. Thanks for sharing!

                                                                                                                1. 2

                                                                                                                  … but as a Schemer interested in macros

                                                                                                                  Do you know about Hy?

                                                                                                                  1. 1

                                                                                                                    I do! A long time ago I had a similar project called Ruse, which aimed to be a compliant Scheme on top of Python 2, which fizzled before I prepped it for release. I’m happy that someone else, independently, thought the idea of a Lisp targetting Python was good. :)

                                                                                                              2. 3

                                                                                                                It sounds like you’d enjoy my (now quite old) blog post about abusing encodings in Python: http://benjiyork.com/blog/2008/02/programmable-python-syntax-via-source.html

                                                                                                                1. 3

                                                                                                                  Thanks, that is amazing.

                                                                                                                  Very relatedly, I blogged about sourefiles using built in rot13 with a starting comment #encoding: rot13 that then have all Sourcecode encoded: https://frederik-braun.com/rot13-encoding-in-python.html

                                                                                                                2. 1

                                                                                                                  I think you might enjoy the complete works of Oleg Kiselyov, full of mind-bending trickery in Scheme, ML and others. I sometimes wish I could just set aside a year and thoroughly study and understand what Oleg is publishing.

                                                                                                                  1. 2

                                                                                                                    I sometimes wish I could just set aside a year and thoroughly study and understand what Oleg is publishing.

                                                                                                                    I sometimes ask the question, legitimately, “What would Oleg do?” – Yes, aware. But similar to you, completely understudied due to time.

                                                                                                                1. 3

                                                                                                                  The idea of a “bundle” und “unbundling content” is a very interesting one. I do sometimes miss the days of publications (be it print or any kind) where apart from the stuff that you are interested in is also a bunch of stuff you aren’t interested in yet but might discover real gems. I wonder what are the ways to recapture that kind of magic on the modern internet. The author mentions podcasts which I couldn’t ever get into, but maybe fellow Lobsters have some suggestions?

                                                                                                                  1. 2

                                                                                                                    I used to listen to a lot of the developer tea podcast in its early days, haven’t found time to listen to any podcasts in the past year or two so I don’t know if its still any good.

                                                                                                                    I liked the fact that I could fit two episodes in a bike ride to work.

                                                                                                                  1. 18

                                                                                                                    Java: Checked exceptions are a good idea, I’m so sorry everyone hates them in the only language that used them. Also, with Guava + Java 8, you can write pretty nice code. Won’t win on raw efficiency, but beats a lot of dynlangs handily. Primary use-case for the JVM, which is a delightful little VM for people to also write Kotlin, Scala, Clojure…

                                                                                                                    Python: All my Python complaints are contextual: it’s best-in-class for writing quick, readable, versatile code. One of the better communities for their scale.

                                                                                                                    Go: Prioritizing quick compile times and gofmt show a commitment to developer happiness that other languages would do well to emulate.

                                                                                                                    JavaScript: I love how all the data is more-or-less transparent, you can inspect any object and its properties, easy to printline-inspect/debug. Browser tools are some of the best the world has ever produced, available to everyone. One of the better “maps and objects are the same!!!” implementations (thinking of Python object slots, and/or some issues I ran into when trying to work with Lua).

                                                                                                                    This was a cute exercise, thank you! 😄

                                                                                                                    1. 3

                                                                                                                      Checked exceptions are a good idea, I’m so sorry everyone hates them in the only language that used them.

                                                                                                                      I sort of feel that algebraic effect will end up similar to checked exceptions (basically tracking effects like exceptions in the type system) hopefully without the annoyance that Java’s checked exceptions brought. Best of both worlds.

                                                                                                                      1. 6

                                                                                                                        I think the core failure of checked exceptions were that you couldn’t really do anything useful with the “list of checked exceptions potentially thrown” that the language gave to you.

                                                                                                                        One couldn’t really write a function that accepted a function with various checked exceptions, handle a specific exception, and receive a function back with the checked exceptions minus the one just handled.

                                                                                                                        In the end I think exceptions (regardless of checked or unchecked) are rather unnecessary – just use types.

                                                                                                                        1. 4

                                                                                                                          Checked exceptions are a use of types. I think the reason they get unweildy is people want to treat then like unchecked exceptions. If you have a long list of throws in your method signature then you are doing it wrong. Checked exceptions should be handled close to where they are thrown. You may want to wrap them in a new exception, but you probably don’t want to carry them all the way up. That is what an unchecked exception is for. I do think a better time system makes checked exceptions unnecessary.

                                                                                                                          1. 2

                                                                                                                            The big usability failure of Java’s checked exceptions, I think, is that you are forced to handle (or explicitly declare) them exactly one stack frame away from where they are thrown, whether it makes any sense in the context of the application code or not. You probably don’t want most checked exceptions to silently bubble 20 layers up the call stack, but, say, 3 layers can make complete sense depending on what the intermediate layers are.

                                                                                                                            1. 3

                                                                                                                              I think that usability failure is because of the checked exception is being thrown at the wrong layer. Checked Exceptions should be viewed as a second return type that you are required to handle. Unchecked exceptions should be treated like a panic. This means careful consideration of exceptions in your API.

                                                                                                                              Where people go wrong I think is that they pretend like the exception they throw can be treated as separate from their API. This results in a lot of miscommunication and confusion. Docs hide the exceptions that get thrown from you. Some people think you should never catch an exception. Some people think you should always catch an exception. At least checked exceptions give you a way to distinguish between the exceptions you expect the caller to do something with and the exceptions that you expect the caller to ignore.

                                                                                                                          2. 3

                                                                                                                            Yes, the make or break issue I see is composability. We will see how that will play out.

                                                                                                                            We do use result types in OCaml at work but the problem is the composability of the type representing the failure. For once, you can’t really force all 3rd party libraries to use the same representation, thus leaving you to write wrappers to convert from the provided behaviour to that you want to have. The other issue is that even then then, how to join multiple error types from different functions is difficult. If you represent it as ADT you can’t easily join constructors A | B with C | D without defining a boilerplat-y new type. If you use open types like polymorphic variants you can easily get code that over or underestimates the set of error types and it doesn’t support shrinking the set of variants (as you mention above, a pretty important feature).

                                                                                                                          3. 1

                                                                                                                            I am reminded of the Vexing Exceptions blog post.

                                                                                                                            Summary: Exogenous exceptions are the reason why checked exceptions exist. Vexing exceptions are the reason why everyone hates checked exceptions.

                                                                                                                            Exogenous exceptions represent the messy external realities that impinge on our nice clean code. It’s good to force developers to do something somewhere about them.

                                                                                                                            Vexing exceptions are sort-of ridiculous use of exceptions to handle non-exceptional situations that commonly happen, especially in standard library code. It’s super annoying that there’s so much boilerplate around things that should be handled in a simpler way.

                                                                                                                        1. 1

                                                                                                                          Don’t we have the same problem on lobste.rs? A rating of -20 not really common around here but technically certainly possible. Maybe it would make sense to cap the negative level to somewhere?

                                                                                                                          1. 3

                                                                                                                            On lobsters at least, I think a better idea would be to ask the downvoter to explain their reasoning in a comment private to the post. On the other hand, the current system of simply choosing a reason to downvote seems to work well. I rarely see downvotes here.

                                                                                                                            1. 3

                                                                                                                              The fact that new comments don’t show their score until they’ve aged out a bit helps a lot. I’d say the effect is still present but greatly reduced in impact.

                                                                                                                              1. 1

                                                                                                                                I always thought the down-vote concept a bit flawed as it is too easy to abuse.

                                                                                                                                Better not to have down-vote button imho.

                                                                                                                                It raises the bar for the use-case, so that the person wishing to down-vote and the original comment writer engage in a discussion instead; which seems healthy.

                                                                                                                                1. 1

                                                                                                                                  TBH the few times I used downvote I didn’t really check if it was already at some low number.

                                                                                                                                  /runs off to go look up if own downvotes are shown somewhere

                                                                                                                                1. 4

                                                                                                                                  Kill it with fire.

                                                                                                                                  1. 3

                                                                                                                                    Might help to say why.

                                                                                                                                    1. 9

                                                                                                                                      Wait, so you’re gonna make me explain myself? How dare you! ;-P

                                                                                                                                      Just kidding.

                                                                                                                                      Now that llvm is becoming more and more mature, I’d love for the entirety of the OS to be self-hosted with llvm across all supported architectures. FreeBSD has a mechanism for an “external compiler toolchain”–meaning, a compiler toolchain installed via ports/pkg (or otherwise).

                                                                                                                                      FreeBSD will need to continue with the notion of an external toolchain at least until llvm gains support for those architectures where an external toolchain is already required. Regardless of llvm’s architectural support (or lack thereof), having a notion of an external toolchain allows toolchain developers to experiment on the OS from a compiler perspective from outside the actual OS source code tree–especially important for OSes like the BSDs that keep a notion of a basic userland tightly coupled with the kernel.

                                                                                                                                      This is all background info to say: there is really no need for gcc in base, especially given the existing capability to rely on an external toolchain when needed. Therefore: kill gcc with fire.

                                                                                                                                      1. 8

                                                                                                                                        Basically GCC is fine, GCC 4.2.1 that’s been obsolete for a decade isn’t.

                                                                                                                                        1. 6

                                                                                                                                          GCC 4.2.1 is the last gcc under GPLv2, all newer versions are GPLv3. That’s why most BSD’s stayed on 4.2.1 until clang/llvm became the compiler of choice.

                                                                                                                                          1. 2

                                                                                                                                            I should’ve prefaced my response to say that my beliefs don’t necessarily reflect those of the FreeBSD project’s. From someone on the outside who has been paying attention, it just seems natural to retire gcc 4.2.1 in base in favor of the external toolchain capability.

                                                                                                                                            1. 1

                                                                                                                                              No worries, just adding a bit of clarification.

                                                                                                                                          2. 0

                                                                                                                                            So, anyone want to speculate how GPL lost the mindshare war here?

                                                                                                                                            If GCC were good, people would use it. And GPL would have a foothold.

                                                                                                                                            Clang being BSD = major blow to GPL.

                                                                                                                                            1. 8

                                                                                                                                              BSD people like to use software with BSD licenses?

                                                                                                                                              1. 4

                                                                                                                                                GCC was good. People did use it. And then Apple poured incredible resources into Clang so they could exert more control over their platform, resulting in Clang becoming a viable alternative to GCC.

                                                                                                                                                1. 3

                                                                                                                                                  I agree, and GCC was also the compiler who has basically killed an industry of crappy proprietary vendor C compilers by supporting C reasonably well and generating code for all kinds of platforms.

                                                                                                                                                  That said, the competition from Clang was a very good thing for GCC as well. So in the end, everybody is better off: both GCC for improving due to pressure from Clang and the BSDs for finally having a compiler with a license they like.