My own view: rolling release distros gets less in my way than distros like Debian. They allow me to install anything I want, as close as possible to upstream.
Not saying one is better than the other, just remarking that it's interesting to see 'getting in the way' meaning completely opposite things for different people :).
But... Debian is also a rolling release distro. Just use the "testing" or "unstable" suite. I am using Debian unstable on my main desktop since 1999, and had very little issues with it. The testing suite is the one which filters out most bugs found in unstable, and is something you can definitely use as a regular user.
Can confirm, have been using Debian testing branch on my local server for AI experiments for a year and it works great. Never hit any major issues, always have (reasonably) up to date software.
I've found both to be true at different times in my life. When I was younger and had time to read release notes I found rolling release made my life a lot easier, because my software was always close to the documentation online, always had the latest fixes etc.
But now my schedule only lets me do an update once a month rather than daily, so it feels more likely to introduce breaking changes and I'd rather just leave her all until a specific moment when I have the time to work through it all, and the longer term support distris help with that because those big all-at-once upgrades seem to be better documented.
> My own view: rolling release distros gets less in my way than distros like Debian. They allow me to install anything I want, as close as possible to upstream.
Debian comes with backports repositories which allow you to cleanly install newer versions of selected packages, without affecting the rest of the system.
Right. Because only laid-off employees can cause such a damage of course (/s).
This is a twisted way to look at the risk.
Disgruntled employees have more reason to wreak havoc. All the more reason
they should be treated as humanely as possible in a difficult period that
in most cases is inflicted by the company itself.
I have been out of the field for some time, so I am not sure how much BLAST is used these days.
Therer was a time when BLAST-ing a DNA and protein sequence you have is like doing a Google search on it: it simply tells you where the sequence might come from. This is useful especially when your research is to figure out what that specific sequence is doing. It won't give you the answer immediately (otherwise why bother doing the research at all), but it certainly gives context: sequence similarity often hints at similar / related functions.
As an analogy: imagine if StackOverflow is suddenly down and you don't know *if* it's going to be up again.
My sibling is a molecular biologist working in the industry and they do use BLAST data. She's been telling her company for months they need to secure access with an alternative source or offline backup, hopefully their software team started it in time.
Everyone can set-up their own blast database. Usually if you are specialized on a certain species you have your own DB cached in memory somewhere locally for efficiency. Also there are alternatives. NCBI blast is just one of many. Also all the sequences are globally kept and in sync in different regions of the world, so if one Datacenter goes down you still have the option to use the exact same data from Europe or Japan and so on.
Fair, and to be totally clear, even when I was in the field (an age ago), sequence stuff was never really my thing. However, sequence comparison is a fairly fundamental tool.
Of course, yes you can run these things locally, other providers (such as EBI Europe and Japan) have them, etc. It's still a bad sign on the pile of other bad signs, IMO.
Not a professional, but still use it like that. They also have a new smartblast thing, which works much faster (really, really like Google!) but only on highly similar proteins.
> in the Hack Club Slack (Discord-style online groupchat), you'll find a group of 27,253+ fabulous ...
See, in my head Slack comes first before Discord. It was released, after all, 2 years prior. My mental shortcut for Discord is that it's like Slack but for games so it has better audio support. But here it's the other way around.
It's ok ~ perhaps the on-ramp path is Discord -> Slack -> IRC :).
I can second AsciiDoc. It hits the sweet spot between Markdown (arguably more suited for short-ish content) and LaTeX (full-blown academic papers with citations, formulas, etc.).
Have been using AsciiDoc for the past few years and loving it, only falling back to Markdown on places where AsciiDoc is not (yet?) available. GitHub and GitLab, for example, supports rendering AsciiDoc. PyPI unfortunately has not supported it, but more seem to be looking into it [1], which is great.
GSoC is awesome and I'm happy to see it's still running.
The experience I got as a student in 2012 was invaluable for my career in tech ~ more so since I did not formally study CS. It introduced me to so much: a lot of the programming itself, collaborating with fellow developers.
I spent one year preparing for it, and man seeing my proposal accepted was one of the best feelings I have ever experienced (much better than when I graduated, even). A close second is knowing that I actually was helping people with my code (I still keep the emails where people sent me questions about the library API I was developing).
I hope this year's (and future) batches of students get to experience the same (if not more) highs :).
> But the real question is why they don't do the same for tax evasion?
Who says they don't?
If I had to guess, I would say the magnitude of the problem is just more complex. The tax system is more complicated and impacts more people.
They did attempt to change the law to give the tax agency more similar powers[1]. Last I checked, it was rejected due to public outcry[2]. I do not expect this to be the last attempt.
"Congress asked the IRS to report on why it audits the poor more than the affluent. Its response is that it doesn’t have enough money and people to audit the wealthy properly. So it’s not going to."
It's neat ~ could have used checks in-between to ensure e.g. `$(go env GOBIN)` is not empty.
For something more comprehensive (of course with a larger install size) and the possibility of handling not just Go, I have had good experiences with asdf [1].
Everybody keeps telling me about asdf, but I haven't yet come around to using it. I like to have manual control over my packages, but I guess I should really give it a try one day.
I hesitated a little bit before deciding to purchase and go through the book. Had already read many glowing reviews then, but was not sure if the choice of language (Java) for the first half of the book would be a hindrance (it's not the stack I am most familiar with).
Decided to buy it anyway, primarily because the two implementations of the toy language piqued my interest (most other books only go through one implementation).
Boy was I glad I did.
Writing is superb, end-of-chapter challenges are instructive, code samples are meticulously and beautifully done. Here and there I also encountered references to other languages (e.g. had a brief detour to Lua internals [1], thanks to a side note), which I have enjoyed too.
Went through the first half twice: first using Java as it is written and then secondly implemented the interpreter in Rust (my initial fear turned out to be unfounded). Currently going through the second half.
I wish people would be less opinionated about things like this. I've completed exercises for books or courses in C, C++, Lisp, Scheme, Go, Python, Javascript, Ruby, Rust, Java, Scala, Clojure, Prolog, Assembly, etc. It's not a big deal. Nobody is telling anybody they have to then program in that language for the rest of their lives. Be open to new experiences. Java really isn't difficult or alien or bad enough to complain that it's the wrong language and expecting book x to be in your preferred language z when there are dozens one could choose is so...closed-minded.
I wrote the first one in Python without issue. I guess any sufficiently expressive language should be fairly easy to “adjust the recipe to” while still following the book.
I fully agree. Superb, "meticulously and beautifully done". I read it online and followed along writing code then bought the book just to support the author. Thanks Bob.
Crafting is less about modern or production-grade anything and more about understanding fundamentals. It would be equally at home in a 1980s compilers and language design course or in a 2000s version of that course. It has a single motivating principle, which is that a learner who understands the bare basics of algorithms and data structures knows, in the truest sense of the word, what a compiler and an interpreter does. It achieves that principle beautifully.
The parser’s data structure is a more traditional Abstract Syntax Node design. Roslyn’s tree design is, IMO, a good internal structure for use in a production-grade compiler meant to be coupled with a developer environment (IDE and other tools) because the complexity pays off in terms of developer experience. However, Bob set out (as far as I can tell from the book and his talks/comments on the subject) to provide a fairly beginner friendly, introduction to the topic of language implementation. Within his chosen scope the parser implementation in Crafting Interpreters is more than sufficient and clearly presents the concepts intended.
IIRC, Roslyn's red-green tree approach is at least partly due to needing to support interactive editing without re-parsing everything. If that's what you're referring to, no, the book doesn't cover that; both interpreters run either in batch mode on a single file or in a simple REPL.
If you're interested in Roslyn inspired compiler writing, Immo Landwerth who works on as a Program Manager on .NET made a Youtube series about writing a compiler, and my understanding from the part I watched is his work is heavily inspired by Roslyn.
See to me Java was an advantage because it ensured I would do part 1 in Not Java (in my case c#). Mind you c# is great because it is similar enough you can follow along while also being different enough that you still are forced to engage and think. At some point I want to redo part 1 in F# to REALLY push myself (and also force me to better engage with F#).
I did the first part in F#, and rather than translating Java to F#, I looked at what the author was trying to accomplish in each step, and did something functionally equivalent in idiomatic F#. That was fun & challenging.
haven't tackled the second part, I'm currently down the rabbit hole with Samuel Mimram's Program = Proof, which I'm just loving and the first book I've seen that focuses on the Curry Howard Isomorphism, covering essential logic, lambda calculus, type theory, and Agda... so good.
Any trouble with the Rust implementation? I wanted to give the book a go using Rust, but have been sitting on it because I don't want to get halfway through it only to find that Rust's intentional design and limitations might make it difficult to build an interpreter via the assumptions in the book.
You can do it pretty much verbatim, with dynamic dispatch using enums and lots of pattern matching.
It gets a bit trickier when you are nesting environments for closures and the like, but certainly nothing insurmountable without a few things from the standard library.
I've been loosely following the book with Rust, and no issues so far. Both the compiler and interpreter are implementable without much issues. You'll have to adapt a bit, but in general you can use the same methods.
Not really (for the first part at least, am not yet finished with the second part). I did deviate a little bit with my Rust implementation.
This was my goal anyway: implement Lox differently. Off the top of my head:
* I used ADTs to encapsulate error types and states as much as possible, this lead to heavy use of enums and pattern matching.
* I implemented the `Environment` as an immutable, explicitly passed value. This was a little challenging at first, but overall quite satisfying to do.
The way you phrase that makes it sound like you're implying there isn't an overwhelming dominance in terms of 'boring languages' and tutorials/content/books/training material. HN presumably doesn't upvote Java book #10^6 unless it is quite unique otherwise.
I didn't worry because of Java's perceived lack of 'excitement'.
Just that I am more familiar with other languages and I worried I'd get lost trying to understand Java and not digest the material properly. I tend to fall down rabbit holes sometimes ...
If anything, this has been another way for me to be more acquainted with Java, which I am happy for :).
Java is the opposite of boring.
It lacks basic fundamentals such as algebraic data types and pattern matching.
You will be kicking and screaming the whole ride.
A boring language would be a language where you aren't triggered/bothered by its basic ergonomics and hygiene. In Java, you must translate discrete variants into dogmatic OO paradigm instead of using language primitives.
Thanks to Java's poor design, it's fundamentally a hazard and a land mine thanks to null not being first class in type system. The use of null as a value inhabiting any type should result in a slap in the face upon opening a pull request (until Java adopts type-safe optionals like Kotlin)
P.S. Switch expressions and sealed interfaces aren't there yet, Kotlin and Scala are still the only options if you are imprisoned to JVM.
Using Java was a poor choice (especially without the latest improvements such as records and switch expressions):
* new books should use more modern popular languages to age well and to attract younger audience
* on the JVM there are languages better suited for the topic (e.g. Scala by a large margin)
* There's already the "Language Implementation Patterns" book (https://www.amazon.com/Language-Implementation-Patterns-Doma...) which not only is great for teaching because of its pattern-based approach but also gives you real life skills (e.g. ANTLR is used in most big data query engines)
> new books should use more modern popular languages to age well and to attract younger audience
That doesn't make sense. Java is one of the most popular programming language, more popular than a lot of other "modern popular languages". The only languages more popular are either as old as Java (JavaScript, Python) or older (C, C++). C# might be one option, but it's close to Java, and I don't know if the support for Linux/MacOS was here at the time this book was started. Same thing for JavaScript and Python's popularity, which are relatively recent trends. On the other hand, Java has stayed and endured. It's still here and will still probably be here in 20 years.
> on the JVM there are languages better suited for the topic (e.g. Scala by a large margin)
Scala is less popular than Java, and harder to master. Once you consider Scala, you get into endless arguments about whether to use Scala, SML, OCaml, Haskell, etc.
> There's already the "Language Implementation Patterns" book
There is also "Writing an interpreter in Go" and "Writing a compiler in Go" that seem to cover the same ground. But I'm certain than more people know about interpreters and compilers thanks to these three books than thanks to any one of them.
> but also gives you real life skills (e.g. ANTLR is used in most big data query engines)
The majority of programming languages don't use a generated parser but a handmade recursive descent parser, because it's the best at error reporting. There's a good post about different parsing approaches by Laurence Tratt: https://tratt.net/laurie/essays/entries/which_parsing_approa.... Generated parsers are great for DSLs but that won't teach you how the programming languages that you use work.
Didn't think I'd see 'attract younger audience' and 'Scala' in the same sentence.
A lot of young people know Java because it's what they learned in school and because a lot of employers use it so it's the first thing they learn on the job.
In my opinion, the language is designed in a way that makes it easy to pick up for beginners. The lack of obfuscated operators and foot guns is a plus, and the language forces you to avoid doing 'clever' code golf things, too.
ANTLR may be used in big data query engines but I can’t think of a single language I’ve ever used that had a parser written with it. I know you can grab off the shelf parsers with antlr for a bunch of languages, but who cares?
And frankly, Scala’s build tool is way too slow and would be a slog to use for this book.
SBT and Scala are the biggest productivity killers for me at work purely based on the slow build time and lack of proper documentation. That and every release the ecosystem makes some breaking change.
Yeah, SBT is pretty awful. I feel like Scala suffers from design by committee, and by being the choice language of certain types of Enterprise Software Engineers TM.
Introducing `false` as a standalone type but not `true` is what makes this weird. Generic, literal returns are fine. Python is another language that has it [1].
The introduction of the RFC [2] also still mentions `false` is of type bool:
> null corresponds to PHP's unit type, i.e. the type which holds a single value. false is a literal type of type bool.
But why call it bool if `true` is not a standalone type too?
Not saying one is better than the other, just remarking that it's interesting to see 'getting in the way' meaning completely opposite things for different people :).