Xurinos
It removes the need for your fellow drivers to feel a tension when it is time to switch lanes, to not have to make a risky maneuver. You get to relax when driving because now you aren’t competing to get to your destination, and you can feel more confident others are not going to accidentally hit you in a desperate attempt to go where they are going.
That impatient driver behind you? They will get around you and play the rat race. Let them. Most drivers don’t do that unless you are much obviously slower than traffic flow. Let people win the game they are playing. You are making it generally safer, and your consistency on the road helps them make decisions easier.
I’ve been doing this for about 10 years. No accidents, no cause of accidents, no angry honkers, none of that nonsense. Try it for a week! Give others space to move. Watch traffic jams ease up a little around you. It’s very neat. My space clears spaces so I can move easier after people get in front of me. I’ve seen others follow my example (or be their own example).
In 2015, we continue to develop incorrect CSV parsing and production when there are ready solutions in the wild for the spec (http://www.rfc-editor.org/rfc/rfc4180.txt - 2005), such as Ruby's csv package, Perl's Text::CSV, CL's CL-CSV, and so forth. It's a solved problem. I quite understand this challenge, but this issue is important to me because this same print "%s,%s\n" stuff shows up in the wild from professional developers who have the time on their hands to use the right tool, some of which I have personally worked with. Perhaps, like in this challenge, they are under pressure to get their feature finished, and this is the first thing they think of because, after all, it's just "comma-separated values".
This challenge is especially amusing in that it, were it a real-world situation, involves people's financial welfare, and developers in a rush could very well have screwed it up. Isn't that cause for worry?
Fun specific example at the lock screen after holding down the iPhone's button for a couple seconds: "Read the latest message from my wife to me." Then, still at the lock screen, "Reply to my wife I love you".
Maybe it's just my experience, but I did not care much for Siri until she allowed me greater control over my device. When she first came out, you could not ask her to read the screen; later, the program was able to toggle assisting configuration like VoiceOver by command.
* Something only the user knows (e.g., password, PIN, pattern);
* Something only the user has (e.g., ATM card, smart card, mobile phone); and
* Something only the user is (e.g., biometric characteristic, such as a fingerprint).
Your example was two things that someone knows -- one factor.
Today's punctuation rules may have awkward beginnings, but the rules are standard, familiar, and subconsciously expected. This actually improves the speed at which I can read. The author's style had several places that were difficult for me because I have been mentally trained on one set of road signs and meanings.
Imperative OOP often feels like one is pivoting behavior around the data.
FP feels like the data is flowing from one transformation to the next.
There is the "functional" part of it, too... where functions are highly composable. One creates new functions by combining old functions, and these may carry along with them important context (closures).
2. From what I've learned of Haskell -- and I'm a Haskell noob -- it lets you work with the side effecty real world. You can alter your hardware state. The key is that it specifically flags such side effects and encourages separation between more "pure" code and code that is "tainted" with the side effects.
[1] OOP is an abstraction and compatible with pure FP. You can model your class instances such that they are immutable and get all the benefits of OOP. FP contrasts better with imperative programming.
Don't judge a book by its cover. Follow the money. A witty saying proves nothing.
I thought the notion of willpower being a finite resource was debunked (http://lifehacker.com/5967249/your-willpower-is-only-a-finit...). If you believe your willpower is finite, then it is finite; if you believe it is infinite and powerful, then it is infinite and powerful. This "finite resource" notion is a feel-good easy path out, a way to comfort yourself that it is okay that your will failed you because, after all, you only had so much.
I see this article confuses willpower with motivation. Willpower is what you use when your motivation has waned. Willpower is a tool to help you rekindle the fires of motivation or to press forward regardless because of an oath you made to yourself.
It comes down to what you believe, what mental constructs you have put into place, to inhibit or strengthen your willpower. You have the power to choose, every moment.
You're right. It's manipulation. Building consensus, too, is a form of manipulation. Some of it is irritating, especially if it is delivered in the form you quoted. My hackles rise, too!
From your comment, I am seeing that the real issue is when the manipulation is overt, when someone expresses something in a way that is clearly intended to push you in a direction rather than actually respect and accept your buy-in.
But that leads me to seeing that this really just another form of pathos. In a conversation, the average person wants to feel respected, that their opinion has merit. This is part of rhetoric. In fact, where action and tone are lacking, some people may genuinely need the additional words of appreciation that set you and me off. My point is that logos is not the only valid appeal, and I would propose that nobody is absolutely rational, meaning that degrees of the other forms of persuasion are acceptable and useful means.
To address your first point, all persuasion is manipulation. Somewhere I read that all speech is a form of persuasion, though the reasoning behind this assertion may be a bit contrived. Instead of elaborating on that point, I want to suggest instead that even if it is not "all", even if it is just "most", we could see instead that manipulation is not an evil in itself. Clearly there is nothing wrong with asking somebody where they would like to eat as your means to coerce them into joining you for dinner. Obtaining consensus or bringing someone to agree with you is not, itself, an evil or even irritating.
Armed with all the appeals of rhetoric and following these steps with respect to the audience's needs, I think the four steps listed at the top of the thread are acceptable means in polite society of persuasion, or, if you prefer, manipulation.
Addendum: I just tried the four steps. Was this post a successful example? Did I overdo it?
On the other hand, I did find that Skype over 3G was conclusively better-sounding than the regular AT&T voice stuff...when it did not lag out with weird chirps.
Is there a reasonable way to have trusted individuals intermittently audit the service?
If the brain receives noise, it fills in the blanks (http://www.sciencedaily.com/releases/2000/06/000601164617.ht...). In sensory deprivation, the brain also fills in the blanks (would cite but ended up finding a ton of supporting material in a web search, including an interesting study about the effects of anxiety on amount of hallucinations).
I would propose that deliberate practice (http://www.freakonomics.com/2011/05/04/deliberate-practice-h...) is more key than age (I could be goofing off for 40 years) and experience (I could be poorly repeating the same inefficient niche for a long time).
Always "git pull --rebase"; it is fast, easy, and meaningful. You can change the default configuration and probably should; same goes with other tools like emacs and vim.
Worried about date rearrangements? For those few situations where it is important, git log --since="$DATE_OF_LAST_TUESDAY".
Clojure:
user=> (cons 3 4)
IllegalArgumentException Don't know how to create ISeq from: java.lang.Long clojure.lang.RT.seqFrom (RT.java:494)
user=> (cons 3 '(4))
(3 4)
Common Lisp: CL-USER(1): (cons 3 4)
(3 . 4)
CL-USER(2): (cons 3 '(4))
(3 4)
CL-USER(3):C is a high-level language with fewer features than many other languages, is not necessarily the engine behind other languages, has the problem of its programs poorly implementing a percentage of what other high level languages are capable of doing quickly and securely, and provides slow and troublesome memory allocation out-of-the-box. When comparing the speed of operations, people are rarely comparing apples to apples. And contrary to what is spattered on the boards, C is not an understandable, close-to-the-metal wrapper around assembly instructions (compilers have advanced quite a bit).
I love C. It does feel fast, and I get the illusion of being close to the metal. It was one of my first languages, holding a sentimental place in my heart. Very important things are written in it. It is a high-level language with some okay abstractions.
Is it underneath other high level languages? Maybe, if you mean that the compiler might be written in C in order to bootstrap the language. Of course, one could write the compiler in any language; it's all about translating programmer-friendly symbols into assembly or VM bytecode, right? And speed of compile is a different subject from speed of the compiled program.
But here is the gotcha on raw performance: Your large C program poorly implements a percentage of what other high level languages are capable of doing quickly and securely.
I once foolishly argued in favor of C's performance, saying that one could write a layer that supports all these nice features speedily, such as the data structures I will mention below as well as GC; by the time you do that, you might as well be using a different language. You probably implemented that layer poorly, compared to other languages with large communities pounding at and optimizing that layer. For example, when you implemented your "fast" list with the basic struct and next pointer, did you also implement the new-node creation in such a way as it still uses raw malloc(), as opposed to managing previously-malloced memory efficiently?
How many implementations of a basic list do we need in C? Super large integers? Fixed-point integers? Growable arrays? Lazy/infinite lists? Trees? Hash maps? Surely you don't think these other language designers said to themselves, "Let's support hash maps and make them slow." No, they came up with a fast standard, supported by their language, sometimes complete with various configuration options to make all the tradeoff decisions on making those data structures speed-efficient or memory-efficient for reads or writes. Others, of course, subscribe to a religion, er, a specific tradeoff, such as perl's approach to {}s ("There's more than one way to do it" ... unless you are dealing with hash tables).
What about all the wonderful memory management you can do in C? Aren't you closer to the metal that way, able to make basic memory allocation super speedy? Not really. This is part of the illusion. malloc() is slow enough that developers have rewritten versions of it several times. ROM-based MUDs, for example, manage their own memory, using an initial malloc, of course, but regularly using their own set of allocators and deallocators (free_string, str_dup, etc) on top of that allocation. There are these tricks and more in high level languages, including the sharing of partial structures (kinda like union but with more pointers and fewer bugs associated with those pointers), allowing for resource allocation strategies that can be "faster than C".
If the argument in favor of C's speed at the end of the day is, "When we write crappy programs with buffer overrun holes, memory leaks, and no error handling, it's super fast!", we are (1) not comparing apples to apples and (2) doing ourselves and our customers a grave disservice.
Let's be honest: C is no "closer to the metal" than other high level languages (http://news.ycombinator.com/item?id=3753530 and https://en.wikipedia.org/wiki/Low-level_programming_language...). The days of manually XORing to assign 0 to a variable are well behind us.
Note... I don't mean all high-level languages. There are many very slow implementations of these languages. Programmers are getting better at this stuff in modern implementations, gcc included. And it is fair to say that there are many things other languages can do that are, when you compare apples to apples, faster than C, especially when you factor in modern JIT compilation; and they also do some things slower than a similar function in C.
No, C isn't and won't be obsolete, not until people write popular OSes in other human-readable languages, complete with a body of excellent libraries. We operate in a world of legacy, working code.
Edit: Looks like we both must have not read the article before replying. The author goes over many of these points.
People should be doing that when they design classes, but the flexibility tends to work against them. It could just be a mindset that makes it work well, and this might be a more appropriate approach for larger projects than for smaller types.
So what is the measure by which we are able to claim that some site's design is "bad"? I provide the counter: large, active userbase and a lot of money moving through ebay. Perhaps not enough money goes there? Do we think someone could create a competitor to ebay with a "better" site design and steal ebay's crowd? What role does site design actually play here?