Starting October 1st, we will start to randomly select tenants and disable basic authentication access for… IMAP, …
IMAP, at least, isn’t going away, just “basic authentication.” You’ll still be able to use it, but you won’t be logging in with a username and password. Instead, you’d need to use a predictably non-standard MS extension to oauth2 called xoauth. It relies on Azure and O365/Exchange and I didn’t find it to be difficult, but whether or not clients will adopt it is another matter.
I ran into this last month. I had to work on some IMAP integration recently with O365, and about a week after getting something working MS switched off legacy auth in my employer’s tenant. I had to switch over to xoauth2. The only difficult part was finding any information about how to do it. Microsoft’s documentation, given how much of it there is, is usually scattered and often hard to piece together.
My workplace did the same. Seems like the easiest way is to pretend to be Thunderbird, and use its client ID and secret.
I don’t know what this adds other than friction, but maybe that’s the point.
Using OAuth like this just doesn’t work. I thought corporations learned that during the rise of smartphones, when people were plucking OAuth credentials out of apps for fun.
I used client modules in go and node. Roughly, it consisted of setting up a new azure app, granting that app permission to use imap in the tenant, enabling oauth flows for the app, creating a principle (user)/client I’d/secret, granting O365 permission for the user. Then it was a matter of enabling imap access on the specific O365 user account/mailboxes, and finally granting the principle access to the boxes. There were a few powershell scripts mixed in.
It wasn’t obvious or documented and took some trial and error. This has been my experience for anything having to do with azure and integration with virtually any of Microsoft’s other cloud products: business central, o365, etc. It’s a time suck.
After all that, my understanding based solely on my admin’s findings is that IMAP is sticking around, at least for paying (enterprise) customers. However, vanilla, plaintext, basic auth goes away.
IMAP, at least, isn’t going away, just “basic authentication.”
That’s not exactly how the mail is phrased:
[The Enterprise] only supports the use of the approved email client Outlook, Outlook 365 available in our [The Enterprise] tenant, or Outlook for iOS and Android.
That makes it sound like you can only use Outlook.
Also: do they even read what they’re writing? This is so user-hostile it isn’t even funny:
“If you use an alternate email program that relies on POP3, IMAP or SMTP, like native mail programs in iOS and Android, expect your [The Enterprise] email connection for that app to stop functioning when Microsoft chooses to disable these protocols.”
[The Enterprise] only supports the use of the approved email client Outlook, Outlook 365 available in our [The Enterprise] tenant, or Outlook for iOS and Android.
That’s the policy of the tenant. A lot of orgs completely disable POP/IMAP in Exchange, and just use OWA/EWS/MAPI. As stated, IMAP is staying if your org uses it, just with OAuth.
(The funny thing is Outlook doesn’t support the OAuth extensions to IMAP, so it’ll just be using EWS/MAPI.)
“If you use an alternate email program that relies on POP3, IMAP or SMTP, like native mail programs in iOS and Android, expect your [The Enterprise] email connection for that app to stop functioning when Microsoft chooses to disable these protocols.”
Mobile apps are usually using EAS instead of IMAP.
I agree totally agree regarding the user hostility bit. Just to be clear, my employer /is/ using O365 in an enterprise tenant.
In my case the integration service relied on IMAP with regular authentication. My admin read that they were going to disable IMAP on some tenants in the future, and the following week they did for ours. He re-enabled it, but the integration wasn’t able to authenticate.
After a day or two of spelunking though the MSDN nightmare we were able to piece together a process to get the oauth client credentials flow, suitable for integration because it doesn’t require manual consent, working against their tenant/O365. Works like a charm. Still IMAP, different auth scheme.
So you’re right, IMAP may be going away in general, but it’s alive and well in their enterprise environment. “Basic authentication” no longer works, at least for us.
Edit: I’m not using an outlook /client/. I’m using imap clients in go, node, and at least initially c#.
Wow! I didn’t expect this to get posted here. Neat.
Anyway, yes, user-hostile. But by now, I’m used to this attitude from The Enterprise. They brought the company I was working for and by God, we’re going to do things their way (for development, they’re doing The Enterprise Agile method, which is mostly the stuff on the right hand-side of the Agile Manifesto and ignoring the left hand-side).
You can re-enable these for your tenant. Microsoft is turning off access and pushing warnings to say the authentication protocol for IMAP and POP3 are not recommended. They want you to use a more modern authentication protocol to access their mail servers. I do not want to force our teams to migrate from the email apps they like, so I re-enabled the protocols tenant wide.
When they turn it off you don’t even get a warning. IMAP just stops working. The new auth method (pdf) isn’t difficult to work with, but whether or not non-MS mail clients will support it more broadly remains to be seen.
Neat way to present Caddy…but Sourcegraph itself looks pretty interesting. Does anyone have any experience with it to share? It looks like a great way to document and navigate a codebase.
It looks like a great way to document and navigate a codebase.
Yeah, some of our customers use Notebooks for onboarding new hires.
Before I joined I used it to monitor code containing the name of the CNCF project I was maintaining at the time. Since joining I’ve been using it for batch changes (https://about.sourcegraph.com/blog/batch-changes-ospo) and other tasks. If you have any other questions let me know her or our Discord.
One piece of software that I’m super grateful for lately is jless. It’s crossed my radar once or twice in the past, but recently I’ve needed to navigate big json responses while testing and evaluating different APIs and it’s come in really handy.
Because you need the whole of spacemacs (or one of its competitors) not just one keybinding mode to make Emacs info an IDE. After you’ve installed all that, it’s no longer low-latency. (This was one of the things that eventually made me give up on Emacs.)
Pretty much all vi emulations have infelicities, so if you have muscle memory for vi it’s advantageous to be using the real thing.
So is it that Doom/Spacemacs have inherent increased latency compared to vim/nvim or the addition of LSP modes to them causes this lag?
I ask because if I enable CoC , I see hiccups here and there in my vim (unstable) setup.
I remain a fan of Spacemacs. In my experience there was often a little lag even when using modes that didn’t rely on an lsp iirc, and even though it was lazy loading. I wouldn’t say it was slow, but it often wasn’t as responsive as my vim config, and that caused it to feel kind of heavy. I tried Doom, which seemed a lot quicker than spacemacs, but I don’t think it has the documentation that spacemacs has and quickly gave it up.
I switched to neoclide/coc.nvim with its lsp support last week, mainly out of curiosity, while I was tooling around with go source. I thought it worked out pretty good compared to my previous ncm/ncm2 setup. In both cases there was pretty noticeable startup lag that I wasn’t thrilled with but tolerated. I think it’s possible that the cause of that lag in the former was the addition of the LSP modes I’d installed, but I couldn’t say for sure.
I haven’t used lunarvim for more than a day but the startup and responsiveness I’ve seen are significantly improved compared to my older configs. lunarvim is lazy loading its language support like spacemacs, but it seems to do a better job.
My experience(*) was that the Elisp interpreter was blocking on CPU. There’s only a single thread and it wasn’t fast enough to keep up with typing, once syntax highlighting & the rest was going on.
(* from a few years ago now, this predates the use of LSPs)
i’ve tried evil mode a time or two, and a full fledged spacemacs installation once. never stuck with it long, because it’s always felt distinctly less responsive than vim.
I caught this on the orange site and thought I’d give it a shot. I’m impressed. In 5 minutes I’ve already got a vim that’s behaving better than what I spent a chunk of last weekend tuning.
How about, “Four books professional server-side Python developers should read (and a few they don’t need to)”.
As a client-side C++ programmer, that list doesn’t do me much good, except for “High Performance Browser Networking” which is a killer read for anyone involved in HTTP-based APIs on either end of the wire. (And OK, I do write some utility scripts in Python.)
On the other hand, “Design Patterns” is a stone classic.
The stone cold classic is SICP, to the point of cliche but no less valid for it. It doesn’t have the instant for-my-job practicality boost that a style guide like “90 Specific Ways to Write Better Python” does, but it’s in another ballpark of depth.
@eatonphil I am curious if you had criticisms of it or if you think its lessons are just not nuts-and-bolts enough for your list.
It’s a perennial goal of mine to finish SICP. 😀 If someone is coming to this list and sees value in four top books, I can’t really recommend a book in the same category here that’s taken me years to finish. But for people who read a lot, of course you can give it a go.
I’m very much a PL nerd. As mentioned elsewhere, I’ve spent a lot of time programing in Standard ML (see ponyo on my github) and Scheme (see bsdscheme on my github). Forcing myself to spend years getting good at both has seriously improved my ability to write simple code.
But I also can’t really recommend that to most devs either because who knows if you’ll enjoy it. Doing what inspires you is the most important thing so you actually complete what it is you want to do.
Scheme and the art of programming by George Springer is almost the same material as SICP but in Scheme. Honestly if you have worked for years in ML or Scheme you probably don’t need SICP since it is a introductory level text.
I just picked this one up a few weeks back and have slowly been working through it. I’m surprised that I hadn’t run into it before then. It’s a textbook and it reads like a textbook, there’s no getting around that, but it’s accessible and seems to be a great intro to Scheme in general.
SICP is using Scheme too, isn’t it? I recall running across MIT being the recommended implementation, but I’ve had no problems with Guile, and there’s a language in Racket, too. I bounce between the Springer book, SICP, and Little Schemer when I’m not too busy. I’m in no rush, but I’ve found those three to be a great way to get acquainted with emacs/geiser & guile.
I wish I could recommend books on other languages! But no book I’ve read on JavaScript (thinking JavaScript the Good Parts, How JavaScript Works), Go (there’s almost nothing here that’s not just reference), Java (Effective Java is massive and not all useful), or C++ (what, Meyers’ Effective C++?) is in the same category in terms of information density, being well-written, and still being applicable today. I’d be happy to take recommendations though for books not among these.
Thinking Forth (1984) and Writing Solid Code (1993) are two books that radically changed how I approached programming. Yes, one is about Forth, and one is about C, but I’ve found them applicable to more than just those two languages.
Fully agree on both and in particular that TF is applicable beyond Forth. Great book.
I wonder whether you might enjoy Elements of Programming and/or The Humane Interface (and here’s the bit I’ve quoted most often). Very different books, both of them insightful and hard. EoP is a C++ book that’s about C++ in the way TF is about Forth, THI is a UI book that uses phrases like “information-theorietic efficiency” instead of “at [famous company] we do this [this way]”.
Personally, my qualm wouldn’t be about the language, it would be about the domain. I haven’t read the books, but those 4 titles really are web focused. I’m sure lots of those translate to other domains, but it’s clearly not aimed as the general purpose developer who doesn’t yet know which domain they will tackle. No, this is for backend web developers.
Thus, your title should really be closer to: Four books professional backend developers should read. That way it’s more focused to your actual target audience.
My point is that it wasn’t intended to be backends focused. I haven’t read any really great books on JavaScript (but HPBN is clearly browser, not backend, focused). And I genuinely wish frontend developers I worked with knew more that’s covered in DDIA.
But I don’t pretend to speak for every domain of programming for sure.
It’s easy to for us to get myopic about stuff outside our domain.
Note that even here you seem to be implicitly assuming that not-backend = in-browser. That’s leaving out (native) desktop, mobile and embedded development.
I suspect there aren’t actually any books that are super important for all serious programmers. The books I learned the most from are way out of date (K&R, the Smalltalk-80 Blue Book, Advanced Cryptography) or very domain specific (Unix Network Programming) or both (Inside Macintosh.)
Yes I’m definitely missing domains but mobile isn’t one of them! HPBN devotes a ton of time to the effect of protocols on mobile battery life of all things. There’s a chapter or two on the behavior of mobile networks. Mobile developers are also responsible for monitoring and alerting on their production deploys. And they’ll also be heavy users of backend systems.
All this isn’t to say that I’ve got the list perfect. I hope I change my mind on it over time as I’ve read new books, learned new things, and expired different domains.
I feel The Go Programming Language is quite good; certainly more than just a reference.
The Little Schemer is probably the best programming book I’ve read. While it’s quite limited in scope (functional programming in Scheme), it does explain it in such a way that’s very insightful and useful for other languages too, IMO. And the writing style is just fun!
I feel The Go Programming Language is quite good; certainly more than just a reference.
It’s not bad. And certainly new Go developers would do well to use it as a style guide since writing “idiomatic” Go takes a bit. I’ll consider adding it to a future version of this post.
The Little Schemer is probably the best programming book I’ve read. While it’s quite limited in scope (functional programming in Scheme), it does explain it in such a way that’s very insightful and useful for other languages too, IMO. And the writing style is just fun!
In the category of niche languages there is no shortage of gems. :) I haven’t read The Little Schemer but I’m working through The Little Typer at the moment. I’ve got a post in mind for a rundown of 6-8 Lisp books alone. But I wouldn’t consider recommending any of these to developers en masse (even though I believe programming in Scheme or Standard ML for a while helps you write simpler code).
I don’t think the value of The Little Schemer is in learning Scheme, but rather in learning recursion and functional programming, and Scheme is just the tool that explains these concepts. The reason I got it in the first place is because it came recommended to better understand JavaScript’s functional aspects.
You Don’t Know JS was an excellent language-specific book back in ~2013 when I read it, and I think it’s been updated after that.
I do prefer more general books these days, now that I know enough languages well enough. SICP is a famous one, but I think How to Design Programs might be a more approachable similar book. Nb. I’ve only worked about halfway through it.
My copy of Effective Java by Joshua Bloch is 346 pages, are you perhaps confusing it with another? I found it useful, too. Some of it is a bit self-evident, but I opened my copy at a random page and read an item (46, pages 212-214, about for(:) compared to for(;;)) and still found it good.
It’s not a book on java, though. It’s for people who already know java, and who write or maintain large java programs, say 50kloc or more.
I dunno, I’m reading through Designing Data-Intensive Applications at the moment, and it feels pretty language agnostic. I’ve seen some snippets of bash, but that’s it. Definitely not Python-focused.
Language-agnostic, but server-oriented. That’s why I wrote “server-side”. As a client (mostly mobile) developer, I’m not much concerned with terabyte-scale data or with distributed algorithms that only make sense for clusters in a data center (because they assume latency is zero and uptime is 99% and all peers are trusted.)
I’m not dissing any of this, just pointing out the applicability is narrower than advertised :)
I’ve been really tempted to buy a remarkable2. But the reviews I see say it’s great for note taking but not so great for just reading PDFs. Mostly I want to read PDFs. I’m still on the fence.
Same. In the month or so I’ve had one, it hasn’t caused me a single frustration (and I’m the kind of person who gets annoyed at the user interfaces of my own Apple products). It works exactly as advertised. Anyone who thinks it might be worth the price tag should watch a third party review video and check out the official and awesome list projects. It has been awhile since I’ve stayed this excited about a new device so long after buying it.
I picked one up recently hoping that I could migrate a lot of my ebooks and pdfs to it. I don’t plan on returning it, but I wouldn’t recommend it.
I was a huge fan of the kindle dx, but I’ve managed to break the buttons on a couple which renders them practically useless. I was on the fence with the first remarkable device but figured I’d given the latest iteration a shot. I figured it’d be a good DX substitute. It’s not. I want to like it, the physical design is really good, but the software sucks.
I have a large collection of documents (epub/pdfs) that I was looking forward to getting on the device. Largely a mix of books published in electronic formats from regular publishers (O’Reilly, Manning, PragProg, etc.) as well as a few papers and docs I’ve picked up here and there.
First, the reMarkable desktop/mobile app that you have to rely on for syncing is a little wonky. Syncing between the device and mobile/desktop versions of the app works, but leaves a little to be desired. Second, I have yet to load a pdf or epub that isn’t brutally slow to navigate (just page by page). If the document has images or graphics (even simple charts and illustrations) it will affect navigation performance. Occasionally a document will load relatively quickly, and navigate reasonable well, only to slow down after a few page turns. Epubs tend to be a little more difficult to work with - particularly if you decide to change the font. All I have to compare this device to is my broken DX, which, everything considered, positively smokes the reMarkable.
It’s usable. It works alright for PDFs, less so for epubs. On the positive side, the battery life is quite good.
I agree with your analysis in most regards. Syncing a lot of ebooks and pdfs to it is not something at which it would excel by default. I have a large Calibre library, and I haven’t synced it over for that reason. However, it’s something I’m looking forward to investigating with KOReader, which supports the reMarkable.
I haven’t experienced the lag that you talk about, but can understand that that would be bothersome – though I definitely have experienced the “wonkiness” of the companion apps.
I don’t know. I’ve got a couple books that are both pdf and ePub, and the pdf version behaves a little better. You can also resize and change fonts for ePub doc, but not for PDFs.
Along these lines, another interesting observation I’ve made has to do with the way some kinds of text get rendered. In particular, I’ve encountered epubs with code listings that render fine in other apps and on other devices, but render horribly on the remarkable2 device. Interestingly, in some of those cases I will also have a publisher provided PDF that renders just fine.
Further, epubs and PDFs are categorized differently in both the app and the device. With epubs you can change the justification, page margins, line spacing, fonts, and font size. With PDFs you have fewer options, but you do have the ability to adjust the view (which is great for papers since you can get rid of the margins).
I don’t think so – from my playing around with ssh, there are definitely some epubs stored on device. I actually think the browser extension generates epubs, rather than pdfs which was surprising.
I own Gen 1 and Gen 2. I love the simplicity and focus of the device. It’s an amazing… whiteboard.
Note taking is not suuuper great. Turns out marking up a PDF to take notes actually isn’t that great because the notes quickly get lost in the PDF. It’s not like in real life, where you can put a sticky note to jump to that page. The writing experience is fantastic though. I have notebooks where I draw diagrams/ideas out. I like it for whiteboarding type stuff.
Reading is terrible. I mean, it works. Searching is painfully slow. The table of contents doesn’t always show up (even though my laptop PDF reader can read the TOC just fine). When you do get a TOC, the subsections are flattened to the top level, so it’s hard to skim the TOC. PDF links don’t work. Text is often tiny, though you can zoom in. EPUBs appear to get converted to PDFs on the fly and their EPUB to PDF conversion sucks. Though, I’ve found doing the conversion myself in Calibre is way better.
Overall, I like the device for whiteboarding. But it’s kinda hard to recommend.
Marking up PDFs works better in color, since you can pick a contrasting ink color. I do it in Notability on my iPad Pro (which is also great for whiteboarding / sketching.)
I was tempted by reMarkable when the first version came out, but I couldn’t see spending that kind of money on something that only does note taking and reading. I’m glad it’s found an audience though, it’s a cool device.
Turns out marking up a PDF to take notes actually isn’t that great because the notes quickly get lost in the PDF. It’s not like in real life, where you can put a sticky note to jump to that page.
So far the best experience I’ve seen for this is LiquidText on an iPad Pro. While you can write on the PDF as any other annotator, there’s also a lot of more hypertext type of features, like collecting groups of notes in an index, or writing separate pages of notes that are bidirectionally hyperlinked to parts of the document they refer to. Or do things like pull out a figure from a paper into a sidebar where you attach notes to it.
The main downside for me is that you do more or less have to go all-on on LiquidText. It supports exporting a workspace to flat PDFs, but if you used the hypertext features in any significant way, the exported PDFs can be very confusing with the lack of expected context.
I picked up the kindle edition and started running through it yesterday. I’m impressed! It’s not your typical node book. It’s a return to the kind and quality of book that O’Reilly /used/ to publish, and that I’d wish they’d return to. The brief introduction to micro queues and node states was enlightening. I’m really enjoying it so far
One of the things I’ve found to be most important is using neutral language in describing the context, options, and consequences. We tend to gravitate toward writing in “pros” and “cons” for every option. That can lead to intellectual dishonesty. We fool ourselves by looking hard for “cons” in the options we don’t like and much less hard at the options we like. Reverse that for the “pros”.
The result is usually a problem statement about how everything is awful, a few options where one looks amazing and the others are clearly awful, then a conclusion that says everything will be awesome. The truth is always messier.
I think this stems from early experience writing “pitches” for approval, funding, etc. It trains everyone to be a salesman.
This is why I don’t even separate my “consequences” section into pros and cons. A consequence should be a fact about the situation that will result. Objective. If stated plainly, all parties should agree “yes that is a consequence that will follow” whether they agree with the decision or not.
Whether a consequence is classified as a “pro” or a “con” is entirely about the relationship one has to the consequence.
Example:
System A will need to sustain 1,000 TPS for at least 5 minutes.
Not really exciting, right? Several parties could agree that 1,000 TPS will be required. (If not, then the disagreement stems from different understanding of the system or different assumptions about behavior. Good information to uncover!)
Is 1,000 TPS good or bad? That depends entirely on whether you like that number or not. If you like it, then you might regard that consequence as a “pro”. Someone else could rationally consider it a “con” based on their relationship to it.
And previously previously. I’m surprised I haven’t run across this recommendation before. I can think of a couple teams I’ve worked with in the past that could have really benefitted from this style of documentation. I’m going to see if I can introduce it to my current team.
I’ve been using OpenBSD on an apu4e2 (an upgrade from the Alix platform the author mentions) as a router / firewall for probably close to two years, and I’ve been totally happy with it. I hadn’t considered a pi since I assumed it was primarily Linux-only, and I’m not thrilled about Linux for my particular use case. FreeBSD on a pi sounds like a fun little project though.
Sublime Text is fast with just enough functionality for me to keep it open constantly. I use it as my go to scratch pad - notes, code snippets, etc. I don’t use it for coding much, but I appreciate that power. If I need to quickly format a chunk of json, or pop open some random source file, ST is my first choice. I hate to lean on an over used expression like “Swiss army knife”, but when I consider how much time the sensible regular expression support alone has saved me when I need to wrangle text and source, Swiss Army knife fits. I’m also a huge fan of the way it saves document state without prompting.
VSCode, on the other hand, seems like the defacto editor today for substantial JavaScript code bases or code bases that need (or want) additional tooling. I haven’t run into the plugin issues the author mentions, but I try to stay out of it if I can, so I’m not a heavy user.
However, I’ve spent more time than I’m willing to admit trying to get niceties like decent LSP support, or node debugging, or similar working in (spac)emacs and vim. 90% of what you want is there, but getting that last 10% is a time-sink. VSCode just works. It’s fast and impressive for what it is but I still find it still slow compared to … well … basically everything except IntelliJ or eclipse. One day I’ll probably get around to seeing how neovim integration works, but until then I’ll just hold my nose and pop open VSCode when I find myself spelunking in messy js projects.
I still can’t get myself to like VS Code. I know everything works on VSCode, but so does everything in my sublime and my bash terminal and a few other tools. Part of what bothers me about VS Code is that it wants to do everything for me, but it can’t. It will gladly give me a terminal. Even many terminals. But the terminal is not just as full-featured as, say, Terminator (or iTerm2 if you’re on a mac). VS Code is fast, with completion, with compiling, checks. But it’s not just as fast as sublime or IntelliJ. VS Code wants to do my Azure/AWS deployments for me. But it can’t do everything that I need from it. So by trying to do everything for me, it doesn’t give me the one thing that I needed from it perfectly. Maybe I’d find a great workflow if I used it for a month or longer. But I just can’t.
At work I use IntelliJ. I like parts of it, it packs a bunch of features that I find useful. But it’s a little slow sometimes, and sometimes wants to do too much. All in all, for the types of projects I’m working with, it does a good job.
But I always have a ST instance or 3 open on the side. My scratchpad. Simple demos/POCs that I just started and don’t yet want to fully commit to.
The desk seems a bit spendy to me. I noticed that once I became accustomed to standing, I rarely felt the need to sit down, so spending more on an motorized sit/stand solution seems … extravagant. I agree that wobbly desks suck, however even with the cheap desks that I’ve had (e.g., IKEA handcranked) I’ve not found this to be an issue.
The keyboard thing I take issue with though. Ergodox has basically ruined me for any other keyboard. I’d rather put more of my money there than in a high or even moderately priced desk.
I’d also recommend a single big monitor to a dual setup. I’m not a fan of the ultra wide monitors, but I also prefer them to duals. At the moment I’ve got an LG 43 and wouldn’t go back.
It’s pretty ironic that he goes straight from “don’t spend money on stuff you don’t need” to “I have a standing desk with motorized control to adjust the height” isn’t it…
I wanted a standing desk, as I’ve used them for years at Microsoft and enjoyed them greatly. You can get standing desks with cranks but I know myself well enough to know I would just be lazy and never adjust it up to standing height if I had one. You can, of course, purchase motorized adjustable standing desks for cheaper - but not by a ton.
Mechanical keyswitches aren’t about ergonomics.. it’s all about the feel. They just feel really good to type on! And there’s the aesthetic of fancy keycap sets, yeah. But speaking of ergonomics, this summer I have switched from a basic non-split Leopold to a split keyboard from aliexpress. It’s not tented and the case is made of acrylic layers, so I’m thinking about designing and 3D printing a bottom layer that would make it tented.
I have a vertical mouse.. in a drawer somewhere, was planning to use it in the office :) I only use my G603 at home because I’m not going to play Counter-Strike with a vertical mouse and switching between different mice for work and games is just too much.
I was thinking the same thing—he doesn’t understand mechanical keyboards, or maybe just doesn’t like the way they feel. But you’re right, they are not primarily about ergonomics. Rather, ergonomics are a side benefit to mechanical keyboards. With Cherry MX Blue or Clear switches, I can easily approach 150 wpm (depending on how much sleep and coffee I’ve had) because I’ve become accustomed to feeling where the tactile “bump” is in the switch and that means I don’t bottom out the keys when typing which will prevent RSI and other injuries from long-term use.
If you’re still in an office or a shared space at home and concerned about noise, I recommend the Cherry MX Brown switches. Still great for typing and coding, but not as loud so you can reasonably do things like take notes during a Zoom conference.
I had a couple tent/wedge things 3D printed for my ergodox and have been very satisfied. I found something online and just fired it off to someone on thingiverse.
The idea of this post came while I started learning Win32 apis for my work. MSDN does a good job of explaining the api but outside of that, a very little number of articles and blogs exist.
The Petzold book is outdated but remains a good reference if he’s doing strict Win32 for the UI an not relying on something like MFC. Richter’s ‘Advanced Windows’ is another that I found handy when - his message cracker macros gave me a much better idea of what MFC was doing early on.
Ugh. Vanilla Win32 is not something I’d be super excited to have to pick up today (or, for that matter, for the past 15 years or so.)
10 selling points, no downside, that’s fishy. No mention of the lack of static typing, for example. No mention of Kotlin or Scala. That sounds like someone who’s a bit too enthusiastic to acknowledge the shortcomings that any tool has.
The lack of static typing as a downside is, and will always be, subjective. As Rich Hickey famously says, “What’s true of every bug? 1) it passed your unit tests 2) it passed the type checker.”
Spec, as a structural testing mechanism, is I believe generally understood to be a preferable alternative to static typing, not an afterthought bolted on to appease devs that demand static typing.
My reading is that static typing isn’t a silver bullet. That’s an over simplification. See the video below for a bit more context surrounding that particular quote, and maybe some rationale behind clojure’s approach to typing and the role that Spec plays.
It’s amusing to me that people accept this as a critique of static typing in general rather than a critique of certain hilariously-bad type systems like that of C or Java.
I am trying to think of the last time I encountered a bug in a piece of software written in a language with a not-terrible static type system, but … I can’t think of one.
I mean obviously part of the reason I haven’t run into many bugs is that there just aren’t as many programs written using good type systems. Programs written in Haskell or OCaml or Elm still have bugs, but they only have certain classes of bugs. Just because you can’t get rid of every bug doesn’t mean it’s pointless to get rid of the ones you can, and Rich’s punchy quote seems to imply that this line of reasoning is invalid.
I see what you’re saying. And I agree that, on the surface, that quote seems like it’s dumping on static typing entirely, but I don’t think that’s the case. In the talk in which Hickey drops that quote he expands a on it a bit, to a degree that my simply slapping it into a response doesn’t do justice. You’re the Leiningen guy, you know Clojure, you’re presumably familiar with the talk.
My takeaway was that static typing, like unit tests, catches bugs. Certain classes of bugs (as you mention above). However, in some complex and complicated systems, those classes of bugs aren’t the primary concern. I’ve never worked in that kind of system, but I like what I’ve seen of clojure and I haven’t found this particular line of reasoning disagreeable.
You’re the Leiningen guy, you know Clojure, you’re presumably familiar with the talk.
Yep, I’ve seen the talk. It feels to me like he already decided he doesn’t like static typing because of bad experiences with Java and uses that experience to make straw-man arguments against all static type systems in general. I can imagine the existence of a system for which “bugs that no type system can catch” are the primary concern, but I’ve never encountered such a system myself. (I have worked with plenty of systems where the cost of the type system is higher than the benefit of squashing those bugs, but that’s a very different argument than Rich’s.)
Yep, I’ve seen the talk. It feels to me like he already decided he doesn’t like static typing because of bad experiences with Java and uses that experience to make straw-man arguments against all static type systems in general
I think it’d be really funny if he keynoted ICFP with a talk on algebraic effects and never mentions the talk ever again. Will never happen, but a guy can dream.
I’m pretty skeptical that anyone who “knows Haskell pretty well” would produce the “Maybe Not” talk. More generally, my experience is that anyone willing to invest the time and energy into learning Haskell tends to be more tuned-in to the actual tradeoffs one makes when using the language, and it’s clear that his emotionally-framed talking points overlap very little with what actual Haskell programmers care or think about. Of course, it could be the case that he does know the language pretty well and simply talks about it like a frustrated novice to frame emotional talking points to appeal to his Clojure true-believers, but this seems far-fetched.
IMO the “Maybe Not” talk gets more flak than it deserves. Function subtyping is a valid data representation and Maybe Int -> Intcan be represented as a subtype of Int -> Maybe Int. Haskell chooses not to allow that representation, and it is a way in which the type system is arguable incomplete (in the “excludes valid programs” sense.)
You’ll have to work hard to convince me that Rich Hickey was arguing on the level of critiquing the “function sub-typing” capabilities of Haskell’s type system vs. the more prosaic “static typing bad!” bullshit he falls back on again and again. Stated straightforwardly, his argument is basically “Maybe is bad because it means you will break the expectations of the caller when you need to introduce it to account for optionality.” And, I suppose it is in fact terrible when you don’t have a type-checker and depend on convention and discipline instead. So, Rich Hickey 1, static typing 0, I guess?
As to “Maybe Not” getting more flak than it deserves…yeah, we’ll have to agree to disagree. (And I’ll note here I’m really surprised that you in particular are taking this position considering how often I see you on here deeply engaging with such a broad variety of academic computer science topics, without needing to use strawmen or appeal to emotion to argue a position.)
For example, “Maybe/Either are not type system’s or/union type.” Okay. How do you even argue with that? I don’t even really understand what he’s trying to assert. Does he not believe the Curry-Howard correspondence is valid? For that matter, which type system? Will I get lambasted by the apologists for not understanding his super subtle point, yet again? Meh.
As to “Maybe Not” getting more flak than it deserves…yeah, we’ll have to agree to disagree. (And I’ll note here I’m really surprised that you in particular are taking this position considering how often I see you on here deeply engaging with such a broad variety of academic computer science topics, without needing to use strawmen or appeal to emotion to argue a position.)
Thank you! I should note that just because I deeply engage with a lot of different CS topics doesn’t mean I won’t flail around like an idiot occasionally, or even often.
For example, “Maybe/Either are not type system’s or/union type.” Okay. How do you even argue with that? I don’t even really understand what he’s trying to assert. Does he not believe the Curry-Howard correspondence is valid? For that matter, which type system? Will I get lambasted by the apologists for not understanding his super subtle point, yet again? Meh.
Let me see if I can explain this in a less condescending way than the talk. Let’s take the type Maybe Int, which I’ll write here as Maybe(ℤ). From a set theory perspective, this type is the set {Just x | x ∈ ℤ} ∪ {Nothing}. There is an isomorphism from of the maybe type to the union type ℤ ∪ {Nothing}. Let’s call this latter type Opt(ℤ). Opt(ℤ) is a union type in a way that Maybe(ℤ) is not, because we have ℤ ⊆ Opt(ℤ) but not ℤ ⊆ Maybe(ℤ). 3 ∈ ℤ, 3 ∉ Maybe(ℤ). Again, we have Just 3 ∈ Maybe(ℤ), and an isomorphism that maps Just 3 ↦ 3, so in theory this isn’t a problem.
The problem is that Haskell’s type system makes design choices that makes that isomorphism not a valid substitution. In fact, I don’t think Haskell even has a way of represent Opt(ℤ), only its isomorphism. Which means that we can’t automatically translate between “functions that use Opt(ℤ)” and “functions that use Maybe(ℤ)”. Take the functions
foo :: Maybe Int -> Int
foo Nothing = 0
foo (Just x) = x*x
-- I don't think this is possible in Haskell, just bear with me
bar :: Opt Int -> Int
foo Nothing = 0
foo x = x * x
Is map foo [1..10] type-safe? Not in Haskell, because map foo has type [Maybe Int] -> [Int] and [1..10] has type [Int]. Is map bar [1..10] type-safe? In a type system that supported “proper” union types, arguably yes! ℤ ⊆ Opt(ℤ), so map bar is defined for all [Int]. So maybe types emulate useful aspects of union types but, in the Haskell type system, don’t have all the functionality you could encode in union types.
Now there are two common objections to this:
Haskell has very good reasons for doing things this way. This is 100% true. But it’s true because Haskell has a lot of goals with this type system and being able to encode this particular union type requires us to have proper function subtyping, which would absolutely be a nightmare to combine with everything else in Haskell. But nonetheless shows that Haskell is only exploring one part of the possible space of type systems, and there are valid things that it chooses not to represent. “Proper” union types are one of these things.
You can easily write a shim function to make map foo type safe. This is usually people’s objection to this talk. And most of the time you can do this. But this is just a form of emulation, not reproducing the core idea. It’s similar to how in OOP you can “emulate” higher-order functions with the strategy pattern. But it’s not a perfect replacement. For any given emulation I can probably construct a example where your emulation breaks down and you have to try something slightly different. Maybe it doesn’t work if I’m trying to compose a bunch of fmaps.
This is why I think the talk is underrated. There’s a lot of genuinely interesting ideas here, and I get the impression Rich Hickey has thought a lot of this stuff through, but I think it’s hampered him presenting this ideas to a general clojure audience and not a bunch of type-theory nerds.
I don’t follow: map foo [1..10] wouldn’t even typecheck; it’s not even wrong to say it’s not typesafe (edit: and apologies if that’s what you meant, I don’t mean to beat you over the head with correct terminology, I just honestly didn’t get it). And while it’s well and fine that there’s an isomorphism between {Just x | x ∈ ℤ} and ℤ, it’s not clear to me what that buys you. You still have to check your values to ensure that you don’t have Nothing (or in the case of Clojure, nil), but in Haskell, because I have algebraic data types, I can build abstractions on top to eliminate boilerplate. Your Opt example doesn’t present as better or highlight the power of this isomorphism. Why do I even care that I can’t represent this isomorphism in Haskell? I’m afraid your post hasn’t clarified anything for me.
As far as the talk, I think that if he had some really interesting ideas to share, he’d be able to explain them to type theory nerds in the same talk he gives to his “core constituency.”
At this point, I have trouble considering the output of someone who, no matter how thoughtful they may be, has made it clear that they are hostile to certain ideas without justifying that hostility. There is plenty of criticism to be made of Haskell and type theory without taking on the stance he has taken, which is fundamentally “type theory and type systems and academic PLT is not worth your time to even consider, outside of this narrow range of topics.” If he was a random crank that’d be fine, but I think that because of his position, his presentations do real harm to Clojure programmers and anyone else who hears what he’s saying without having familiarity with the topics he dismisses, because it shuts them off to a world of ideas that has real utility even if it’s very much distinct from the approach he’s taken. It also poisons the well for those of us in the community who have spent serious time in these other worlds and who value them, which is a tremendous shame, because Rich Hickey does have a lot of great ideas and ways of presenting them intuitively. So regardless of how eloquently you may be able to translate from Rich Hickey-ese, what I object to fundamentally is his intellectual attitude, moreso than his ideas, many of which I agree with.
Thank you! I should note that just because I deeply engage with a lot of different CS topics doesn’t mean I won’t flail around like an idiot occasionally, or even often.
I don’t follow: map foo [1..10] wouldn’t even typecheck; it’s not even wrong to say it’s not typesafe (edit: and apologies if that’s what you meant, I don’t mean to beat you over the head with correct terminology, I just honestly didn’t get it).
That’s what I meant, it wouldn’t typecheck. Brain fart on my part.
And while it’s well and fine that there’s an isomorphism between {Just x | x ∈ ℤ} and ℤ, it’s not clear to me what that buys you. You still have to check your values to ensure that you don’t have Nothing (or in the case of Clojure, nil) … Your Opt example doesn’t present as better or highlight the power of this isomorphism.
Let’s try a different tack. So far we have
foo :: Maybe Int -> Int
bar :: Opt Int -> Int
Now I give you three black-box functions:
aleph :: Int -> Maybe Int
beis :: Int -> Opt Int
gimmel :: Int -> Int
foo aleph typechecks, as does bar beis. foo gimmel doesn’t typecheck. I think all three of those we can agree on. Here’s the question: what about bar gimmel? In Haskell that wouldn’t typecheck. However, we know that Int ⊆ Opt Int. gimmel’s codomain is a subset of bar’s domain. So bar must be defined for every possible output of gimmel, meaning that bar gimmelcannot cause a type error.
This means that because Haskell cannot represent this isomorphism, there exists functions that mathematically compose with each other but cannot be composed in Haskell.
Why do I even care that I can’t represent this isomorphism in Haskell?
Mostly this is a special case of function subtyping, which I don’t think Haskell supports at all? So if function subtyping makes your problem domain more elegant, it’d require workarounds here.
To be clear I understood your point initially about function subtyping being a thing that maybe Haskell can’t represent, and I apologize for making you come up with multiple creative examples to try to illustrate the idea (but I appreciate it)!
So if function subtyping makes your problem domain more elegant, it’d require workarounds here.
What remains unclear for me–if we’re treating this as a proxy for Rich Hickey’s argument–is how this demonstrates the practical insufficiency of Maybe, which is his main pitch. I am happy to acknowledge that there are all kinds of limitations to Haskell’s type system, this is no surprise. What I don’t yet understand is why this is a problem wrt Maybe!
In any case, thank you for the thoughtful responses.
Static typing, in my uninformed opinion, is less about catching bugs than it is about enforcing invariants that, as your application grows, become the bones that keep some sort of “tensegrity” in your program.
Without static typing your application is way more likely to collapse into a big ball of mud as it grows larger and none of the original engineers are working on it anymore. From this perspective I suppose the contract approach is largely similar in it’s anti-implosion effect.
However, type theory offers a whole new approach to not only programming but also mathematics and I think there is a lot of benefit we still haven’t seen from developing this perspective further (something like datafun could be an interesting protobuf-esque “overlay language” for example).
On the other hand, dynamic programming (I think) peaked with lisp, and clojure is a great example of that. A lightweight syntax that is good for small exploratory things has a lot of value and will always be useful for on the fly configuration. Doesn’t change that the underlying platform should probably be statically typed.
“In this article we have listed a number of features that positively separates Clojure from the rest.” well, seems like the author thinks they address scala as well as java in the article, even though it’s only named in the previous sentence.
Spec is no alternative to static typing, as far as I know. Isn’t it just runtime checks, and possibly a test helper? Scala and kotlin both have decent (or even advanced) type systems. I think some of the points are also advantages over kotlin and scala (repl and simplicity/stability, respectively), but the choice is not as black and white as depicted in OP.
Spec isn’t static, but it can provide much of the same functionality as a type system like Scala’s, just that it does so at runtime rather than compile time. In addition, it can be used to implement design-by-contract and dependent types and it can also generate samples of the specified data for use in testing. It’s not the same but it is an alternative.
Yeah #8 and #9 (and arguably #7) really are just downsides that are framed as if they were upsides. “There’s no static typing, but here’s what you can do instead!” and “The startup time is really slow; here are some ways to work around that problem!”
Clojure code can’t run without loading the Clojure runtime, which is implemented as an enormous pile of Java bytecode. A “hello world” in Java only has to load a single bytecode file, whereas a comparable Clojure program will have to almost all of clojure.jar before it can even begin to do anything.
That sounds like someone who’s a bit too enthusiastic to acknowledge the shortcomings that any tool has.
Immediately after reading the article, I agreed with this comment. After re-reading it more critically, I think the issue isn’t that he is too enthusiastic, as much as that isn’t the point of this. Outside of the brief jab in the second to last sentence (“that positively separates Clojure from the rest”), to me this doesn’t read as a comparison between all the potential successors, just something aimed at getting people interested in trying Clojure.
As someone who hasn’t written Clojure before, but really enjoys Lisp-based languages, I found it to be a helpful overview of the language. The fact that there are no negatives listed doesn’t deter me from believing the positives any more than if I was looking for a new computer and the specifications didn’t list out other companies that make a better product. It just makes me want to carry out his last sentence and see for myself:
… the best way to learn Clojure is to actually use it.
As a fan of static typing, I would not advertise Java’s implementation of it as a feature. More of an anti-feature. It doesn’t track whether or not a field or variable pointing at a reference type can be null or not. It doesn’t support algebraic data types.
For contrast, I would advertise the static type systems in Kotlin and Scala as features.
This hit the orange site yesterday, and one of the top comments for a while indicated that the real issue was less to do with the technology or language, and more to do the management and administration. Later discussion brought up fairly consistent descriptions of historical finance and management issues in New Jersey In particular.
I’m not in any position to agree or disagree, but in my experience technology and/or language aren’t always the most significant factor in a system that’s “falling apart”.
It’s been a while since I played FizzBuzz, so I coded it up in F# to compare how the two answers look:
let x=seq{0..100}
|> Seq.iter(fun x->
(match (x%3=0, x%5=0) with
|(true,true)->printfn "%s" "FizzBuzz"
|(true,_)->printfn "%s" "Fizz"
|(_,true)->printfn "%s""Buzz"
|(_,_)->()))
I don’t know. There’s nothing wrong with the C# code.
I tend to view languages differently now than I used to. So instead of asking if a language has $FEATURE_X, I tend to like just a few features can care more about the experience I get coding things. To me the F# code looks more enjoyable, while the C# looks tediouis. It works, but it’s like the language doesn’t want it to work. I don’t think I’d be recommending to C# coders to code this way. I’d rather have them switch over to F# and use OO concepts. That gives them a clear path towards FP if that’s what they want to end up doing. This looks like a little of everything.
I have friends that talk about C++ being functional. Just start using some consts! I have other friends fond of functional Javascript. These things to me always seem like sticking two things together that work but don’t look right.
I agree. Most modern languages are multi-paradigm and have ample support for both functional and OO constructs and styles. However, some languages lean a little more one way than the other.
C# code can be functional, but the language leans more OO. Also, C#, probably owing to its heritage, tends to be more verbose, and functional C# can look a little noisy compared to something like F#. The same can be said for Java and C++. Javascript is a different beast that occupies a unique space.
I love the trend towards adopting a more functional style in traditionally OO languages like C# and C++. I wish languages that lean a little more functional, particularly F# (and Elm), would gain more traction in general.
As an aside, I code in about a dozen languages or more, and I’ve learned enough new tech in my career that I don’t get very excited about programming languages and such.
Having said that, F# is fun. I’ve been using it since it was in beta, and it’s just a joy to play with. Because it’s fun, and because it also handles OO, I consider it first and foremost a training language. You can come here and code using any paradigm you’d like, then go through and by taking out the fp smells learn to be a better functional coder. I don’t get that from the C# code.
I just got mine the other day and I’m very impressed at the quality of this little machine given the $200 price tag. No VSCode, but emacs/spacemacs installs nicely. I haven’t done much other than to surf around and fire up emacs, but I don’t have any complaints. It’s a great little machine and better than chromebooks I’ve picked up for twice that price.
IMAP, at least, isn’t going away, just “basic authentication.” You’ll still be able to use it, but you won’t be logging in with a username and password. Instead, you’d need to use a predictably non-standard MS extension to oauth2 called xoauth. It relies on Azure and O365/Exchange and I didn’t find it to be difficult, but whether or not clients will adopt it is another matter.
I ran into this last month. I had to work on some IMAP integration recently with O365, and about a week after getting something working MS switched off legacy auth in my employer’s tenant. I had to switch over to xoauth2. The only difficult part was finding any information about how to do it. Microsoft’s documentation, given how much of it there is, is usually scattered and often hard to piece together.
My workplace did the same. Seems like the easiest way is to pretend to be Thunderbird, and use its client ID and secret.
I don’t know what this adds other than friction, but maybe that’s the point.
Using OAuth like this just doesn’t work. I thought corporations learned that during the rise of smartphones, when people were plucking OAuth credentials out of apps for fun.
I used client modules in go and node. Roughly, it consisted of setting up a new azure app, granting that app permission to use imap in the tenant, enabling oauth flows for the app, creating a principle (user)/client I’d/secret, granting O365 permission for the user. Then it was a matter of enabling imap access on the specific O365 user account/mailboxes, and finally granting the principle access to the boxes. There were a few powershell scripts mixed in.
It wasn’t obvious or documented and took some trial and error. This has been my experience for anything having to do with azure and integration with virtually any of Microsoft’s other cloud products: business central, o365, etc. It’s a time suck.
After all that, my understanding based solely on my admin’s findings is that IMAP is sticking around, at least for paying (enterprise) customers. However, vanilla, plaintext, basic auth goes away.
That’s not exactly how the mail is phrased:
That makes it sound like you can only use Outlook.
Also: do they even read what they’re writing? This is so user-hostile it isn’t even funny:
That’s the policy of the tenant. A lot of orgs completely disable POP/IMAP in Exchange, and just use OWA/EWS/MAPI. As stated, IMAP is staying if your org uses it, just with OAuth.
(The funny thing is Outlook doesn’t support the OAuth extensions to IMAP, so it’ll just be using EWS/MAPI.)
Mobile apps are usually using EAS instead of IMAP.
I agree totally agree regarding the user hostility bit. Just to be clear, my employer /is/ using O365 in an enterprise tenant.
In my case the integration service relied on IMAP with regular authentication. My admin read that they were going to disable IMAP on some tenants in the future, and the following week they did for ours. He re-enabled it, but the integration wasn’t able to authenticate.
After a day or two of spelunking though the MSDN nightmare we were able to piece together a process to get the oauth client credentials flow, suitable for integration because it doesn’t require manual consent, working against their tenant/O365. Works like a charm. Still IMAP, different auth scheme.
So you’re right, IMAP may be going away in general, but it’s alive and well in their enterprise environment. “Basic authentication” no longer works, at least for us.
Edit: I’m not using an outlook /client/. I’m using imap clients in go, node, and at least initially c#.
Wow! I didn’t expect this to get posted here. Neat.
Anyway, yes, user-hostile. But by now, I’m used to this attitude from The Enterprise. They brought the company I was working for and by God, we’re going to do things their way (for development, they’re doing The Enterprise Agile method, which is mostly the stuff on the right hand-side of the Agile Manifesto and ignoring the left hand-side).
You can re-enable these for your tenant. Microsoft is turning off access and pushing warnings to say the authentication protocol for IMAP and POP3 are not recommended. They want you to use a more modern authentication protocol to access their mail servers. I do not want to force our teams to migrate from the email apps they like, so I re-enabled the protocols tenant wide.
There’s always a proxy.
When they turn it off you don’t even get a warning. IMAP just stops working. The new auth method (pdf) isn’t difficult to work with, but whether or not non-MS mail clients will support it more broadly remains to be seen.
Neat way to present Caddy…but Sourcegraph itself looks pretty interesting. Does anyone have any experience with it to share? It looks like a great way to document and navigate a codebase.
Sourcegrapher here.
Yeah, some of our customers use Notebooks for onboarding new hires.
Before I joined I used it to monitor code containing the name of the CNCF project I was maintaining at the time. Since joining I’ve been using it for batch changes (https://about.sourcegraph.com/blog/batch-changes-ospo) and other tasks. If you have any other questions let me know her or our Discord.
One piece of software that I’m super grateful for lately is jless. It’s crossed my radar once or twice in the past, but recently I’ve needed to navigate big json responses while testing and evaluating different APIs and it’s come in really handy.
For JSON, another thing I like is
gronwhich flattens JSON so you can do things like:On a tip somewhere here I found the idea of making a
norgscript that isgron --ungronand that makes it even nicer to use.oh, that looks nice. Thanks for sharing!
When I see this kind of thing I genuinely have to ask, why not just plonk evil-mode or such on emacs and call it a day?
Because then I’d have to learn how to reproduce all of my configuration, custom functions, mappings, and plugins in emacs.
Because you need the whole of spacemacs (or one of its competitors) not just one keybinding mode to make Emacs info an IDE. After you’ve installed all that, it’s no longer low-latency. (This was one of the things that eventually made me give up on Emacs.)
Pretty much all vi emulations have infelicities, so if you have muscle memory for vi it’s advantageous to be using the real thing.
So is it that Doom/Spacemacs have inherent increased latency compared to vim/nvim or the addition of LSP modes to them causes this lag?
I ask because if I enable CoC , I see hiccups here and there in my vim (unstable) setup.
I remain a fan of Spacemacs. In my experience there was often a little lag even when using modes that didn’t rely on an lsp iirc, and even though it was lazy loading. I wouldn’t say it was slow, but it often wasn’t as responsive as my vim config, and that caused it to feel kind of heavy. I tried Doom, which seemed a lot quicker than spacemacs, but I don’t think it has the documentation that spacemacs has and quickly gave it up.
I switched to neoclide/coc.nvim with its lsp support last week, mainly out of curiosity, while I was tooling around with go source. I thought it worked out pretty good compared to my previous ncm/ncm2 setup. In both cases there was pretty noticeable startup lag that I wasn’t thrilled with but tolerated. I think it’s possible that the cause of that lag in the former was the addition of the LSP modes I’d installed, but I couldn’t say for sure.
I haven’t used lunarvim for more than a day but the startup and responsiveness I’ve seen are significantly improved compared to my older configs. lunarvim is lazy loading its language support like spacemacs, but it seems to do a better job.
The native compilation support in emacs HEAD (ant 28, when that lands) is also good at reducing editor jitter.
My experience(*) was that the Elisp interpreter was blocking on CPU. There’s only a single thread and it wasn’t fast enough to keep up with typing, once syntax highlighting & the rest was going on.
(* from a few years ago now, this predates the use of LSPs)
i’ve tried evil mode a time or two, and a full fledged spacemacs installation once. never stuck with it long, because it’s always felt distinctly less responsive than vim.
I caught this on the orange site and thought I’d give it a shot. I’m impressed. In 5 minutes I’ve already got a vim that’s behaving better than what I spent a chunk of last weekend tuning.
How about, “Four books professional server-side Python developers should read (and a few they don’t need to)”.
As a client-side C++ programmer, that list doesn’t do me much good, except for “High Performance Browser Networking” which is a killer read for anyone involved in HTTP-based APIs on either end of the wire. (And OK, I do write some utility scripts in Python.)
On the other hand, “Design Patterns” is a stone classic.
The stone cold classic is SICP, to the point of cliche but no less valid for it. It doesn’t have the instant for-my-job practicality boost that a style guide like “90 Specific Ways to Write Better Python” does, but it’s in another ballpark of depth.
@eatonphil I am curious if you had criticisms of it or if you think its lessons are just not nuts-and-bolts enough for your list.
It’s a perennial goal of mine to finish SICP. 😀 If someone is coming to this list and sees value in four top books, I can’t really recommend a book in the same category here that’s taken me years to finish. But for people who read a lot, of course you can give it a go.
I’m very much a PL nerd. As mentioned elsewhere, I’ve spent a lot of time programing in Standard ML (see ponyo on my github) and Scheme (see bsdscheme on my github). Forcing myself to spend years getting good at both has seriously improved my ability to write simple code.
But I also can’t really recommend that to most devs either because who knows if you’ll enjoy it. Doing what inspires you is the most important thing so you actually complete what it is you want to do.
Scheme and the art of programming by George Springer is almost the same material as SICP but in Scheme. Honestly if you have worked for years in ML or Scheme you probably don’t need SICP since it is a introductory level text.
I just picked this one up a few weeks back and have slowly been working through it. I’m surprised that I hadn’t run into it before then. It’s a textbook and it reads like a textbook, there’s no getting around that, but it’s accessible and seems to be a great intro to Scheme in general.
SICP is using Scheme too, isn’t it? I recall running across MIT being the recommended implementation, but I’ve had no problems with Guile, and there’s a language in Racket, too. I bounce between the Springer book, SICP, and Little Schemer when I’m not too busy. I’m in no rush, but I’ve found those three to be a great way to get acquainted with emacs/geiser & guile.
I’m in the same boat with SICP and similar books with an academic feel. If it’s not project oriented, it’s usually too hard for me to focus on.
I wish I could recommend books on other languages! But no book I’ve read on JavaScript (thinking JavaScript the Good Parts, How JavaScript Works), Go (there’s almost nothing here that’s not just reference), Java (Effective Java is massive and not all useful), or C++ (what, Meyers’ Effective C++?) is in the same category in terms of information density, being well-written, and still being applicable today. I’d be happy to take recommendations though for books not among these.
Thinking Forth (1984) and Writing Solid Code (1993) are two books that radically changed how I approached programming. Yes, one is about Forth, and one is about C, but I’ve found them applicable to more than just those two languages.
Edit: added years first published.
Fully agree on both and in particular that TF is applicable beyond Forth. Great book.
I wonder whether you might enjoy Elements of Programming and/or The Humane Interface (and here’s the bit I’ve quoted most often). Very different books, both of them insightful and hard. EoP is a C++ book that’s about C++ in the way TF is about Forth, THI is a UI book that uses phrases like “information-theorietic efficiency” instead of “at [famous company] we do this [this way]”.
Personally, my qualm wouldn’t be about the language, it would be about the domain. I haven’t read the books, but those 4 titles really are web focused. I’m sure lots of those translate to other domains, but it’s clearly not aimed as the general purpose developer who doesn’t yet know which domain they will tackle. No, this is for backend web developers.
Thus, your title should really be closer to: Four books professional backend developers should read. That way it’s more focused to your actual target audience.
My point is that it wasn’t intended to be backends focused. I haven’t read any really great books on JavaScript (but HPBN is clearly browser, not backend, focused). And I genuinely wish frontend developers I worked with knew more that’s covered in DDIA.
But I don’t pretend to speak for every domain of programming for sure.
It’s easy to for us to get myopic about stuff outside our domain.
Note that even here you seem to be implicitly assuming that not-backend = in-browser. That’s leaving out (native) desktop, mobile and embedded development.
I suspect there aren’t actually any books that are super important for all serious programmers. The books I learned the most from are way out of date (K&R, the Smalltalk-80 Blue Book, Advanced Cryptography) or very domain specific (Unix Network Programming) or both (Inside Macintosh.)
Yes I’m definitely missing domains but mobile isn’t one of them! HPBN devotes a ton of time to the effect of protocols on mobile battery life of all things. There’s a chapter or two on the behavior of mobile networks. Mobile developers are also responsible for monitoring and alerting on their production deploys. And they’ll also be heavy users of backend systems.
All this isn’t to say that I’ve got the list perfect. I hope I change my mind on it over time as I’ve read new books, learned new things, and expired different domains.
I feel The Go Programming Language is quite good; certainly more than just a reference.
The Little Schemer is probably the best programming book I’ve read. While it’s quite limited in scope (functional programming in Scheme), it does explain it in such a way that’s very insightful and useful for other languages too, IMO. And the writing style is just fun!
It’s not bad. And certainly new Go developers would do well to use it as a style guide since writing “idiomatic” Go takes a bit. I’ll consider adding it to a future version of this post.
In the category of niche languages there is no shortage of gems. :) I haven’t read The Little Schemer but I’m working through The Little Typer at the moment. I’ve got a post in mind for a rundown of 6-8 Lisp books alone. But I wouldn’t consider recommending any of these to developers en masse (even though I believe programming in Scheme or Standard ML for a while helps you write simpler code).
I don’t think the value of The Little Schemer is in learning Scheme, but rather in learning recursion and functional programming, and Scheme is just the tool that explains these concepts. The reason I got it in the first place is because it came recommended to better understand JavaScript’s functional aspects.
I highly recommend Eloquent JavaScript by Marijn Haverbeke. It has a great style of writing and starts from some really nice computing basics.
Learn you a haskell has been transformative to me, for this reason
You Don’t Know JS was an excellent language-specific book back in ~2013 when I read it, and I think it’s been updated after that.
I do prefer more general books these days, now that I know enough languages well enough. SICP is a famous one, but I think How to Design Programs might be a more approachable similar book. Nb. I’ve only worked about halfway through it.
My copy of Effective Java by Joshua Bloch is 346 pages, are you perhaps confusing it with another? I found it useful, too. Some of it is a bit self-evident, but I opened my copy at a random page and read an item (46, pages 212-214, about for(:) compared to for(;;)) and still found it good.
It’s not a book on java, though. It’s for people who already know java, and who write or maintain large java programs, say 50kloc or more.
I dunno, I’m reading through Designing Data-Intensive Applications at the moment, and it feels pretty language agnostic. I’ve seen some snippets of bash, but that’s it. Definitely not Python-focused.
Language-agnostic, but server-oriented. That’s why I wrote “server-side”. As a client (mostly mobile) developer, I’m not much concerned with terabyte-scale data or with distributed algorithms that only make sense for clusters in a data center (because they assume latency is zero and uptime is 99% and all peers are trusted.)
I’m not dissing any of this, just pointing out the applicability is narrower than advertised :)
I’ve been really tempted to buy a remarkable2. But the reviews I see say it’s great for note taking but not so great for just reading PDFs. Mostly I want to read PDFs. I’m still on the fence.
As long as your PDFs don’t require color, it is 100% worth it. Definitely one of my favorite devices at the moment.
Same. In the month or so I’ve had one, it hasn’t caused me a single frustration (and I’m the kind of person who gets annoyed at the user interfaces of my own Apple products). It works exactly as advertised. Anyone who thinks it might be worth the price tag should watch a third party review video and check out the official and awesome list projects. It has been awhile since I’ve stayed this excited about a new device so long after buying it.
I picked one up recently hoping that I could migrate a lot of my ebooks and pdfs to it. I don’t plan on returning it, but I wouldn’t recommend it.
I was a huge fan of the kindle dx, but I’ve managed to break the buttons on a couple which renders them practically useless. I was on the fence with the first remarkable device but figured I’d given the latest iteration a shot. I figured it’d be a good DX substitute. It’s not. I want to like it, the physical design is really good, but the software sucks.
I have a large collection of documents (epub/pdfs) that I was looking forward to getting on the device. Largely a mix of books published in electronic formats from regular publishers (O’Reilly, Manning, PragProg, etc.) as well as a few papers and docs I’ve picked up here and there.
First, the reMarkable desktop/mobile app that you have to rely on for syncing is a little wonky. Syncing between the device and mobile/desktop versions of the app works, but leaves a little to be desired. Second, I have yet to load a pdf or epub that isn’t brutally slow to navigate (just page by page). If the document has images or graphics (even simple charts and illustrations) it will affect navigation performance. Occasionally a document will load relatively quickly, and navigate reasonable well, only to slow down after a few page turns. Epubs tend to be a little more difficult to work with - particularly if you decide to change the font. All I have to compare this device to is my broken DX, which, everything considered, positively smokes the reMarkable.
It’s usable. It works alright for PDFs, less so for epubs. On the positive side, the battery life is quite good.
I agree with your analysis in most regards. Syncing a lot of ebooks and pdfs to it is not something at which it would excel by default. I have a large Calibre library, and I haven’t synced it over for that reason. However, it’s something I’m looking forward to investigating with KOReader, which supports the reMarkable.
I haven’t experienced the lag that you talk about, but can understand that that would be bothersome – though I definitely have experienced the “wonkiness” of the companion apps.
My understanding is that epubs are converted to PDF before being synced? Is that actually the case?
It renders the epub to pdf for display but that’s all in-memory. It’s still an epub on disk.
I don’t know. I’ve got a couple books that are both pdf and ePub, and the pdf version behaves a little better. You can also resize and change fonts for ePub doc, but not for PDFs.
Along these lines, another interesting observation I’ve made has to do with the way some kinds of text get rendered. In particular, I’ve encountered epubs with code listings that render fine in other apps and on other devices, but render horribly on the remarkable2 device. Interestingly, in some of those cases I will also have a publisher provided PDF that renders just fine.
Further, epubs and PDFs are categorized differently in both the app and the device. With epubs you can change the justification, page margins, line spacing, fonts, and font size. With PDFs you have fewer options, but you do have the ability to adjust the view (which is great for papers since you can get rid of the margins).
I don’t think so – from my playing around with
ssh, there are definitely someepubs stored on device. I actually think the browser extension generatesepubs, rather thanpdfs which was surprising.Huh. Cool. Hmmm. The real reason I shouldn’t get one is that I always fall asleep with my e-reader and it often bounces off my face.
That’s a pro, for the device, it weighs next to nothing. I’ve damn near knocked myself out dropping an iPad Pro on my head when reading in bed.
For me, it’s more the fact that the Kobo then ends up falling onto the floor. I’m not crazy with that with a $120 device, so …
I own Gen 1 and Gen 2. I love the simplicity and focus of the device. It’s an amazing… whiteboard.
Note taking is not suuuper great. Turns out marking up a PDF to take notes actually isn’t that great because the notes quickly get lost in the PDF. It’s not like in real life, where you can put a sticky note to jump to that page. The writing experience is fantastic though. I have notebooks where I draw diagrams/ideas out. I like it for whiteboarding type stuff.
Reading is terrible. I mean, it works. Searching is painfully slow. The table of contents doesn’t always show up (even though my laptop PDF reader can read the TOC just fine). When you do get a TOC, the subsections are flattened to the top level, so it’s hard to skim the TOC. PDF links don’t work. Text is often tiny, though you can zoom in. EPUBs appear to get converted to PDFs on the fly and their EPUB to PDF conversion sucks. Though, I’ve found doing the conversion myself in Calibre is way better.
Overall, I like the device for whiteboarding. But it’s kinda hard to recommend.
Marking up PDFs works better in color, since you can pick a contrasting ink color. I do it in Notability on my iPad Pro (which is also great for whiteboarding / sketching.)
I was tempted by reMarkable when the first version came out, but I couldn’t see spending that kind of money on something that only does note taking and reading. I’m glad it’s found an audience though, it’s a cool device.
So far the best experience I’ve seen for this is LiquidText on an iPad Pro. While you can write on the PDF as any other annotator, there’s also a lot of more hypertext type of features, like collecting groups of notes in an index, or writing separate pages of notes that are bidirectionally hyperlinked to parts of the document they refer to. Or do things like pull out a figure from a paper into a sidebar where you attach notes to it.
The main downside for me is that you do more or less have to go all-on on LiquidText. It supports exporting a workspace to flat PDFs, but if you used the hypertext features in any significant way, the exported PDFs can be very confusing with the lack of expected context.
Agreed that it is hard to find notes. There should be a way to jump to pages that have notes on them (this is how Drawboard PDF works, for example).
What is the advantage over drawing on a piece of paper or on a whiteboard, then taking a photo of what you’ve drawn, if needed?
I tried paper note books, but I’m too messy and make too many mistakes. Erasing, moving, and reordering is hard on paper.
A whiteboard is pretty good for temporary stuff and erases better than paper. But, it can be a bit messy.
I also tried Rocketbook for a while. I got the non-microwaveable (yes you read that right) one. That was okay. A little meh for me.
And of course, you can’t read PDFs on any of these.
I picked up the kindle edition and started running through it yesterday. I’m impressed! It’s not your typical node book. It’s a return to the kind and quality of book that O’Reilly /used/ to publish, and that I’d wish they’d return to. The brief introduction to micro queues and node states was enlightening. I’m really enjoying it so far
One of the things I’ve found to be most important is using neutral language in describing the context, options, and consequences. We tend to gravitate toward writing in “pros” and “cons” for every option. That can lead to intellectual dishonesty. We fool ourselves by looking hard for “cons” in the options we don’t like and much less hard at the options we like. Reverse that for the “pros”.
The result is usually a problem statement about how everything is awful, a few options where one looks amazing and the others are clearly awful, then a conclusion that says everything will be awesome. The truth is always messier.
I think this stems from early experience writing “pitches” for approval, funding, etc. It trains everyone to be a salesman.
This is why I don’t even separate my “consequences” section into pros and cons. A consequence should be a fact about the situation that will result. Objective. If stated plainly, all parties should agree “yes that is a consequence that will follow” whether they agree with the decision or not.
Whether a consequence is classified as a “pro” or a “con” is entirely about the relationship one has to the consequence.
Example:
System A will need to sustain 1,000 TPS for at least 5 minutes.
Not really exciting, right? Several parties could agree that 1,000 TPS will be required. (If not, then the disagreement stems from different understanding of the system or different assumptions about behavior. Good information to uncover!)
Is 1,000 TPS good or bad? That depends entirely on whether you like that number or not. If you like it, then you might regard that consequence as a “pro”. Someone else could rationally consider it a “con” based on their relationship to it.
Edit: I forgot to mention that I previously wrote about this same advice in my blog.
And previously previously. I’m surprised I haven’t run across this recommendation before. I can think of a couple teams I’ve worked with in the past that could have really benefitted from this style of documentation. I’m going to see if I can introduce it to my current team.
I’ve been using OpenBSD on an apu4e2 (an upgrade from the Alix platform the author mentions) as a router / firewall for probably close to two years, and I’ve been totally happy with it. I hadn’t considered a pi since I assumed it was primarily Linux-only, and I’m not thrilled about Linux for my particular use case. FreeBSD on a pi sounds like a fun little project though.
Sublime Text is fast with just enough functionality for me to keep it open constantly. I use it as my go to scratch pad - notes, code snippets, etc. I don’t use it for coding much, but I appreciate that power. If I need to quickly format a chunk of json, or pop open some random source file, ST is my first choice. I hate to lean on an over used expression like “Swiss army knife”, but when I consider how much time the sensible regular expression support alone has saved me when I need to wrangle text and source, Swiss Army knife fits. I’m also a huge fan of the way it saves document state without prompting.
VSCode, on the other hand, seems like the defacto editor today for substantial JavaScript code bases or code bases that need (or want) additional tooling. I haven’t run into the plugin issues the author mentions, but I try to stay out of it if I can, so I’m not a heavy user.
However, I’ve spent more time than I’m willing to admit trying to get niceties like decent LSP support, or node debugging, or similar working in (spac)emacs and vim. 90% of what you want is there, but getting that last 10% is a time-sink. VSCode just works. It’s fast and impressive for what it is but I still find it still slow compared to … well … basically everything except IntelliJ or eclipse. One day I’ll probably get around to seeing how neovim integration works, but until then I’ll just hold my nose and pop open VSCode when I find myself spelunking in messy js projects.
I still can’t get myself to like VS Code. I know everything works on VSCode, but so does everything in my sublime and my bash terminal and a few other tools. Part of what bothers me about VS Code is that it wants to do everything for me, but it can’t. It will gladly give me a terminal. Even many terminals. But the terminal is not just as full-featured as, say, Terminator (or iTerm2 if you’re on a mac). VS Code is fast, with completion, with compiling, checks. But it’s not just as fast as sublime or IntelliJ. VS Code wants to do my Azure/AWS deployments for me. But it can’t do everything that I need from it. So by trying to do everything for me, it doesn’t give me the one thing that I needed from it perfectly. Maybe I’d find a great workflow if I used it for a month or longer. But I just can’t.
At work I use IntelliJ. I like parts of it, it packs a bunch of features that I find useful. But it’s a little slow sometimes, and sometimes wants to do too much. All in all, for the types of projects I’m working with, it does a good job.
But I always have a ST instance or 3 open on the side. My scratchpad. Simple demos/POCs that I just started and don’t yet want to fully commit to.
It is very fast and very nice.
The desk seems a bit spendy to me. I noticed that once I became accustomed to standing, I rarely felt the need to sit down, so spending more on an motorized sit/stand solution seems … extravagant. I agree that wobbly desks suck, however even with the cheap desks that I’ve had (e.g., IKEA handcranked) I’ve not found this to be an issue.
The keyboard thing I take issue with though. Ergodox has basically ruined me for any other keyboard. I’d rather put more of my money there than in a high or even moderately priced desk.
I’d also recommend a single big monitor to a dual setup. I’m not a fan of the ultra wide monitors, but I also prefer them to duals. At the moment I’ve got an LG 43 and wouldn’t go back.
It’s pretty ironic that he goes straight from “don’t spend money on stuff you don’t need” to “I have a standing desk with motorized control to adjust the height” isn’t it…
I wanted a standing desk, as I’ve used them for years at Microsoft and enjoyed them greatly. You can get standing desks with cranks but I know myself well enough to know I would just be lazy and never adjust it up to standing height if I had one. You can, of course, purchase motorized adjustable standing desks for cheaper - but not by a ton.
Mechanical keyswitches aren’t about ergonomics.. it’s all about the feel. They just feel really good to type on! And there’s the aesthetic of fancy keycap sets, yeah. But speaking of ergonomics, this summer I have switched from a basic non-split Leopold to a split keyboard from aliexpress. It’s not tented and the case is made of acrylic layers, so I’m thinking about designing and 3D printing a bottom layer that would make it tented.
I have a vertical mouse.. in a drawer somewhere, was planning to use it in the office :) I only use my G603 at home because I’m not going to play Counter-Strike with a vertical mouse and switching between different mice for work and games is just too much.
I was thinking the same thing—he doesn’t understand mechanical keyboards, or maybe just doesn’t like the way they feel. But you’re right, they are not primarily about ergonomics. Rather, ergonomics are a side benefit to mechanical keyboards. With Cherry MX Blue or Clear switches, I can easily approach 150 wpm (depending on how much sleep and coffee I’ve had) because I’ve become accustomed to feeling where the tactile “bump” is in the switch and that means I don’t bottom out the keys when typing which will prevent RSI and other injuries from long-term use.
If you’re still in an office or a shared space at home and concerned about noise, I recommend the Cherry MX Brown switches. Still great for typing and coding, but not as loud so you can reasonably do things like take notes during a Zoom conference.
I had a couple tent/wedge things 3D printed for my ergodox and have been very satisfied. I found something online and just fired it off to someone on thingiverse.
The 14k initial tcp window item he mentions is not something I knew about. Neat
The Petzold book is outdated but remains a good reference if he’s doing strict Win32 for the UI an not relying on something like MFC. Richter’s ‘Advanced Windows’ is another that I found handy when - his message cracker macros gave me a much better idea of what MFC was doing early on.
Ugh. Vanilla Win32 is not something I’d be super excited to have to pick up today (or, for that matter, for the past 15 years or so.)
10 selling points, no downside, that’s fishy. No mention of the lack of static typing, for example. No mention of Kotlin or Scala. That sounds like someone who’s a bit too enthusiastic to acknowledge the shortcomings that any tool has.
The lack of static typing as a downside is, and will always be, subjective. As Rich Hickey famously says, “What’s true of every bug? 1) it passed your unit tests 2) it passed the type checker.”
Spec, as a structural testing mechanism, is I believe generally understood to be a preferable alternative to static typing, not an afterthought bolted on to appease devs that demand static typing.
I don’t understand what the quote is trying to say. “Every bug” is still fewer bugs if type bugs are ruled out by a type checker.
My reading is that static typing isn’t a silver bullet. That’s an over simplification. See the video below for a bit more context surrounding that particular quote, and maybe some rationale behind clojure’s approach to typing and the role that Spec plays.
https://www.infoq.com/presentations/Simple-Made-Easy/
It’s amusing to me that people accept this as a critique of static typing in general rather than a critique of certain hilariously-bad type systems like that of C or Java.
I am trying to think of the last time I encountered a bug in a piece of software written in a language with a not-terrible static type system, but … I can’t think of one.
Awesome. I’ll take your word for it. What is a language with a not-terrible type system? Haskell?
Right.
I mean obviously part of the reason I haven’t run into many bugs is that there just aren’t as many programs written using good type systems. Programs written in Haskell or OCaml or Elm still have bugs, but they only have certain classes of bugs. Just because you can’t get rid of every bug doesn’t mean it’s pointless to get rid of the ones you can, and Rich’s punchy quote seems to imply that this line of reasoning is invalid.
I see what you’re saying. And I agree that, on the surface, that quote seems like it’s dumping on static typing entirely, but I don’t think that’s the case. In the talk in which Hickey drops that quote he expands a on it a bit, to a degree that my simply slapping it into a response doesn’t do justice. You’re the Leiningen guy, you know Clojure, you’re presumably familiar with the talk.
My takeaway was that static typing, like unit tests, catches bugs. Certain classes of bugs (as you mention above). However, in some complex and complicated systems, those classes of bugs aren’t the primary concern. I’ve never worked in that kind of system, but I like what I’ve seen of clojure and I haven’t found this particular line of reasoning disagreeable.
Yep, I’ve seen the talk. It feels to me like he already decided he doesn’t like static typing because of bad experiences with Java and uses that experience to make straw-man arguments against all static type systems in general. I can imagine the existence of a system for which “bugs that no type system can catch” are the primary concern, but I’ve never encountered such a system myself. (I have worked with plenty of systems where the cost of the type system is higher than the benefit of squashing those bugs, but that’s a very different argument than Rich’s.)
There seems be at least some evidence that he knows Haskell pretty well, he just doesn’t really publicize it.
I think it’d be really funny if he keynoted ICFP with a talk on algebraic effects and never mentions the talk ever again. Will never happen, but a guy can dream.
I’m pretty skeptical that anyone who “knows Haskell pretty well” would produce the “Maybe Not” talk. More generally, my experience is that anyone willing to invest the time and energy into learning Haskell tends to be more tuned-in to the actual tradeoffs one makes when using the language, and it’s clear that his emotionally-framed talking points overlap very little with what actual Haskell programmers care or think about. Of course, it could be the case that he does know the language pretty well and simply talks about it like a frustrated novice to frame emotional talking points to appeal to his Clojure true-believers, but this seems far-fetched.
IMO the “Maybe Not” talk gets more flak than it deserves. Function subtyping is a valid data representation and
Maybe Int -> Intcan be represented as a subtype ofInt -> Maybe Int. Haskell chooses not to allow that representation, and it is a way in which the type system is arguable incomplete (in the “excludes valid programs” sense.)You’ll have to work hard to convince me that Rich Hickey was arguing on the level of critiquing the “function sub-typing” capabilities of Haskell’s type system vs. the more prosaic “static typing bad!” bullshit he falls back on again and again. Stated straightforwardly, his argument is basically “Maybe is bad because it means you will break the expectations of the caller when you need to introduce it to account for optionality.” And, I suppose it is in fact terrible when you don’t have a type-checker and depend on convention and discipline instead. So, Rich Hickey 1, static typing 0, I guess?
As to “Maybe Not” getting more flak than it deserves…yeah, we’ll have to agree to disagree. (And I’ll note here I’m really surprised that you in particular are taking this position considering how often I see you on here deeply engaging with such a broad variety of academic computer science topics, without needing to use strawmen or appeal to emotion to argue a position.)
For example, “Maybe/Either are not type system’s or/union type.” Okay. How do you even argue with that? I don’t even really understand what he’s trying to assert. Does he not believe the Curry-Howard correspondence is valid? For that matter, which type system? Will I get lambasted by the apologists for not understanding his super subtle point, yet again? Meh.
Someone who was honestly and deeply engaged with the ideas he spends so much time critiquing wouldn’t be babbling nonsense like “you would use logic to do that, you wouldn’t need some icky category language to talk about return types” or “type system gook getting into spec”…god forbid!
I’ll give him this though: Rich Hickey is doing a great job of convincing the people who already agree with him that static typing is bad.
(Edited to fix some links and a quote)
Thank you! I should note that just because I deeply engage with a lot of different CS topics doesn’t mean I won’t flail around like an idiot occasionally, or even often.
Let me see if I can explain this in a less condescending way than the talk. Let’s take the type Maybe Int, which I’ll write here as Maybe(ℤ). From a set theory perspective, this type is the set
{Just x | x ∈ ℤ} ∪ {Nothing}. There is an isomorphism from of the maybe type to the union typeℤ ∪ {Nothing}. Let’s call this latter type Opt(ℤ). Opt(ℤ) is a union type in a way that Maybe(ℤ) is not, because we have ℤ ⊆ Opt(ℤ) but not ℤ ⊆ Maybe(ℤ). 3 ∈ ℤ, 3 ∉ Maybe(ℤ). Again, we haveJust 3∈ Maybe(ℤ), and an isomorphism that mapsJust 3 ↦ 3, so in theory this isn’t a problem.The problem is that Haskell’s type system makes design choices that makes that isomorphism not a valid substitution. In fact, I don’t think Haskell even has a way of represent Opt(ℤ), only its isomorphism. Which means that we can’t automatically translate between “functions that use Opt(ℤ)” and “functions that use Maybe(ℤ)”. Take the functions
Is
map foo [1..10]type-safe? Not in Haskell, becausemap foohas type[Maybe Int] -> [Int]and[1..10]has type[Int]. Ismap bar [1..10]type-safe? In a type system that supported “proper” union types, arguably yes! ℤ ⊆ Opt(ℤ), somap baris defined for all[Int]. So maybe types emulate useful aspects of union types but, in the Haskell type system, don’t have all the functionality you could encode in union types.Now there are two common objections to this:
map footype safe. This is usually people’s objection to this talk. And most of the time you can do this. But this is just a form of emulation, not reproducing the core idea. It’s similar to how in OOP you can “emulate” higher-order functions with the strategy pattern. But it’s not a perfect replacement. For any given emulation I can probably construct a example where your emulation breaks down and you have to try something slightly different. Maybe it doesn’t work if I’m trying to compose a bunch offmaps.This is why I think the talk is underrated. There’s a lot of genuinely interesting ideas here, and I get the impression Rich Hickey has thought a lot of this stuff through, but I think it’s hampered him presenting this ideas to a general clojure audience and not a bunch of type-theory nerds.
I don’t follow:
map foo [1..10]wouldn’t even typecheck; it’s not even wrong to say it’s not typesafe (edit: and apologies if that’s what you meant, I don’t mean to beat you over the head with correct terminology, I just honestly didn’t get it). And while it’s well and fine that there’s an isomorphism between{Just x | x ∈ ℤ}andℤ, it’s not clear to me what that buys you. You still have to check your values to ensure that you don’t haveNothing(or in the case of Clojure,nil), but in Haskell, because I have algebraic data types, I can build abstractions on top to eliminate boilerplate. YourOptexample doesn’t present as better or highlight the power of this isomorphism. Why do I even care that I can’t represent this isomorphism in Haskell? I’m afraid your post hasn’t clarified anything for me.As far as the talk, I think that if he had some really interesting ideas to share, he’d be able to explain them to type theory nerds in the same talk he gives to his “core constituency.”
At this point, I have trouble considering the output of someone who, no matter how thoughtful they may be, has made it clear that they are hostile to certain ideas without justifying that hostility. There is plenty of criticism to be made of Haskell and type theory without taking on the stance he has taken, which is fundamentally “type theory and type systems and academic PLT is not worth your time to even consider, outside of this narrow range of topics.” If he was a random crank that’d be fine, but I think that because of his position, his presentations do real harm to Clojure programmers and anyone else who hears what he’s saying without having familiarity with the topics he dismisses, because it shuts them off to a world of ideas that has real utility even if it’s very much distinct from the approach he’s taken. It also poisons the well for those of us in the community who have spent serious time in these other worlds and who value them, which is a tremendous shame, because Rich Hickey does have a lot of great ideas and ways of presenting them intuitively. So regardless of how eloquently you may be able to translate from Rich Hickey-ese, what I object to fundamentally is his intellectual attitude, moreso than his ideas, many of which I agree with.
Well understood from personal experience. ;-)
That’s what I meant, it wouldn’t typecheck. Brain fart on my part.
Let’s try a different tack. So far we have
Now I give you three black-box functions:
foo alephtypechecks, as doesbar beis.foo gimmeldoesn’t typecheck. I think all three of those we can agree on. Here’s the question: what aboutbar gimmel? In Haskell that wouldn’t typecheck. However, we know that Int ⊆ Opt Int.gimmel’s codomain is a subset ofbar’s domain. Sobarmust be defined for every possible output ofgimmel, meaning thatbar gimmelcannot cause a type error.This means that because Haskell cannot represent this isomorphism, there exists functions that mathematically compose with each other but cannot be composed in Haskell.
Mostly this is a special case of function subtyping, which I don’t think Haskell supports at all? So if function subtyping makes your problem domain more elegant, it’d require workarounds here.
To be clear I understood your point initially about function subtyping being a thing that maybe Haskell can’t represent, and I apologize for making you come up with multiple creative examples to try to illustrate the idea (but I appreciate it)!
What remains unclear for me–if we’re treating this as a proxy for Rich Hickey’s argument–is how this demonstrates the practical insufficiency of
Maybe, which is his main pitch. I am happy to acknowledge that there are all kinds of limitations to Haskell’s type system, this is no surprise. What I don’t yet understand is why this is a problem wrtMaybe!In any case, thank you for the thoughtful responses.
Static typing, in my uninformed opinion, is less about catching bugs than it is about enforcing invariants that, as your application grows, become the bones that keep some sort of “tensegrity” in your program.
Without static typing your application is way more likely to collapse into a big ball of mud as it grows larger and none of the original engineers are working on it anymore. From this perspective I suppose the contract approach is largely similar in it’s anti-implosion effect.
However, type theory offers a whole new approach to not only programming but also mathematics and I think there is a lot of benefit we still haven’t seen from developing this perspective further (something like datafun could be an interesting protobuf-esque “overlay language” for example).
On the other hand, dynamic programming (I think) peaked with lisp, and clojure is a great example of that. A lightweight syntax that is good for small exploratory things has a lot of value and will always be useful for on the fly configuration. Doesn’t change that the underlying platform should probably be statically typed.
Static typing is mentioned in section 8 in regards to the
speclibrary, and Scala is named in the Epilogue as a mature alternative.“In this article we have listed a number of features that positively separates Clojure from the rest.” well, seems like the author thinks they address scala as well as java in the article, even though it’s only named in the previous sentence.
Spec is no alternative to static typing, as far as I know. Isn’t it just runtime checks, and possibly a test helper? Scala and kotlin both have decent (or even advanced) type systems. I think some of the points are also advantages over kotlin and scala (repl and simplicity/stability, respectively), but the choice is not as black and white as depicted in OP.
Spec isn’t static, but it can provide much of the same functionality as a type system like Scala’s, just that it does so at runtime rather than compile time. In addition, it can be used to implement design-by-contract and dependent types and it can also generate samples of the specified data for use in testing. It’s not the same but it is an alternative.
Yeah #8 and #9 (and arguably #7) really are just downsides that are framed as if they were upsides. “There’s no static typing, but here’s what you can do instead!” and “The startup time is really slow; here are some ways to work around that problem!”
I read #9 as ‘by default, clojure is compiled, like java. But here’s a way to get instant(-ish) startup time, which is impossible with java.’
Being compiled has nothing to do with how fast something starts; planck is compiled as well.
That is, clojure’s startup time characteristics are similar to java’s.
uh … no?
Clojure code can’t run without loading the Clojure runtime, which is implemented as an enormous pile of Java bytecode. A “hello world” in Java only has to load a single bytecode file, whereas a comparable Clojure program will have to almost all of clojure.jar before it can even begin to do anything.
Immediately after reading the article, I agreed with this comment. After re-reading it more critically, I think the issue isn’t that he is too enthusiastic, as much as that isn’t the point of this. Outside of the brief jab in the second to last sentence (“that positively separates Clojure from the rest”), to me this doesn’t read as a comparison between all the potential successors, just something aimed at getting people interested in trying Clojure.
As someone who hasn’t written Clojure before, but really enjoys Lisp-based languages, I found it to be a helpful overview of the language. The fact that there are no negatives listed doesn’t deter me from believing the positives any more than if I was looking for a new computer and the specifications didn’t list out other companies that make a better product. It just makes me want to carry out his last sentence and see for myself:
As a fan of static typing, I would not advertise Java’s implementation of it as a feature. More of an anti-feature. It doesn’t track whether or not a field or variable pointing at a reference type can be null or not. It doesn’t support algebraic data types.
For contrast, I would advertise the static type systems in Kotlin and Scala as features.
There is little difference between Java’s type system and Kotlin’s type system.
Kotlin has literally the exact two features I just mentioned. Java does not.
Yes, and those two features do little difference – so it’s weird saying “Java bad, Kotlin good”.
Explicit nullability tracking is not a small deal. Never having to accidentally cause a NullPointerException again is liberating.
ADTs mean you can implement everything in the “make wrong states unrepresentable” paper.
That’s a bit like saying “look how crazy fast this 486 is .. compared to a 386!”.
Doesn’t Kotlin have algebraic data types and pattern matching?
Yes, barely, and no.
This hit the orange site yesterday, and one of the top comments for a while indicated that the real issue was less to do with the technology or language, and more to do the management and administration. Later discussion brought up fairly consistent descriptions of historical finance and management issues in New Jersey In particular.
I’m not in any position to agree or disagree, but in my experience technology and/or language aren’t always the most significant factor in a system that’s “falling apart”.
It’s been a while since I played FizzBuzz, so I coded it up in F# to compare how the two answers look:
I don’t know. There’s nothing wrong with the C# code.
I tend to view languages differently now than I used to. So instead of asking if a language has $FEATURE_X, I tend to like just a few features can care more about the experience I get coding things. To me the F# code looks more enjoyable, while the C# looks tediouis. It works, but it’s like the language doesn’t want it to work. I don’t think I’d be recommending to C# coders to code this way. I’d rather have them switch over to F# and use OO concepts. That gives them a clear path towards FP if that’s what they want to end up doing. This looks like a little of everything.
I have friends that talk about C++ being functional. Just start using some consts! I have other friends fond of functional Javascript. These things to me always seem like sticking two things together that work but don’t look right.
My two cents, fwiw.
I agree. Most modern languages are multi-paradigm and have ample support for both functional and OO constructs and styles. However, some languages lean a little more one way than the other.
C# code can be functional, but the language leans more OO. Also, C#, probably owing to its heritage, tends to be more verbose, and functional C# can look a little noisy compared to something like F#. The same can be said for Java and C++. Javascript is a different beast that occupies a unique space.
I love the trend towards adopting a more functional style in traditionally OO languages like C# and C++. I wish languages that lean a little more functional, particularly F# (and Elm), would gain more traction in general.
As an aside, I code in about a dozen languages or more, and I’ve learned enough new tech in my career that I don’t get very excited about programming languages and such.
Having said that, F# is fun. I’ve been using it since it was in beta, and it’s just a joy to play with. Because it’s fun, and because it also handles OO, I consider it first and foremost a training language. You can come here and code using any paradigm you’d like, then go through and by taking out the fp smells learn to be a better functional coder. I don’t get that from the C# code.
I just got mine the other day and I’m very impressed at the quality of this little machine given the $200 price tag. No VSCode, but emacs/spacemacs installs nicely. I haven’t done much other than to surf around and fire up emacs, but I don’t have any complaints. It’s a great little machine and better than chromebooks I’ve picked up for twice that price.
Have you tried the headmelted community builds of VSCode? They’re not official but they might work.