"used in my example above where we decided that us meant “unsafe string” and s meant “safe string.” They’re both of type string. The compiler won’t help you if you assign one to the other"
Assuming you have the luxury of a language with a good type system (either because it's designed for the task in hand or it's extensible), the compiler can help you, and you would be much better off having unsafe and safe strings as separate types. Then the encode function simply becomes a function of type unsafe -> safe. I believe Michael Snoymann touches on this in his presentation, "Designing Type-Safe Haskell APIs"[1].
I'm not arguing that Joel's method isn't a good idea. However, if you can it's better to leave hints for the compiler, not just the programmers.
This article is about pre-rendering a webpage to png, so anyone using a text-based browser would actually find the result even less useful than the original page.
If you're using the mouse, not having focus follows mouse means you have to click twice to activate something in a window without focus, which from my point of view as someone who uses focus-follows-mouse, is pointless and irksome.
When I'm not using the mouse, I change the focus with the keyboard (In my setup, focus follows mouse only when the mouse moves).
I found this to be one of git's greatest strengths; Beyond the basics, it doesn't force you to use features you don't need or want. Initially, I just committed snapshots in a single branch. Later, I found I wanted to do something experimental, so I learnt to branch, and so on…
Now, I would miss git's more advanced features if they weren't there, but when I started, I distinctly remember thinking, "For now, I just want to be able to change my code non-destructively, so I can easily revert it if I make mistakes". Git did that, and did it well.
I also round them up, but in doing so, it makes me think about the fact that the price doesn't reflect the 'value' of the product: If they hadn't rounded it to ₤X.99, would it have been more or less? How much of that is profit?…
Our local libraries recently started an ebook program. However, copyright restrictions mean they aren't allowed to loan a single 'copy' out to more than one person at once. With the relatively small number of ebook copies available compared to the number of library users, last time I checked there was a long waiting list for most books. Perhaps ironically, it is quicker to go to the library and borrow a paper copy. (The irony being that one of the advantages of ebooks over paper books is that you don't have to wait for them to be delivered)
Would it help if they were prepared in such a way as to make them unrecognisable? I know plenty of people who will happily eat mince, chops, etc., but who find it offputting if there are signs of where the meat came from, (e.g. a hog roast, fish/poultry with the heads still on).
That's the trouble with this article; With the dependence on buying everything in bulk (and somehow using it all up before it goes off), it appears to be more of a fun theoretical calculation than a practical weekly diet.
You'd have to walk for hours to check all the prices and work out the cheapest from various supermarkets though. Also, the more calories you burn walking across town to find, purchase, and carry home the very cheapest food, the more you need to eat...
> …hopefully they do it in a different way, doing the same thing twice is pointless.
I believe Newton said, "If I have seen further it is by standing on the shoulders of giants.", not, "I have rediscovered everything in a slightly different way because no-one gave me more than a vague method to go on"
It is no bad thing to have several independent implementations of an algorithm. If there is a problem with one, then the others are likely to show that there is a problem. However, without open source code, all you can do is say, "Mmm, something's wrong somewhere" and write another version. You may end up with several papers that agree and one that doesn't, but you still can't draw any conclusions without looking at the code. Ultimately, you get a situation where everyone has to repeat the same work and see what they get, when what they should be doing is poring over the original soources and discussing which bits could/should have been implemented differently and how that affects the result.
The code is part of the method. If you can't show us the code, don't expect me to believe your 'results'. That is science.
In addition to the other answers, don't forget that in the situation described, if you remove the 'thousands of unauthorized copies', you still haven't sold any copies.
In terms of semantics: "Say I write a book but nobody purchases a copy."
In more meaningful terms: If people do not value your book highly enough to pay you for it, then without the thousands of unauthorized copies, you are an unknown writer languishing in obscurity. With the copies, you have at least started to publicise your name and your message.
I think perhaps there is an increasing tendency to design one UI for every platform (touch screen tablets, desktops etc.) and to favour consistency across platforms rather than proper integration within each platform. So if right-click is difficult to emulate on a touch screen, then often the desktop version of a program available for touch-screen devices won't make good use of right-click either.
It is perhaps part of a larger trend to try and solve UI problems for tablets and phones, then push the solutions back to the desktop, despite the fact the desktop didn't suffer from the problem they attempted to solve.
This appears to be trying to solve a problem that doesn't exist with a solution that is more problematic than the problem it attempts to solve.
If my browser can handle pdfs, I probably want to view them using the browser[1].
If my browser can't handle pdfs, it will be forced to download them anyway.
If my browser can handle pdfs, but I want to save it/view it with another program, I can use right-click+save as.
By contrast, a pdf which I want to view in-browser, but which forces the browser to download it instead is just a nuisance. Even if there were a 'right-click+don't save it, just view it in browser', I don't know that I need to use it until I have tried clicking the link.
In general terms: You publish content on the web, I decide how I view it. Try to force my hand and you'll just annoy me into going elsewhere.
[1] If the browser supports pdfs by default, but I prefer to view them with somthing else, there are usually settings to tell the browser how to handle different file types.
It wouldn't read your .bash_profile, because it cannot. Any variables that are set by your .bash_profile will therefore not be set, and anything that depends on them being set may break.
There is a subtle hint that all is not well if you try to select the code using triple-click: it will only select one half at a time, suggesting it is not the one-liner it appears to be...
> There was an attempt to port homebrew to linux, but it didn't go far.
Linux already has more package managers than you can shake a stick at. To gain traction on linux, homebrew would have to offer useful features that other package managers don't have. Even then, people are more likely to copy the features into an existing linux package manager.
I don't think people tend to shop around when it comes to package managers; you use whatever your distro provides. If it sucks, you find a better distro or submit patches, depending how involved you are.
"used in my example above where we decided that us meant “unsafe string” and s meant “safe string.” They’re both of type string. The compiler won’t help you if you assign one to the other"
Assuming you have the luxury of a language with a good type system (either because it's designed for the task in hand or it's extensible), the compiler can help you, and you would be much better off having unsafe and safe strings as separate types. Then the encode function simply becomes a function of type unsafe -> safe. I believe Michael Snoymann touches on this in his presentation, "Designing Type-Safe Haskell APIs"[1].
I'm not arguing that Joel's method isn't a good idea. However, if you can it's better to leave hints for the compiler, not just the programmers.
[1] https://docs.google.com/presentation/d/1K7smIeqmca-fY8qgQUKr...