Thrall
"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...
- Home, end, pgup, pgdown
- Delete
- Function keys that are just F-keys, not volume/brightness controls that act as F-keys when you press a 'function' modifier key.
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).
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.
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.
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 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.
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.
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's like a master-criminal's subtle and sophisticated plan being foiled by a simpleton because it assumed that the victims would be able to read.
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.
Bear in mind that it is in the jeweller's interest to perpetuate such superstitions as it means they can persuade many customers to buy a new ring instead.
Buying a diamonds as a romantic gesture, the buyer is vulnerable for two reasons:
1) They're unlikely to have much experience of buying jewellery; for many, this is the only occasion.
2) They probably feel very strongly about the gesture; it's very important that they get it right. Overspending pales beside the risk of offending the love of their life and/or subjecting them to negative judgement by their peers.
As a result, it is all too easy for jewellers to intimidate the buyer by telling them exactly what is 'expected' and charging absurd prices for it.
However, I think the advertising industry grossly exaggerates the importance of advertising.
The trouble is, it's impossible to ask, "Does advertising work?" and get a conclusive scientific answer. There are usually far too many other factors in play to be able to look at a company or product and say, "X failed/succeeded because they didn't/did advertise." Is X successful because they advertise? Could they have been more successful if they'd invested their ad-campaign funding elsewhere? Did Y fail because of lack of advertising or simply because they tried to sell a rubbish product? Did they even fail because they devoted too much of their budget to advertising, not leaving enough to properly develop their product?
If you have to chew gum to make up for this, you're starting to lose the simplicity which was one of the idea's main selling points. A bit like switching from cycling to work to driving to work to save 10 minutes, then having to spend an hour in the gym to make up for the lack of exercise.
I can't help thinking there will turn out to be many more subtle effects to compensate for. Yes, I am a sceptic.
It can't be because physical keyboards wouldn't have the key, because my keyboard doesn't display a # symbol, but that is widely used.
I can only guess that the character sets and "what characters are easy to type into a computer" became standardised early on, and no individual language has been able to push such a change (Early in development a language has few users, thus no influence; Later in development, the language has been using "->" itself for a while, so it's less easy to change).
Also, proper languages like lisp use parentheses (), not curly braces. :p
If we assume that the professional's fee is constant (doesn't depend on your income), then someone with very high income can waste only minutes on the task before it would have been cheaper to hire a professional, whereas someone with low income can devote a few hours to learning how to do it themselves and still make up for lost earnings by avoiding the cost of hiring a professional.
(I know the answer's no, I just find the idea interesting)