HN user

Xurinos

1,510 karma

Admin for the Dark Mists MUD at http://www.darkmists.org (telnet to port 2222)

Posts3
Comments472
View on HN

To all the folks replying that someone will fill the gap in front of you: that’s the point. It isn’t about reaction time. It’s about letting traffic flow easier, not fighting with each other.

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).

CSV Challenge 11 years ago

That was an incredibly condescending answer.

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?

CSV Challenge 11 years ago

I am disappointed in this challenge on two levels: (1) A great many solutions fail to actually produce proper CSV: what would you do if any of the names or arbitrary credit card number inputs had quotes or commas in them? Big waste of time to roll your own, and you would have failed to prevent fraud likely without even realizing it. (2) Our JSON-dumping hackers didn't put quotes or commas in the strings to foil do-gooders.

I can't speak for the other two systems compared, but to be clear, OP's examples involve more than "dictation and simple searches"; Siri also controls the device. Without entering the text messaging or email apps, one can tell the virtual secretary to read and write messages and emails. Assuming Siri understands your voice well enough.

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.

This is not two-factor authentication. It is important to know what it means. From https://en.wikipedia.org/wiki/Multi-factor_authentication factors are:

* 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.

This sentence really clued me into my problem with the essay. As I read it, I found myself tripping over the sentences, especially this one. I had to reread it in order to understand what the author was saying.

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.

1. I think we should challenge the definition of "global variable". In what context is the variable global? The traditional definition is that the context is the whole program. However, in imperative OOP [1] code, I find that people just learned to hide their global variables in class instances. The whole program cannot access them, right? but every method in the class can and does, and all those mutations and side effects can lead to the kind of spaghetti code we all hated when there was no OOP. It's just global variables with extra sugar. And we can make copies of them, so the code is maybe one step better.

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.

Brief rant whenever I read this tripe, and reading it afterward reminds me of psychobabble, but I am ranting against psychobabble anyway...

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.

I believe you may be saying that if your goal is to make somebody say "Yes", then the toolset adequate for the job is one based around manipulation. One may manipulate through direct force, emotional means, whatever it takes. It is a waste of time and irritating -- perhaps condescending in that it is an obvious manipulation? -- to say things like, "Let me first say I've learnt a lot from you, I really appreciated your view on this that and that. I think you are smart person blablabla" before getting to the point. Like you said, it distracts from the actual important points of the argument. In fact, such an approach towards discussion is, as you point out, counter-productive.

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?

Android is better 13 years ago

While true, I happen to have both kinds of devices (updated, not old), and we found the Facetime experience MUCH less pixelated and less jumpy than the Skype experience over the same network, back-to-back. In further tests, the Google Hangouts and other Google video offerings were just as pixelated as our Skype calls. Skype is a solution, but here is was case where we could objectively say one approach was better.

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.

Every time I see the phrase "open source", I mentally add "but not open binary"; how do I know that the service that is run uses binaries that are compiled from that open source alone? with trusted libraries? After all, anyone can employ a site-specific patch in their build process that adds additional "features" to their normally open source project.

Is there a reasonable way to have trusted individuals intermittently audit the service?

Maybe the critical question is: If no light at all comes from the object, is that the same as it being dark, or is it a complete lack of stimulus?

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).

My guess: The object that does not reflect light to you ceases to exist in your vision. Nothing comes from that direction. Your brain would then attempt to compensate -- as it does for the blind spot in both your eyes -- and fill in the void, perhaps with a fuzzy version of continuity of whatever colors and textures surround the object.

Rebase is for cleaning up history. Merge is for introducing new features. Use the best tool for the job.

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".

The closest Clojure has to car/cdr is first/rest. It supports "cons" but only for creating sequences. Traditional Lisp car/cdr is one-location/other-location, and its cons puts together pairs of data. Often this is used for constructing sequences, but it is also often used for trees.

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):

Can you go into more detail about your architecture (a quick diagram of the connections between these components)? I am very interested -- my own dabblings have been leading me in this direction and firm belief, but I would love to learn from someone else's experience with it. Please feel free to email me if you prefer.

I guess I will be your essay-writing dissenter.

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.

SQL is Agile 14 years ago

Having done this for a while, I can solidly say that the relationships and structure of data has been consistently better when designed as a set of schema tables than as a set of classes because they are especially constrained. The constraints forced people to actually think about the relationships between facets of their data, and the resulting classes were much cleaner and more maintainable. Should we ever decide to move aspects of the classes into a database, the transition requires little code refactoring; this comes up fairly often for us, since we are trying to give users more customization powers.

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.

From someone who likes to look at these kinds of libraries... D3.js vs animation/graphics libraries: D3.js targets processes over arrays of data, perfect for designing views of data; these other libraries (like raphael.js, jquery.svg, etc) target transformations and tweening, perfect for objects in motion.

I agreed with your first post. I am also holding out for the thought that there are exceptions. Interestingly, this comment stood out to me: "That is mostly because eBay is a generally badly designed site. They have one of the most averse-to-change user bases on top of it, so bad decisions stick for a longtime." But they have a huge userbase. Transactions are happening. This is where my confusion kicks in... People claim a site has bad design, but a ton of users actively use the service. I would venture to guess that a large percentage of those users are not tech-savvy.

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?