1. 1

    There seems to be a belief amongst memory safety advocates that it is not one out of many ways in which software can fail, but the most critical ones in existance today, and that, if programmers can’t be convinced to switch languages, maybe management can be made to force them.

    I didn’t see this kind of zeal when (for example) PHP software fell pray to SQL injections left and right, but I’m trying to understand it. The quoted statistics about found vulnerabilities seem unconvincing, and are just as likely to indicate that static analysis tools have made these kind of programming errors easy to find in existing codebases.

    1. 19

      Not all vulnerabilities are equal. I prioritize those that give attackers full control over my computer. They’re the worst. They can lead to every other problem. Plus, their rootkits or damage might not let you have it back. You can lose the physical property, too. Alex’s field evidence shows memory unsafety causes around 70-80% of this. So, worrying about hackers hitting native code, it’s rational to spend 70-80% of one’s effort eliminating memory unsafety.

      More damning is that languages such as Go and D make it easy to write high-performance, maintainable code that’s also memory safe. Go is easier to learn with a huge ecosystem behind it, too. Ancient Java being 10-15x slower than C++ made for a good reason not to use it. Now, most apps are bloated/slow, the market uses them anyway, some safe languages are really lean/fast, using them brings those advantages, and so there’s little reason left for memory-unsafe languages. Even in intended use cases, one can often use a mix of memory-safe and -unsafe languages with unsafe used on performance-sensitive or lowest-level parts of the system. Moreover, safer languages such as Ada and Rust give you guarantees by default on much of that code allowing you to selectively turn them off only where necessary.

      If using unsafe languages and having money, there’s also tools that automatically eliminate most of the memory unsafety bugs. That companies pulling in 8-9 digits still have piles of them show total negligence. Same with those in open-source development who aren’t doing much better. So, on that side of things, whatever tool you encourage should lead to memory safety even with apathetic, incompetent, or rushed developers working on code with complex interactions. Double true if it’s multi-threaded and/or distributed. Safe, orderly-by-default setup will prevent loads of inevitable problems.

      1. 13

        The quoted statistics about found vulnerabilities seem unconvincing

        If studies by security teams at Microsoft and Google, and analysis of Apple’s software is not enough for you, then I don’t know what else could convince you.

        These companies have huge incentives to prevent exploitable vulnerabilities in their software. They get the best developers they can, they are pouring many millions of dollars into preventing these kinds of bugs, and still regularly ship software with vulnerabilities caused by memory unsafety.

        “Why bother with one class of bugs, if another class of bugs exists too” position is not conductive to writing secure software.

        1. 3

          “Why bother with one class of bugs, if another class of bugs exists too” position is not conductive to writing secure software.

          No - but neither is pretending that you can eliminate a whole class of bugs for free. Memory safe languages are free of bugs caused by memory unsafety - but at what cost?

          What other classes of bugs do they make more likely? What is the development cost? Or the runtime performance cost?

          I don’t claim to have the answers but a study that did is the sort of thing that would convince me. Do you know of any published research like this?

          1. 9

            No - but neither is pretending that you can eliminate a whole class of bugs for free. Memory safe languages are free of bugs caused by memory unsafety - but at what cost?

            What other classes of bugs do they make more likely? What is the development cost? Or the runtime performance cost?

            The principle cost of memory safety in Rust, IMO, is that the set of valid programs is more heavily constrained. You often here this manifest as “fighting with the borrow checker.” This is definitely an impediment. I think a large portion of folks get past this stage, in the sense that “fighting the borrow checker” is, for the most part, a temporary hurdle. But there are undoubtedly certain classes of programs that Rust will make harder to write, even for Rust experts.

            Like all trade offs, the hope is that the juice is worth the squeeze. That’s why there has been a lot of effort in making Rust easier to use, and a lot of effort put into returning good error messages.

            I don’t claim to have the answers but a study that did is the sort of thing that would convince me. Do you know of any published research like this?

            I’ve seen people ask this before, and my response is always, “what hypothetical study would actually convince you?” If you think about it, it is startlingly difficult to do such a study. There are many variables to control for, and I don’t see how to control for all of them.

            IMO, the most effective way to show this is probably to reason about vulnerabilities due to memory safety in aggregate. But to do that, you need a large corpus of software written in Rust that is also widely used. But even this methodology is not without its flaws.

            1. 2

              If you think about it, it is startlingly difficult to do such a study. There are many variables to control for, and I don’t see how to control for all of them.

              That’s true - but my comment was in response to one claiming that the bug surveys published by Microsoft et al should be convincing.

              I could imagine something similar being done with large Rust code bases in a few years, perhaps.

              I don’t have enough Rust experience to have a good intuition on this so the following is just an example. I have lots of C++ experience with large code bases that have been maintained over many years by large teams. I believe that C++ makes it harder to write correct software: not (just) because of memory safety issues, undefined behavior etc. but also because the language is so large, complex and surprising. It is possible to write good C++ but it is hard to maintain it over time. For that reason, I have usually promoted C rather than C++ where there has been a choice.

              That was a bit long-winded but the point I was trying to make is that languages can encourage or discourage different classes of bugs. C and C++ have the same memory safety and undefined behavior issues but one is more likely than the other to engender other bugs.

              It is possible that Rust is like C++, i.e. that its complexity encourages other bugs even as its borrow checker prevents memory safety bugs. (I am not now saying that is true, just raising the possibility.)

              This sort of consideration does not seem to come up very often when people claim that Rust is obviously better than C for operating systems, for example. I would love to read an article that takes this sort of thing into account - written by someone with more relevant experience than me!

              1. 7

                I’ve been writing Rust for over 4 years (after more than a decade of C), and in my experience:

                • For me Rust has completely eliminated memory unsafety bugs. I don’t even use debuggers or Valgrind any more, unless I’m integrating Rust with C.
                • I used to have, at least during development, all kinds of bugs that spray the heap, corrupt some data somewhere, use uninitialized memory, use-after-free. Now I get compile-time errors or panics (which are safe, technically like C++ exceptions).
                • I get fewer bugs overall. Lack of NULL and mandatory error handling are amazing for reliability.
                • Built-in unit test framework, richer standard library and easy access to 3rd party dependencies help too (e.g. instead of hand-rolling another own buggy hash table, I use a well-tested well-optimized one).
                • My Rust programs are much faster. Single-threaded Rust is 95% as fast as single-threaded C, but I can easily parallelize way more than I’d ever dare in C.

                The costs:

                • Rust’s compile times are not nice.
                • It took me a while to become productive in Rust. “Getting” ownership requires unlearning C and a lot of practice. However, I’m not fighting the borrow checker any more, and I’m more productive in Rust thanks to higher-level abstractions (e.g. I can write map/reduce iterator that collects something into a btree — in 1 line).
          2. 0

            Of course older software, mostly written in memory-unsafe languages, sometimes written in a time when not every device was connected to a network, contains more known memory vulnerabilities. Especially when it’s maintained and audited by companies with excellent security teams.

            These statistics don’t say much at all about the overall state of our software landscape. It doesn’t say anything about the relative quality of memory-unsafe codebases versus memory-safe codebases. It also doesn’t say anything about the relative sizes of memory-safe and memory-unsafe codebases on the internet.

            1. 10

              iOS and Android aren’t “older software”. They’ve been born to be networked, and supposedly secure, from the start.

              Memory-safe codebases have 0% memory-unsafety vulnerabilities, so that is easily comparable. For example, check out the CVE database. Even within one project — Android — you can easily see whether the C or the Java layers are responsible for the vulnerabilities (spoiler: it’s C, by far). There’s a ton of data on all of this.

              1. 2

                Android is largely cobbled together from older software, as is IOS. I think Android still needs a Fortran compiler to build some dependencies.

                1. 9

                  That starts to look like a No True Scotsman. When real-world C codebases have vulnerabilities, they’re somehow not proper C codebases. Even when they’re part of flagship products of top software companies.

                  1. 2

                    I’m actually not arguing that good programmers are able to write memory-safe code in unsafe languages. I’m arguing vulnerabilities happen at all levels in programming, and that, while memory safety bugs are terrible, there are common classes of bugs in more widely used (and more importantly, more widely deployed languages), that make it just one class of bugs out of many.

                    When XSS attacks became common, we didn’t implore VPs to abandon Javascript.

                    We’d have reached some sort of conclusion earlier if you’d argued with the point I was making rather than with the point you wanted me to make.

                    1. 4

                      When XSS attacks became common, we didn’t implore VPs to abandon Javascript.

                      Actually did. Sites/companies that solved XSS did so by banning generation of markup “by hand”, and instead mandated use of safe-by-default template engines (e.g. JSX). Same with SQL injection: years of saying “be careful, remember to escape” didn’t work, and “always use prepared statements” worked.

                      These classes of bugs are prevalent only where developers think they’re not a problem (e.g. they’ve been always writing pure PHP, and will continue to write pure PHP forever, because there’s nothing wrong with it, apart from the XSS and SQLi, which are a force of nature and can’t be avoided).

                      1. 1

                        This kind of makes me think of someone hearing others talk about trying to lower the murder rate and then hysterically going into a rant about how murder is only one class of crime

                        1. -1

                          I think a better analogy is campaigning aggressively to ban automatic rifles when the vast majority of murders are committed using handguns.

                          Yes, automatic rifles are terrible. But pointing them out as the main culprit behind the high murder rate is also incorrect.

                          1. 4

                            That analogy is really terrible and absolutely not fitting the context here. It’s also very skewed, the murder rate is not the reason for calls for bans.

                      2. 2

                        Although I mostly agree, I’ll note Android was originally built by a small business acquired by Google that continued to work on it probably with extra resources from Google. That makes me picture a move fast and break things kind of operation that was probably throwing pre-existing stuff together with their own as quickly as possible to get the job done (aka working phones, market share).

                    2. 0

                      Yes, if you zoom in on code bases written in memory-unsafe languages, you unsurprisingly get a large number of memory-unsafety vulnerabilities.

                      1. 12

                        And that’s exactly what illustrates “eliminates a class of bugs”. We’re not saying that we’ll end up in utopia. We just don’t need that class of bugs anymore.

                        1. 1

                          Correct, but the author is arguing that this is an exceptionally grievous class of security bugs, and (in another article) that developers’ judgement should not be trusted on this matter.

                          Today, the vast majority of new code is written for a platform where execution of untrusted memory-safe code is a core feature, and the safety of that platform relies on a stack of sandboxes written mostly in C++ (browser) and Objective C/C++/C (system libraries and kernel)

                          Replacing that stack completely is going to be a multi-decade effort, and the biggest players in the industry are just starting to dip their toes in memory-safe languages.

                          What purpose does it serve to talk about this problem as if it were an urgent crisis?

                          1. 10

                            Replacing that stack completely is going to be a multi-decade effort, and the biggest players in the industry are just starting to dip their toes in memory-safe languages.

                            Hm, so. Apple has developed Swift, which is generally considered a systems programming language, to replace Objective-C, which was their main programming language and already had safety features like baked in ARC. Google has implemented Go. Mozilla Rust. Google uses tons of Rust in Fuchsia and has recently imported the Rust compiler into the Android source tree.

                            Microsoft has recently been blogging about Rust quite a lot and is often seen hanging around and blogs about how severe memory problems are to their safety story. Before that, Microsoft has spent tons of engineering effort into Haskell as a research base and C#/.Net as a replacement for their C/C++ APIs.

                            Amazon has implemented firecracker in Rust and bragged about it on their AWS keynote.

                            Come again about “dipping toes”? Yes, there’s huge amounts of stack around, but there’s also huge amounts to be written!

                            What purpose does it serve to talk about this problem as if it were an urgent crisis?

                            Because it’s always been a crisis and now we have the tech to fix it.

                            P.S.: In case this felt a bit like bragging Rust over the others: it’s just where I’m most aware of things happening. Go and Swift are doing fine, I just don’t follow as much.

                            1. 2

                              The same argument was made for Java, which on top of its memory safety, was presented as a pry bar against the nearly complete market dominance of the Wintel platform at the time. Java evangelism managed to convert new programmers - and universities - to Java, but not the entire world.

                              Oracle’s deadly embrace of Java didn’t move it to rewrite its main cash cow in Java.

                              Rust evangelists should ask themselves why.

                              I think that of all the memory-safe languages, Microsoft’s C++/CLI effort comes closest to understanding what needs to be done to entice coders to move their software into a memory-safe environment.

                              At my day job, I actually try to spend my discretionary time trying to move our existing codebase to a memory-safe language. It’s mostly about moving the pieces into place so that green-field software can seamlessly communicate with our existing infrastructure. Then seeing what parts of our networking code can be replaced, slowly reinforcing the outer layers while the inner core remains memory unsafe.

                              Delicate stuff, not something you want the VP of Engineering to issue edicts about. In the meantime, I’m still a C++ programmer, and I really don’t appreciate this kind of article painting a big target on my back.

                              1. 4

                                Java and Rust are vastly different ball parks for what you describe. And yet, Java is used successfully in the database world, so it is definitely to be considered. The whole search engine database world is full of Java stacks.

                                Oracle didn’t rewrite its cashcow, because - yes, they are risk-averse and that’s reasonable. That’s no statement on the tech they write it in. But they did write tons of Java stacks around Oracle DB.

                                It’s an argument on the level of “Why isn’t everything at Google Go now?” or “Why isn’t Apple using Swift for everything?”.

                                1. 2

                                  Looking at https://news.ycombinator.com/item?id=18442941 it seems that it was too late for a rewrite when Java matured.

                              2. 8

                                What purpose does it serve to talk about this problem as if it were an urgent crisis?

                                To start the multi-decade effort now, and not spend more decades just saying that buffer overflows are fine, or that—despite of 40 years of evidence to the contrary—programmers can just avoid causing them.

                    3. 9

                      I didn’t see this kind of zeal when (for example) PHP software fell pray to SQL injections left and right

                      You didn’t? SQL injections are still #1 in the OWASP top 10. PHP had to retrain an entire generation of engineers to use mysql_real_escape_string over vulnerable alternatives. I could go on…

                      I think we have internalized arguments the SQL injection but have still not accepted memory safety arguments.

                      1. 3

                        I remember arguments being presented to other programmers. This article (and another one I remembered, which, as it turns out, is written by the same author: https://www.vice.com/en_us/article/a3mgxb/the-internet-has-a-huge-cc-problem-and-developers-dont-want-to-deal-with-it ) explicitly target the layperson.

                        The articles use the language of whistleblowers. It suggests that counter-arguments are made in bad faith, that developers are trying to hide this ‘dirty secret’. Consider that C/C++ programmers skew older, have less rosy employment prospects, and that this article feeds nicely into the ageist prejudices already present in our industry.

                        Arguments aimed at programmers, like this one at least acknowledge the counter-arguments, and frame the discussion as one of industry maturity, which I think is correct.

                        1. 2

                          I do not see it as bad faith. There are a non-zero number of people who say they can write memory safe C++ despite there being a massive amount of evidence that even the best programmers get tripped up by UB and threads.

                          1. 1

                            Consider that C/C++ programmers skew older, have less rosy employment prospects, and that this article feeds nicely into the ageist prejudices already present in our industry.

                            There’s an argument to be made that the resurging interest in systems programming languages through Rust, Swift and Go futureproofs experience in those areas.

                        2. 5

                          Memory safety advocate here. It is the most pressing issue because it invokes undefined behavior. At that point, your program is entirely meaningless and might do anything. Security issues can still be introduced without memory unsafety of course, but you can at least reason about them, determine the scope of impact, etc.

                        1. 3

                          I think PHP has lost its identity. I think P++ only muddies the waters more. The problems that PHP was originally meant to solve are now minor issues. The PHP team needs to decide on what niche or market they want to target and then go after it. They have spent years trying to be a little bit of everything but not the best at anything.

                          1. 5

                            Surprisingly, no mention of Hack.

                            1. 3

                              Yeah that is interesting. I think Hack dropped support for some popular frameworks awhile ago, hence dropping PHP compatibility.

                              I’m neither a PHP or Hack developer, but from the outside it looks like the two groups had diverging interests and couldn’t work together. Not saying that’s good or bad.

                              I did think Hack was a good idea, i.e. to rescue a bad but useful language, but I guess there is more than one way to do it.

                              1. 7

                                I think this is a bad idea because it’s worse for beginners. It’s also self-serving to the Twisted community that has felt spurned for a long time. We’re optimizing for the future Python programmers who will far out number us, and “batteries included” is the way to do that.

                                1. 3

                                  Why is it self serving to the Twisted community?

                                  1. 6

                                    Because they want asyncio removed from the standard library because it competes with Twisted. Some more context here: http://pyfound.blogspot.com/2019/05/amber-brown-batteries-included-but.html

                                    1. 3

                                      Because they want asyncio removed from the standard library because it competes with Twisted.

                                      I think that’s a very uncharitable reading of the situation. The suggestion is that much of the standard library become third-party on PyPI, not that the modules be eliminated altogether. And the reasoning is pretty sound: it’s an absolute pain to know that something was just added to the Python standard library but you can’t use it because it’ll be at least half a decade until enough users have migrated to a version of Python that has it. If the modules were on PyPI, you’d just tweak the version in your own dependency declaration and be able to rely on it same-day.

                                      1. 1

                                        Your comment doesn’t make sense to me. Can you clarify? Is “half a decade” a reference to Python 3? There were backports to 2 (https://pypi.org/project/trollius/). Yield from wasn’t in Python until 3.3, and there was a separate package for that version (https://pypi.org/project/asyncio/). What makes asyncio feel good is async and await which didn’t arrive until 3.5, and that’s syntax that you can’t install as a module.

                                        We’re trying to optimize for new programmers, and the last thing they should be learning about is package management. It’s hard enough to just learn the language and become productive.

                                        1. 1

                                          A given Python release series (like 3.7.x) tends to have a support lifetime of around five years from the Python core team. And your installed base as an application developer is going to include a lot of corporate users who standardize on a version and ride it until upstream support ends (or even longer). Since you can’t count on people doing timely upgrades of their Python interpreter + stdlib, you can’t count on them being able to use anything that depends on more recent Python features.

                                          We’re trying to optimize for new programmers, and the last thing they should be learning about is package management.

                                          Unless you’re giving them a custom distribution of Python that also includes Flask, Django, the full numpy/scipy stack, Jupyter, ML/AI libraries and game toolkits in a single install, they’re going to have to learn how to type pip install at some point in order to be productive beyond the intro to the language.

                                          And being a consumer of Python packages is not particularly difficult these days, because it really is just pip install. The variation in toolchains and techniques is almost all on the producer side of packaging, and is mostly invisible to people who just want to install and use unless we scare them off by inaccurately telling them there are dozens of competing options.

                                          1. 2

                                            I think you’re conflating corporate users of Python with beginners. The point here is that we’re trying to delay the need to install any extra Python packages for as long as possible to maximize proficiency before users have to learn a second tool (pip in this case). If the standard library is empty then beginners have two problems to confront in order to learn the language. It’s a really simple concept.

                                            1. 1

                                              Nobody’s saying there should be no standard library. Several people are suggesting a much smaller standard library that contains only the really essential things, and move the rest to PyPI.

                                              You can still teach beginners how to write functions and classes and do things with just the language itself and zero import statements. And like I said, at some point if they want to write anything non-trivial either you need to be providing a bundled installer that has extra stuff in it, or they need to learn to run pip install.

                                              1. 1

                                                os, io, pdb, unittest, functools.wraps, collections, socket, … – all of these should be in PyPI? My advice would be to switch to JavaScript and npm if that’s what you want. With Python: “There should be one– and preferably only one –obvious way to do it.”

                                                1. 2

                                                  I keep telling you what people are actually proposing. You keep refusing to engage with that and instead setting up straw men you can knock down. So I’m not going to spend any more time on this.

                                  2. 1

                                    Are there links on how you are going about this?

                                    1. 4

                                      This post from one of the core devs covers it pretty well I think:

                                      https://snarky.ca/why-python-3-exists/

                                      1. 2

                                        Thank you for the link. This did not cover anything about the standard library, but it was helpful to get the perspective on Python 3.

                                        So expect Python 4 to not do anything more drastic than to remove maybe deprecated modules from the standard library.

                                        When I got to this line it became clear to me that the Twisted community and Python core devs are talking past each other.

                                        1. 2

                                          There is now a draft PEP suggesting that Python deprecate and remove some of the “dead batteries” in the standard library. There’s no reason, in 2019, for every Python user on earth to devote bandwidth to download, and disk space to storing, copies of a module for working with the audio files from 1990s Sun workstations (to take one egregious example of something that’s in the standard library with no real right to be).

                                  1. 13

                                    I think being T shaped is best. Learn the basics of most things and find a few things to be an expert in.

                                    1. 4

                                      T-shaped would be an expert in one thing. For a few things you would be π-shaped or m-shaped.

                                      I would rather suggest ⌶-shaped: Broad shallow overview. Expert in one thing. Good general fundamentals.

                                      1. 1

                                        I agree; having the depth in a few key technologies allows you to more effectively evaluate new technologies, too. Most blog posts and tutorials completely oversell new technologies, but with some experience in related technologies you’ll quickly be able to intuit (or test for) pitfalls when evaluating a new tool. That’s much better than running into issues in production and then having to scramble to work around deficiencies.

                                        1. 5

                                          This is a great example of a light-weight knowledge base for how to do something. I am increasingly of the opinion that a big reason why these types of efforts fail is due to the friction in the process. By “types” I mean efforts such as a knowledge base, service level mapping, ticket/issue management, etc. The rise and success of the wiki is due to the fact that it makes it easy to contribute. The downside of the wiki is that it lacks structure and the content grows stale.

                                          This example from etsy adds a little more structure to “how-docs” than a wiki by keeping a topical, reverse ordered list of answers. The friction to contribute is about the same as a wiki or maybe even less for those people who are comfortable on a command line.

                                          1. 1

                                            Totally agree. I love the concept of wikis but they need some kind of automation to identify stale content. Runnable pages (like Jupyter notebooks) and block-based pages like Notion would be two key features to achieve that, I would say. Do you have any opinion on how wikis could be improved for code documentation?

                                          1. 4

                                            I love this post because its radical. It points out correctly that the view modifies the model correctly. People often mistakenly delegate that to the controller. Only purpose of the control is to orchestrate views. However I wish he went into more of Trygve’s latest work with DCI.

                                            1. 2

                                              This is mostly due to the way web frameworks work. The router goes to a controller which can update the model.

                                              Newer frameworks are starting to have a router call a function, which seems to bring us a bit closer to the original MVC pattern.

                                            1. 10

                                              This might be a stupid question, but why not less instead of cat? Cat is not really meant to display files but to concatenate them. I’d definitely like a better pager, but neither w3m or vi in view mode worked for me, so i’m still using less

                                              1. 5

                                                Cat is still cat. Bat is like the kitchen sink that just clobbers more? Yeah, I don’t quite understand why this tool is positioning itself relative to cat.

                                                It is definitely not a clone. But I am all for new, more usable terminal based tools that use what we have at our disposal, more cores, more ram, ssd read/write.

                                                I’d really like a tool that built an n-gram inverted index of all files below my current dir and allowed me to jump to anything, that showed similar token/phrases/lines, etc. All terminal driven, with an option to load a rich GUI over a local http connection.

                                                1. 3

                                                  Although I agree with you, I can see why this would be positioned as an alternative to cat.

                                                  Quite a lot of people use cat to preview files, and that’s what bat does. I know less and more exist, but for some reason I still find myself using cat. Perhaps other people do the same.

                                                  1. 4

                                                    I use cat because, if I’m lucky, the output will fit in my terminal, and I’m ready for my next command; with a pager, I need to press a key to exit out of the pager before I can issue my next command, and the output disappears (in the case of less) as if the pager never ran, so I can’t keep context around.

                                                    1. 11

                                                      By the way, less can be configured to act well in these circumstances. I have more as an alias for less -FX. Those two options to less are:

                                                             -F or --quit-if-one-screen
                                                                    Causes less to automatically exit if the entire file can be displayed on the first screen.
                                                             -X or --no-init
                                                                    Disables sending the termcap initialization and deinitialization strings to the terminal.  This is sometimes desirable if the deinitialization string does something unnecessary, like clearing the screen.
                                                      

                                                      I also define $PAGER to be less -FX, so manpages and the like don’t clear the screen once the pager quits.

                                                      1. 5

                                                        I second this. -c would be helpful in $PAGER as well so that everything above on your screen stays untouched.

                                                        Personally, I’ve been rolling with this:

                                                        $ type le
                                                        le is an alias for 'less -FcmNqX --follow-name'
                                                        
                                                      2. 2

                                                        the output disappears (in the case of less) as if the pager never ran, so I can’t keep context around.

                                                        If you want to get rid of this sort of behaviour globally, disable “alternate screen” in your terminal.

                                                        In tmux, set-window-option -g alternate-screen off. In putty there’s Disable switching to alternate terminal screen under Terminal → Features.

                                                        1. 1

                                                          Just tested bat, and the output doesn’t disappear. When you need a specific section from a file (not the whole thing) - using bat over cat and not less makes sense. Neat.

                                                      3. 2

                                                        Bat will act like cat if it determines there is no tty. Thus, bat is like less when used interactive and like cat when scripting.

                                                        Like someone else said, people use cat to dump contents to the terminal so they can refer to it while continuing work.

                                                        1. 2

                                                          Proof!

                                                          Oh.. you can also use it to concatenate files 😉. Whenever bat detects a non-interactive terminal, it will fall back to printing the plain file contents.

                                                      1. 3

                                                        I use the ORM for create, update and delete. I usually write raw sql for reads. Good ORMs also provide migrations and other ways to manage the database and schema.

                                                        I have been in situations where the database is managed independently of the ORM. In that case, I have found a lot less value in an ORM.

                                                        1. 8

                                                          I like https://darksky.net/app for the weather.

                                                          1. 2

                                                            I find WeatherLine to be pretty good too.

                                                          1. 1

                                                            It is great to see more open source stuff for iOS.

                                                            1. 3

                                                              I don’t find this argument very convincing.

                                                              It seems that the author’s primary complaint is that no alternative suggestion is provided. I don’t think that that’s relevant at all.

                                                              Secondarily,

                                                              ways that involve the three areas of ethics, metaphysics, and epistemology—he gives not a single example of a question that those disciplines have answered.

                                                              Again, that’s not the point of this article, which is to critique scientism.

                                                              1. 3

                                                                This harkens to the idea that one cannot complain unless they have a solution. I think it was good that Hughes did not provide a solution. If he did, this author would have been unable to restrain himself from focusing on the solution instead of addressing the criticisms Hughes has about scientism.

                                                              1. 1

                                                                My biggest problem with visual tools is that they do not understand my intent. Text-based programming is capturing my intent because I am telling the computer exactly what to do. With visual tools, a layer is trying to translate my clicking and positioning into code. This works great 80% of the time, but that 20% of the time where the tool cannot adequately capture my intent removes most of the benefit from using the tool in the first place.