1. 2

    As someone working a lot with logs and traces, lnav is a freaking lifesaver.

    1. 3

      I used to work with the inventor of that and everybody at the company used it. Very smart dude.

      1.  

        Have you tried if https://github.com/akavel/up might also be useful to you?

      1. 3

        @lenormf could you please fix the github links in the article to make them permalinks, instead of pointing to the master branch? You can press y key on most pages on github, to make github replace master in the URL to a proper commit hash - that way you can have links that won’t bit-rot in a few weeks/months.

        1. 1

          Thanks for the feedback, that’s helpful. I’ve updated the links to have them point to code from the latest release (v2020.09.01).

        1. 20

          I am a big fan of having a paper notebook and a nice, hefty, metal pen. The ability to rapidly intermix text, drawings, and sketches is underrated.

          EDIT: For the record, I really like Machine Era pens. Solid metal and made in the USA, with easily refillable ink cartridges.

          1. 4

            After trying multiple systems on my laptop or smartphone, I always fall back to my notebooks and a foutain pen. The only thing that I miss is a way to easily record some url or reference. I thought about creating my own url shortener or find a mini printer to print sticker with QR code.

            Intermixing different kinds of inputs (text,drawings,sketches,ddiagrams) is the really what I miss the most when I tried any numeric system.

            1. 1

              I recently had the same idea about a link shortener and so I made one! It doesn’t have much in the way of documentation but it was literally a two hour project and it’s only 50 lines of Go so I think you should be able to get it running really quickly. It uses autoincrementing numbers so the links are always very short and easy to write down (also spell out to someone, remember etc.) I hope you find it useful! Here’s the repo: https://github.com/k2l8m11n2/s

              1. 1

                That’s nice ! What kind of input method do you use? Sending HTTP request via a web interface or CLI? I will definitely look at it longer, thanks!

                1. 1

                  The interface is the simplest one I could think of: you GET (or just enter in your browser) https://shortener.example.com/https://some-cool-link.example.net/fun-link-stuff and you get back a number (starting with 1) that you use like so: https://shortener.example.com/1 which redirects you to https://some-cool-link.example.net/fun-link-stuff! I hope this example was clear enough, feel free to ask if you have any questions.

            2. 4

              I like rotring pens.

              1. 1

                Have you ever had a problem with them leaking? My partner uses those, as the line quality is beautiful but after a while, every one she has had has started to leak and needs to be cleaned out.

                1. 1

                  No, I haven’t had trouble with mine leaking. I mostly use the ball point pen though. Nothing fancy.

              2. 3

                In some previous variant of a similar thread, one fellow lobster got me addicted to discbound notebooks [1] [2] [3]. I heartily recommend checking them out for anyone using paper for work notes. They’re an absolutely ingenious invention, I’m surprised they’re not better known and more popular. I mean, I don’t guarantee they’ll fix all your life problems and smooth your wrinkles, but they have many benefits with not many flaws, and I think everyone should know they exist, so that they can choose them as a tool at will.

                1. 3

                  If you like hefty metal pens, but European ones, I cannot recommend enough Caran d’Ache: https://www.carandache.com/us/en/ballpoint-pen/849-popline-metallic-black-ballpoint-pen-with-holder-p-10214.htm

                  This kind of pen can go a long way.

                  1. 5

                    So once upon a time I spoke French reasonably well and I was trying to translate “Caran d’Ache” and now I have a headache. Turns out it’s actually a French-ish spelling of a Russian version of a Turkish word.

                    1. 4

                      Yes! Even for native French speakers, it feels very French, except Caran doesn’t mean anything (Ache could be a city or whatever).

                      Fore those wondering the meaning:

                      Caran d’Ache means pencil in Russian and has its roots in the Turkish word “kara-tash” which means black stone, in reference to graphite.

                      https://www.carandache.com/us/en/content/ch/fr/la_maison/landing/la_maison_-_histoire.cfm

                      1. 7

                        Caran d’Ache means pencil in Russian and has its roots in the Turkish word “kara-tash” which means black stone, in reference to graphite.

                        Interestingly, I come from a country where fountain pen are mandatory in school. We speak arabic, and everyone called the fountain pen “cartouch”, which means bullet or cartridge. It’s also funny because the cartridge really looks like a bullet. There’s also a close relation with lead. I thought it was an anglicism but now I’m learning it might actually comes from the ottoman era.
                        Language is fun.

                        1. 1

                          Interestingly enough, in French cartridge is also called “cartouche” which is very similar!

                          I’ve tried to find more on the source of the work, but the best I could find was:

                          Borrowed from Italian cartuccia, a diminutive of carta, from Latin charta, from Ancient Greek χάρτης (khártēs) — https://en.wiktionary.org/wiki/cartouche

                          Which is related to the paper that was used for cartridges (in firearms).

                          I wonder what’s the link with pens beside the ink cartridge…

                        2. 2

                          A “Crayon of ash” perhaps?

                        3. 2

                          Oh, right. Карандаш. But it means pencil, so it’s a little bit weird. Does French pronunciation has anything to do with the Russian one? :D

                          1. 2

                            I decided to leam the Cyrillic alphabet a while back because I noticed there are a lot of shared/borrowed French words in Russian and I was going on a visit to Russia. It was really handy. I know a little French, and no Russian, but I could actually read a lot of words on signs. I got the notion from ресторан = restaurant.

                      2. 1

                        What type of paper do you use? Ruled? Grid? Some of my physicist coworkers use a dotted grid-style that I’ve been thinking of trying out

                        1. 4

                          I use a dot-grid notebook for a daily bullet journal and all my notes. I can’t go without some horizontal true north or else I start to slant everything downwards, haha. I recommend the Leuchtturm1917 or the Rhodia Dot Web notebooks if you’re curious.

                          1. 1

                            I’ve been using ruled Moleskine notebooks also with my variant of bullet journal. I also have the same slanting problem, but I think dots would be sufficient. I’ll check those out, thanks!

                            1. 2

                              I found out that dotted paper is the more versatile and my newer notebooks all have some. For example, I can easily draw a chess board when I am working on my chess or write straight or diagram almost properly without any rulers when needed.

                              I have some grieves with the quality of paper is my moleskine that vary so much between notebooks especially with foutain pen ink. Some bleeds too easily, some feathers ans some are perfect with the same ink, foutain pen and nib.

                          2. 2

                            I prefer lined since I write more than I draw and I’m not good at writing on unruled or dotted paper.

                        1. 6

                          Awesome! This seems to basically exactly summarize what I think about comments; will try ty pass it around to coworkers who don’t see point in commenting.

                          Some extra notes I did not seem to see mentioned:

                          1. When reading/analyzing the code, having “guide comments” has the added benefit of helping to find bugs. Both during review, and also later when debugging some tricky bug, this helps me see what the author intended the code to be, and establishes a “hypothesis” about the following code in my (reader’s) mind. Reading the actual code below works as “an experiment” (in Scientific Method terminology), through which I can now “validate” the “hypothesis”. Notably, it tends then to be easier for me to notice when some parts of the code are “fishy” or suspicious, i.e. unexpected from the my established mental model/hypothesis point of view. This can be a useful hint they may be buggy.
                          2. Writing good “function comments” often “automagically” leads me to discovering a good name for the function. I noticed more often than I’d expect, that when I struggle with finding a good name, setting it aside for a moment and focusing on writing a good godoc basically gives me a few of the exact words that are most crucial and best describing for the func.
                          1. 3

                            Code and commits last. Source code management systems expire.

                            Perhaps some of this is a place for a very good set of paragraphs in the commit message.

                            1. 3

                              I have never been able to do a good job with commit messages. I appreciate groups that force commits to follow an exact pattern and use them to describe the pull request.

                              I’d like to improve on this. Still, with squashed commits you lose information.

                              1. 6

                                Still, with squashed commits you lose information.

                                It’s the person who is squashing the commits responsibility to re-construct the commit messages into an uber cohesive message with all the same detail. It’s a very good reason to ask the pull request author to squash their own commits before merging, and the reviewer can then validate the resulting commit message before merging.

                                1. 2

                                  Uh, but why squash the commits, instead of keeping them separate, and thus ideally understandable in small pieces? Personally, before opening a PR, I typically do a lot rebasing and massaging to make the history as easy to review and understand as possible; I’m not sure what value would be then in squashing it into a single uber commit?

                            1. 3

                              Nobody really advocates for comments like the first example, right? So how do they get written?

                              My personal bugbear is garbage doxygen comments. Not only do they add a lot of zero-value comments to the code (usually restating the Identifiers they are referencing, with capitalization and punctuation added) but they also add a bunch of line noise characters for the benefit of the doxygen interpreter. These comments are required by some coding standard, so they can not be removed, no matter how useless or actively harmful they are.

                              1. 6

                                I like the guide comments in the first example – they let me skim the code.

                                Apart from skmming, they also let me understand idioms I was unfamiliar with. For example, I had no idea what HAL_CRC_MspDeInit(hcrc); meant (what’s Msp?) and the comment /* DeInit the low level hardware */ was helpful to me.

                                The phrase ‘guide comment’ comes from antirez’s Writing system software: code comments.

                                GUIDE COMMENT

                                […] guide comments are exactly what most people believe to be completely useless comments.

                                • They don’t state what is not clear from the code.
                                • There are no design hints in guide comments.

                                Guide comments do a single thing: they babysit the reader, assist him or her while processing what is written in the source code by providing clear division, rhythm, and introducing what you are going to read.

                                Guide comments’ sole reason to exist is to lower the cognitive load of the programmer reading some code. […] Of all the comment types I analyzed so far in this blog post, I’ll admit that this is absolutely the most subjective one.

                                The comments in that first example definitely lowered my cognitive load. Ooon the other hand, they are on the edge of being trivial comments (another type discussed in antirez’s essay): I can see a few that I’d rewrite, and few I could remove. But I can’t deny the fact that even in this state they lowered my cognitive load.

                                Edit: extended the quotation to include the ‘liking these comments is subjective’ sentence, and added a bit of ‘trivial or no?’ discussion of my own.

                                1. 3

                                  Given all the encouragement to comment code, I wonder whether some learners are copying the heavily guided style of textbooks and tutorials, without necessarily realising that the abundance of comments in the textbook code is because the code is expected to be new and incomprehensible to the reader, not because that’s how commenting should be done.

                                  I think that differing levels of experience with the language and/or framework can also contribute to “pointless” comments. What is obvious to an experienced engineer seems like a surprising quirk that needs commenting to a novice.

                                  1. 1

                                    Apart from skmming, they also let me understand idioms I was unfamiliar with. For example, I had no idea what HAL_CRC_MspDeInit(hcrc); meant (what’s Msp?) and the comment /* DeInit the low level hardware */ was helpful to me.

                                    Would it have still been helpful if I told you in advance that you were looking at code for a hardware driver, and that MSP is jargon for “microprocessor support package” – essentially, an abstraction layer for low level hardware – and has nothing to do with the specifics of the hardware in question? (the hardware that I copied from is a CRC coprocessor)

                                    To me, it seems like that comment may have actually mislead you.

                                  2. 3

                                    Nobody really advocates for comments like the first example, right? So how do they get written?

                                    I honestly wrote those kinds of comments at the start. I was told that you can comment, and that comments are good. So I would have a comment quota implied in my head and I would write these useless comments.

                                    It’s only later when I became more familiar with programming that I started getting annoyed by comments as they distract from the code itself.

                                    I think writing good comments is an important skill that is quite subtle. It requires you to understand what is expected by other programmers and to use comments to fill in the gaps. To know that, you need to be quite familiar with the language, programming in general and the zeitgeist of a particular time and place.

                                    1. 3

                                      Yes. I prefer reading code without documentation comments. Because they’re attached to functions, doc comments discourage holistic overviews of how functions interact, tutorial sections, or examples of using multiple functions together. As a result, the documentation is often poorer than it could be. Because good documentation comments are long, they make reading the code more difficult. And – as you said – because often doc comments are mandated, they’re present to fill a check box, and end being poor quality. Some of this is cultural, but culture still responds to nudges from tools.

                                      My personal wish is for a tool that cross-references out-of-line reference documentation with code, checking for coverage and correct signatures.

                                      1. 1

                                        Because they’re attached to functions, doc comments

                                        At least with Doxygen, comments can be attached to files, modules, namespaces, and classes, and high-level overview docs can be in separate markdown files that get merged into the final output. It’s a problem of the user, not of the tooling, if a particular project does not include have doc comments that give high-level overviews.

                                        My personal wish is for a tool that cross-references out-of-line reference documentation with code, checking for coverage and correct signatures.

                                        That’s often really difficult to do, because example snippets are not complete compilation units. If I write puts(x), I know that x must be a char *, but it’s difficult to build a type checker for C that will infer this from a snippet. For C++, it may be undecidable.

                                        The way that I solved this in my third book was to write a working compilation unit for each code snippet (or small set of code snippets) and markers in comments identifying them. The .tex file then pulled in snippets from things that would actually compile, but that is too much overhead for tiny inline blocks (e.g. a couple of tokens). The version that generated HTML used libclang to do complete parsing on the files and annotated the HTML with class IDs that corresponded to their token type (e.g. local variable, global variable, type name, keyword).

                                        At that stage, you realise that your tooling is edging towards literate programming and you start to wonder whether you should just start there.

                                      2. 3

                                        I won’t justify them, but the first type of comment only really bothers me when they “explain” a single line or two of code. Something like this:

                                        // Verify the CRC
                                        int crc = 0;
                                        // <XX lines of CRC code here>
                                        assert(crc == expectedValue);
                                        

                                        Isn’t too bad, IMO, but it’s probably a good indicator that there should be a verifyCRC function.

                                        1. 2

                                          When I started writing code, I used to comment like that. In fact, I use to write things like this:

                                          if(...) {
                                          } // end if
                                          

                                          Why? Well, what I knew said that comments were to explain the code. } is not very explanatory, so I felt it needed a comment.

                                          As I became more experienced, I came to understand that context is important in explanatory power as well, and so } should not be read alone, but along with the indentation to allow you to tell what it matched with, etc. I think commenting every line of code with an obvious explanation is not a philosophy, but an expression of inexperience and believing all code to be somehow arcane.

                                          1. 1

                                            As for doxygen & the likes, my gold standard of this kind of docs are the Go standard library docs. Together with how the Go stdlib APIs are designed (except for a few minor historical hiccups), I haven’t seen better yet. Not easy to quickly summarize how to reproduce that, but I like to think aiming for making a godoc page easy to read and understand for a newcomer is a good guiding principle.

                                          1. 1

                                            As a counterargument, as long as the original code is only logging, this unfortunately doesn’t actually appear to reduce the line count in the function at all, while adding new layers and extra complexity overall, whereas the original code was at least dumb and explicit. As to the rest of the claimed benefits, in a code review I’d say hard YAGNI: let’s not introduce this complexity until we really know we need it now and can point to an actual concrete use (which will most probably happen never). And even then a “rule of three” cost-benefit analysis, i.e. wouldn’t a dumb an explicit alternative be actually still good enough.

                                            1. 2

                                              This is a lot more invasive than what I think is the more common method of using decorators. In that case, the business logic doesn’t need to be modified whatsoever.

                                              1. 1

                                                Could you elaborate? I have experience with Go but it’s very unclear to me how to “use decorators” here, and would love to learn that, esp. if the business logic wouldn’t need to be modified whatsoever!

                                                1. 1

                                                  Sure! Here are two examples: https://play.golang.org/p/TtzBWbhLCq5

                                                  This extends to decorators for your e.g. business logic component, as long as you can model it as an interface.

                                              1. 3

                                                I am not saying my dreams are widely shared, or good projects to take up… but I will answer the questions as stated.

                                                Like spreadsheet, only to data-block-first. Multidimensional arrays come first, then they are layed out to show them best (unlike spreadsheets, where huge 2D sheet is primary, then arrays are kind of clumsily specified). Of course the ranges are also named; operations are likely to be a mix of how spreadsheets work nowadays, how normal code is written in Julia/Python/R/… and some things close to APL/J. No idea whether this can be made more useful (for someone) than just the existing structured-iteration libraries, maybe with a bit better output/visualisation code…

                                                A DVCS that does not regress compared to Subversion. I want shallow (last month) and narrow (just this directory) checkouts supported on the level that the workflow that makes sense is just versioning entire $HOME and then sometimes extracting a subset as a project to push. Although no idea if the next iteration of Pijul will approach that.

                                                A hackable 2D game with proper orbital mechanics take-off-to-landing (including aerodynamic flight with a possibility of stalling before landing etc.). Orbiter definitely does more than I want, but for me a 2D version would feel a nice more casual thing. And probably 2D has better chances of not needing Wine…

                                                Writers have tools for sketching out and reshuffling the story; for proofs and for code documentation there is more weight on the notion of what depends on what; and sometimes one can reverse the dependency, or replace with a forward declaration; sketching and experimenting around all that can probably be aided by some kind of a tool, but no idea how it would look like. I guess it would have something in common with Tufts VUE…

                                                1. 3

                                                  A DVCS that does not regress compared to Subversion. I want shallow (last month) and narrow (just this directory) checkouts supported on the level that the workflow that makes sense is just versioning entire $HOME and then sometimes extracting a subset as a project to push

                                                  git can technically do this (using worktrees, subtrees, sparse checkouts etc.) - but the UI for it … does not exist. It seems like a low-hanging fruit to implement this (and one which some friends with whom I collaborate on monorepo tooling may end up picking at some point).

                                                  1. 2

                                                    The thing that git fails completely on data-model level, is that it insists a branch is a pointer. In fact it is more of a property of a commit, which leads to much much better handling of history, and as a curious (but convenient) implication also brings possibility of multiple local heads for a single branch…

                                                    Of course all-$HOME versioning is likely to benefit from a more careful approach to branches, and maybe treating not just content but also changes as more hierarchical structures with possibility to swap a subtree of changes in place, but I really do not believe in anything starting from git here…

                                                  2. 2

                                                    Your spreadsheet concept basically already exists in Apple Numbers. Spreadsheets there don’t take up the whole page but instead are placed individually as a subset of the page.

                                                    To your point on DVCS, there are big companies that do have this kind of thing available, but I’m not sure how much of it is open-sourced.

                                                    1. 3

                                                      Thanks!

                                                      Re: Apple Numbers: Hm, interesting (not interesting enough to touch macOS, but I should look up whether they support more dimensions in all that etc.). Although I would expect the background computational logic to be annoyingly restrictive, but that could be independent of the layout.

                                                      Re: DVCS: what I hear is very restrictive actually, more about how to handle an effectively-monorepo without paying the worst-case performance cost than something thinking in terms of how to structure the workflow to be able to extract a natural subproject as a separate project retroactively.

                                                    2. 1

                                                      As to the first and last points, maybe https://luna-lang.org would be interesting to you? (I am a huge fanboi of them.)

                                                      1. 1

                                                        One more data flow language?

                                                        I mean, data flows are cool, sure, but I am fine writing them in one of the ton of ways in text, though.

                                                        They don’t solve the data entry + presentation issue per se (layout of computation structure and layout of a data set are different issues), and structuring a proof looks way out of scope for such a tool.

                                                        ETA: of course a data flow language well done is cool (and any laguage paradigm well done is cool), I just don’t have a use case.

                                                        1. 1

                                                          With Luna the idea is that you can write in text if you want, then jump to graphical instantly and tweak, then jump back to text, etc. with no loss of information.

                                                          As to the rest, I guess I don’t know the domains well enough to really grasp your needs & pain points :) just wanted to share FWIW, in case it could get you interested. Cheers!

                                                          1. 1

                                                            Sure, I understood that capability to switch between representations losslessly, I just need a reason to do significant mouse-focused work (which, indeed, is not said anywhere in my comment) so using this capability would always be a net loss for me personally.

                                                    1. 2

                                                      Something that makes writing/understanding very large amounts of YAML easy.

                                                      Bonus points if I can feed it something like… all Kubernetes options and available annotations and their types, and get some form of auto-complete and validation.

                                                      1. 8

                                                        Maybe Dhall is what you are looking for.

                                                        1. 3
                                                      1. 3

                                                        https://luna-lang.org - I tried to get hired by them but we couldn’t find common points with my expertise areas unfortunately.

                                                        A non-Electron lean WYSIWYG Markdown editor with outliner features, with plugins support, for stuff like ASCIIMath, ditaa, ASCII UML diagrams, runnable code snippets, etc. (I know, I could learn emacs and org-mode… problem is, I am already fairly advanced in vim, and I don’t suspect evil mode has all the features I use…) Ideally with WordStar keyboard shortcuts.

                                                        A non-Electron GUI email client, with similar features as notmuch, with easy tagging of emails using emoticons/icons and instant filtering by tag combinations (ideally all icons visible at once) and allowing me to easily edit received messages so that I can keep only the crucial parts (but the rest of the whole email text could still be shown “grayed out”).

                                                        A git GUI allowing easy rebasing and splitting of commits via drag and drop on a tree visualization. Also with easy browsing of history and blame-digging (a.k.a. how did this bug/suspicious code get to look like it does now?).

                                                        A car driving simulator using Panini projection and Minecraft-like world editing, possibly on hex grid, shared in wiki-like way so that people could map their cities and train driving in them. With ability to represent non-flat roads, slightly uphill/downhill, up to steep narrow streets of Italian towns.

                                                        A microkernel-based OS working on Raspberry Pi 4 (possibly a set of missing drivers for Genode OS).

                                                        A REPL for Nim similar in power and features to OCaml’s utop.

                                                        Also, did I mention https://luna-lang.org?

                                                        1. 2

                                                          With regards to a non-electron GUI email client, take a look at https://github.com/astroidmail/astroid. It is essentially a frontend for notmuch and the developer is very responsive.

                                                        1. 40

                                                          I want a Wikipedia for time and space. I want people to collaborate on a globe, marking territories of states, migrations of peoples, important events, temperatures, crop yields, trade flows. I want to pick which layers I want to see at one time. This sort of thing would give us a clearer, more integrated view of history, and show how connected we are all. A volcano eruption in Mexico led to crops failing around the world. New World crops led to an explosion of people in southern Chinap, a previously less inhabited place. A Viking woman met natives in present-day Canada and also visited Rome on pilgrimage.

                                                          1. 4

                                                            Excellent idea. I have an idea for something similar but less… featured. My idea is about time and space tagged news.

                                                            1. 3

                                                              Also thinking about one from time to time - in my view kinda like Wikimapia for history, usually thinking how country borders and armies could be represented.

                                                              1. 3

                                                                The Seshat global history databank is a bit similar to this (great) idea.

                                                                “systematically collects what is currently known about the social and political organization of human societies and how civilizations have evolved over time”

                                                              1. 5

                                                                When searching public github with public sourcegraph, you need to limit the query a bit, so as to not get a “too many repos” result. I tend to do it by narrowing the scope down to a single org/dev; it is not explicitly documented AFAIK, but for a single repo, I found that just appending the URL to their one works as a quick shortcut, e.g.:

                                                                Then you can modify the URL in the query editbox to remove the suffix.

                                                                1. 1

                                                                  Sincere question: IIUC Matlab/Octave, R, Julia, all operate on arrays too. What does J/APL bring on the table in comparison nowadays (apart from being an inspiration for those, I assume)? (Sorry if that’s explained in the article, don’t have time to read it now unfortunately.)

                                                                  1. 1

                                                                    The clearest explanation is probably in the seminal paper/presentation Notation as a Tool of Thought. Longer than TFA, but should answer all your questions; read it.

                                                                  1. 1

                                                                    For insta-sharing of the modified videos / their “indexes”, maybe you could put them on IPFS? Sorry if you already mention this somewhere, I only glanced over the readme as I’m in a hurry.

                                                                    1. 1

                                                                      I actually don’t modify the videos, I just download them and build a timetable (that I call an ‘index’) that remembers when was the video loud and when was it silent - the timetable file sizes range from 1K to 20K (I don’t even bother to compress them), most of them being in the ~4K range (it’s the javascript that speeds up the video while playing it). And this extension is not currently used much, so it’s not much of a concern as the sizes are manageable so far.

                                                                      IPFS is interesting project and I need to finally look into it further. It would be really nice if I managed to run it entirely over IPFS and eliminate the need for a central server. I quite like the idea.

                                                                      1. 1

                                                                        I played with the Go API recently, there was a lot of docs I had to wade through, but the final code was quite nice and short. Just remember to call “pin” and/or “provide”, one of them brought down sharing speed from behind NAT from some horrific 45 minutes to something much more bearable around 2 min. And experimental auto-relay; didn’t minimize to check which ones are the required ones. I know they also have JS lib on the same level of support I think.

                                                                    1. 2

                                                                      I hope to order a PineTime once they graduate to a slightly more consumer-oriented phase (i.e. post-devkit, waterproof, and over-the-air programmable).

                                                                      1. 1

                                                                        I read a comment on HN claiming that LLVM uses a neural net for register allocation - can anyone here confirm (ideally with some kind of a reference/citation link) or deny?

                                                                        1. 2

                                                                          Sort of, LLVM has their own improvement upon the basic linear scanning algorithm which allows for multiple different weights and heuristics along the way. They use something called a hopfield network, a 1 layer NN, to determine which variable gets spilled.There’s also been research, not under LLVM as far as I’m aware, on using neural networks to decide which algorithm to run at compile time.

                                                                          Sources: https://www.slideshare.net/mobile/chimerawang/llvm-register-allocation-59885569 https://llvm.org/doxygen/SpillPlacement_8cpp_source.html

                                                                        1. 8

                                                                          Well, yeah, I would expect that the language creators’ definition of the word “possible” excludes what you can do with unsafe due to the likely chance of nasal demon aviation.

                                                                          1. 3

                                                                            Indeed. It’s called unsafe for a reason.

                                                                            1. 2

                                                                              To be even more pedantic, there aren’t any strings being modified - bytes are not strings.

                                                                              1. 1

                                                                                But all strings are bytes.

                                                                                1. 1

                                                                                  But the assertion in the title was not that bytes are immutable.

                                                                                  1. 1

                                                                                    It’s all about perspective.

                                                                                2. 1

                                                                                  strings.Builder turns a byte slice into a string. Read its source sometime – it’s pretty neat (and concise).

                                                                                  1. 2

                                                                                    You can even use assembly in Go, but it isn’t covered by backwards compatibility promise, similar as with unsafe. The strings.Builder OTOH is under promise to be kept working every time Go internals change in important ways.

                                                                              2. 3

                                                                                I remember once someone said something similar about Python strings, and I thought, “this I have got to see,” and it turns out they were using ctypes to yank out the underlying C-string pointer and screw with it. I mean…yes? Play stupid games, win stupid prizes.

                                                                                There are times it’s essential that some data is really and truly immutable. But you can do that even in C, just by making sure you allocate a string carefully and then mark the page it’s in as read-only. Saying Go (or Python, or Java, or…) strings are immutable is talking about what guarantees you can rely on within the language, not what you can accomplish by abusing the runtime.

                                                                                1. 1

                                                                                  nasal demon aviation

                                                                                  Well this made my day.

                                                                                1. 4

                                                                                  Reaaaally weird article in my eyes. I just cannot shake the feeling like if the author never ever had any positive outcome out of their tests. [Or did they just take a deliberately fake rhetoric stance?]

                                                                                  Personally, the first thing I want to say to that is, that I totally had a situation more than once in my life, where I wrote some code, felt happy it’s so smart and great and perfect, then grudgingly wrote some tests, then lo and behold, immediately saw them find some dumb mistakes.

                                                                                  Secondly, I do have a couple hobby open-source projects I wrote, where I didn’t have stamina to write tests. I fully accept that it had to be like that (they took a lot of energy to get to completion anyway). But I’m also now at this unpleasant place, where I’m afraid to improve them and take them further, paralyzed by the thought that any change I do may break something. I feel I really need to add quite a lot of tests before I can go further, to give me some peace of mind and a feeling of safety. Though I also still can’t muster stamina to do that. Hopefully I’ll be able to break out of this place at some point.

                                                                                  Thirdly, in another open-source project, I did write some tests as I was going, especially a few kinda end-to-end “spec” tests. And I’m very happy I did that, they gave me some targets to work towards, and I think a few times they detected some regressions I accidentally introduced while adding code, helping me to fix them early, and somewhat limiting the amount of code I had to browse to debug them.

                                                                                  I mean, I totally don’t agree with many absolutist ideas/rules like “the more tests the merrier”, or “always ever write tests before code”, or “100% coverage or die”, etc. etc. etc. (Maybe the only “hard” rule I kinda try to stick to recently is “if I can’t [yet] write the test reasonably well [esp. non-flaky, non-time-dependent, and black-box], better not write it at all [until I, or someone else, invent some smarter way to do it]”). And I still do find writing tests not only annoying, but also hard and tricky. (In too many ways to quickly list here.) In other words, I don’t see tests as panaceum. But I just do personally often see value in them, see them as helpful. In other words again, I see them as one more tool in my toolbelt, that has its ways and times and places of being useful, as well as of being counter-productive.

                                                                                  PS. Ah, yes, one more thing: I did a few ports of some small open-source projects to different languages. A test-suite was basically a must-have prerequisite before I started each of them, and each time was ab-so-lu-te-ly indispensable.

                                                                                  PPS. I would guess @andyc probably could have an opinion or two on the topic of whether tests are useful to them when writing their shell.

                                                                                  PPPS. I dunno, is the OP just intended to be provocative, so as to force people to write their testimonials/argue to the contrary?

                                                                                  1. 6

                                                                                    If, like me, you’re looking for how it differs from IPFS, DAT, SSB, the author lists some bullet points in a section titled “Comparisons” in the readme.