Programming's Dirtiest Little Secret - <AUTHOR> http://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret.html <comment><USER3> If Steve Yegge typed slower, I wouldn't have to read as much.

<comment><USER4> I just skipped down to the bolded text. Took about 10 seconds.

I'm sure he had something else important to say.

Maybe?

<comment><USER5> Ironically, he also said this:

"You'd be absolutely astonishedly flabbergasted at how many programmers don't know how to READ. I'm dead serious. You can learn to speed read even faster than you can learn to type, and yet there are tons of programmers out there who are unable to even skim this blog. They try, but unlike speed readers, these folks don't actually pick up the content."

<comment><USER4> I wonder if he had anything to say about people who wrote rambling, long articles?

Heck, I'm one of 'em!

</comment></comment></comment></comment><comment><USER6> Guys, could you please take a look at the project I am working on: <http://keybr.com> I thought it could be a good touch typing trainer web application.

<comment><USER7> It's nicely done! I'm not sure that I like the fact that the text doesn't mean anything... I guess it's in purpose so that you have to look at the words and not type mechanically for words you know but at the same time, I spend a lot more time figuring out what is going on...

<comment><USER8> The words are throwing me off. Not because I can't type them fast enough, but because I can't read them as fast as I type so I need to slow down and pay attention to the letters.

</comment></comment></comment><comment><USER9> I started hunt and peck typing at 5 (Apple //c represent!), and had evolved to a four finger lazy-look typing method by 7th grade typing class. I didn't start actually typing without looking at the keyboard until I purchased a factory defect keyboard from a computer fair when I was in 9th grade. This keyboard had no lettering ink on any of the keys. I remember my mom being in disbelief that I could look at her and type something else quickly at the same time.

Best $10 I ever spent.

Because I learned to type this way I have rather unconventional / poor form. My hands rarely center properly on the home row, I tend to use my middle fingers for the upper inside letters, and I don't always use the same fingers for the same keys (I type the first "e" in "letters" with my middle finger and the second with the proper finger).

One other positive side effect of that keyboard while I was exploring UNIX was that there was no value in looking at punctuation either, so I learned to touch type all punctuation, not just the secretary subset, at the same time.

<comment><USER10> I also have a 'modified style' when I use qwerty... via legacy of learning it on my own before being taught.

When I switched dvorak I figured I might as well do it right. As a side effect, my hands no longer hurt like they did with qwerty...

</comment></comment><comment><USER11> Three-word summary: learn to type.

<comment><USER12> Thank you

Edit: why is learning to type a dirty little secret?

<comment><USER13> I think the secret is that those who type slow are picking up speed by being hasty in their code decisions.

I'm skeptical, since far more development time is spent thinking about what to do than in banging out text to implement it.

And maybe some faster typists just emit more bad, buggy code.

<comment><USER14> I agree with you. If your bottleneck in development is typing speed you're doing something terribly wrong.

If it's a "lines of code" contest, then sure, learn to type fast, but if it's about producing good concise code I don't think typing speed makes much difference. If you want to program enough, you'll naturally become fast enough.

<comment><USER15> > If it's a "lines of code" contest, then sure, learn to type fast, but if > it's about producing good concise code I don't think typing speed makes much > difference.

In my experience, good, concise code is rarely written on the first pass. Also (and unfortunately), more often than not people who don't type well are unwilling to spend time on rewrites...

<comment><USER14> Good points.

</comment></comment></comment></comment></comment></comment><comment><USER16> Not looking at the keyboard as you type is important for secretaries who have to copy text off a hard copy. For a programmer I'd say it makes little difference.

But hey, don't let that get in the way of smug superiority.

<comment><USER17> Can you convince me you're just as fast if you have to look at the keyboard?

I bet you'd be faster if you didn't need to.

<comment><USER18> Can you convince me that the quality of a programmer has anything to do with speed?

(At least, to the degree that keyboarding skills would make a measurable difference. I'm not arguing that it's ok to spend all week building a single function.)

<comment><USER17> When you don't have to think what you're typing, your mind is free to think about the code. The more you think about your code, the better you are.

Image if you had to stop and think to use the mouse.

<comment><USER18> Ok, but not thinking about typing comes much earlier than being proficient in typing to the degree mentioned here.

Besides, I don't really think about kicking a soccer ball, but I certainly look at it when I do.

</comment></comment></comment></comment></comment><comment><USER19> I go by Andy Hertzfeld (Apple)'s credo: Your productivity can be measured in how many lines you REMOVE that week...

This is especially true with Lisp - you compact it down like one of those trash compactors.

[folklore.org]

</comment><comment><USER20> Personal request: next time Steve posts, let's just assume the "long post is long lololol" angle has been thoroughly covered, and let's discuss the contents. If the contents do not merit discussion, let's ignore them.

</comment><comment><USER21> > Hell, if you're having trouble, just email me, and I'll give you a > personalized pep talk. I can afford it. I type pretty fast. Plus your email > will be really short.

I'm tempted to email him just to find out what Steve Yegge's idea of a "really short" email is.

<comment><USER22> Hehe, good one, but I think he means the email that the can't-typers send _him_ will be "really short".

</comment></comment><comment><USER23> I learned something from this article; I can't touch-type numbers. After reading that part, I moved over to a friendly unused xterm and tried to type 65536. My head immediately began to bend down to gape at the keys. I tried not to look, but I couldn't do it.

Interestingly, I can type the symbols on the numbers just fine. (hello "world"). $here @are &some #sigils!

</comment><comment><USER24> I'm always a little surprised to find a programmer who can't type while looking at the screen. I never actually sat down and learned to touch type, it was a by-product of coding.

But this isn't just about programmers, you can see it in the movements of any expert.

Systems administrators know how to move around directories with minimal keystrokes - the characters seem to just fly by the screen. I know I'm in the presence of a good one when this happens.

A former colleague of mine proved that he'd spent many years in the trenches as a consultant through his mind-blowing ability to do excel. Any shortcut, he knew. He could set up a pivot table, create a LUT, denormalize data, simulate a query, set up scrolling, and automate charts in, like, 4 minutes. I could do this, but I'd have to hunt around the help, and it would take me a long time.

Good tennis racket stringers chat with you while they instinctively weave the crosses through the mains with a slight waving pattern that reduces friction and extends the life of the string job. They use the clamps and tensioner without really looking at it. I have my own machine and I can string a racket fine, but it takes me an hour and requires my full, fumbling focus - <USER2> certainly can't multi-task.

When a Judo expert falls backwards he/she just sort of rolls through it. No thought is necessary.

It goes on and on. Programmers type fast without thinking about it. It's one of the things they are simply able to do as the result of programming. I'm not saying it's critical, but it would be really odd to get good at programming without making this skill inate.

</comment><comment><USER25> Hmmm. I want to hear from some great programmers who are often here on HN. Do you guys type quickly? Paul Graham and Patrick Collison, are you speed typists? How about Ryan Davis and Jey Kottalam? Suggest some more great hackers, too.

<comment><USER26> I can't speak for them, but I've been able to type at ~80WPM for 20 years, since about age 10. I took Pascal and C in college 12 years ago, but to this day I'm a borderline useless scripter.when tasks call for a bit of Perl, Ruby, automated bash, or whatever.

</comment></comment><comment><USER27> Not being able to touch type is not a bad thing; not being able to type fast is. I can't touch type and I used to be able to type 130+ wpm without errors. I can still average around 100 wpm.

<comment><USER28> What's your definition of "not touch typing"? Do you use two fingers? Do you keep your fingers on the home row?

<comment><USER27> I was actually thinking of "touch typing" as being the standard method that is taught in schools and typing classes - put your fingers on the home row to begin and use all eight fingers to type.

I type by mainly using two fingers, with occasional pinkie and middle finger use. I also use my thumbs for the spacebar sometimes.

If you define "touch typing" as not having to look at the keyboard, then I guess I do touch type and I apologize to the author. I was mostly taking offense to the idea that there is only one correct way to type.

<comment><USER29> You do 130wpm with two fingers? Try using more, you'll do >200wpm easy!

</comment></comment></comment></comment><comment><USER30> Accoridng to Mythical Man-Month average programmer produces 2000 LOC per year. Other data I've seen backs this up. Typing speed is not really a problem.

<comment><USER31> Umm, nice rationalization. But that's 2000 lines of debugged, documented code. It takes a lot more typing than just 2000 x 80 characters. The article basically describes why.

Plus he's not talking about "average."

<comment><USER30> Even if you are 10 times the average that's coming out to 55 lines per day. Seriously, did you ever find your coding constranied by your typing speed?

<comment><USER31> Actually, often. Back when I used to write for school (with a pen) I always had the feeling of losing ideas because I couldn't write as fast as I could think. I don't feel it nearly as much when coding (or writing for that matter), I think because I type faster than I used to be able to write.

</comment></comment></comment></comment><comment><USER32> It frankly never occurred to me that any programmers _wouldn't_ know how to touch-type. How does that happen?

<comment><USER23> Remember that the set of "any programmer" is pretty big. It probably happens by not spending much time programming. Or by not noticing your bad habits.

I think most "kids" today can type pretty well because it's essential for IM- ing. I know that's how I learned to type quickly. Older people might not do much real-time communication, so they might not know how slow their ad-hoc typing is.

</comment></comment><comment><USER33> Although I already had a computer I was taught to touch type "properly" on a typewriter. It really did take just a few weeks to get totally proficient and it's been handy ever since.

The only time I've managed to make a significant boost was when I bought a Das Keyboard. Not having any labels on my keys means I have learned to absolutely never peak at the keyboard. It's improved my speed overall, but especially with the number row.

I have known a lot of programmers who don't type fast. I don't think it's a massive impediment, but I do think there's a strong correlation between bad programming and lack of typing ability.

I don't think any of the people I personally know and consider uber programmers type really badly. Certainly could be though and I just haven't noticed.

</comment><comment><USER34> _"... Yeev noticed that one of the electives, surely placed there by mistake, was Typing. Like, on a typewriter ..."_

What an elective? Mine was compulsory complete with manual typewriters and battle-axe teacher. One thing I do miss about those old clunkers was the solid feel the keys had. You had to learn to position your index fingers at 'F' and 'J' remember where each key was positioned and hit hard. So letters like 'P' and 'q' required a greater force than say 'v' or 'n' (because my index fingers are stronger than pinkies). Keyboards these days have no resistance so typing fast leads to random hits.

What's the most solid keyboard you have used?

<comment><USER35> I have an ancient Northgate with delicious feel. It's huge, and heavy, with some kind of mechanical switches that snick into place in the coolest way when you press a key. Feels like an IBM Selectric typwriter, if you remember those.

I haven't used it in years, since I now use laptops exclusively. I can't bear to get rid of it, though.

<comment><USER34> _"... It's huge, and heavy, with some kind of mechanical switches that snick into place in the coolest way when you press a key. Feels like an IBM Selectric typwriter, if you remember those ..."_

My last IBM model died. The Selectric model was good. Big & heavy I used these in undergrad for creating camera ready artwork. Are the laptop keyboards you use any good?

<comment><USER35> I've been disappointed with my MacBook Pro kbd. Usable, but not great. It helped a lot for emacs to remap the caps lock key to control. I also have an old Thinkpad T42 that I keep around for running Windows apps. The keyboard is quite nice, but I don't use it enough to have really learned it. Both are way behind the Northgate.

The old DEC VT220 dumb terminal had a nice feel, too, though nothing like the Northgate or Selectric.

</comment></comment></comment></comment><comment><USER36> I'm a two-fingers-and-a-thumb, look-at-the-keyboard, what's-the-home-row? typer, and I can still hit 70+ on a bad day. Still not sure what that has to do with 1) my ability to code, 2) my ability to communicate.

<comment><USER37> It's just an all-around upgrade to your personal ability. We all spend a lot of time at a computer. Why not try learning? The process of learning touch typing will make you better at two finger typing, if nothing else.

<http://www.freetypinggame.net/> <http://thepiratebay.org/torrent/3552142/Typing_of_the_Dead>

</comment></comment><comment><USER38> One of my co-workers types with his two pointer fingers and I'm sure he hits at least 80 wpm if not more. He looks at the keys on occasion, but he mostly does not need to. However, I get the impression his error rate is quite high.

All that being said, I think he could type even faster if he just bit the bullet and learned to touch type. This is why Steve is right. You might be a pretty fast typer already, but you can probably be a lot faster using all your fingers instead of just two.

</comment><comment><USER39> This is less an issue when programming in lambda calculus, if one takes the combinator approach and just uses S, K, and I.

I know, I can hear the complaints about the lack of good libraries...

</comment><comment><USER40> Does anyone else type on QWERTY but never from home row? I get 115wpm but with a disastrous 96% accuracy. The upside is much better access to the number keys and punctuation. I once tried to switch to Colemak, but never managed to completely switch over. I think this was because my muscle memory of QWERTY in 8 different positions was too powerful to unlearn.

</comment><comment><USER41> I actually don't know anyone that doesn't touch type that is under the age of 35 (but perhaps I need to pay more attention). Anyone that went and did an engineering level degree surely would be able to (due to thesis writing at least).

Even when I was in high school (back pre 1992) we learned by having a tea- towel over our hands and having to type without looking.

</comment><comment><USER42> i just realized that i may be a fast typist, but i use only 4 fingers. Left pinky for shift, ctrl,alt, left index for left letters, right middle finger for right letters, right thumb for space(sometimes left). I can type with a descent speed in two languages(English, Bulgarian) and i can even mix em and still type pretty fast. But i look at the keyboard pretty often and i my backspace key is the most clean one. This blog post has inspired me to just load KTouch and practice(KDE 4 came with a fast typing teacher, cool). I don't actually have a problem, because i make many mistakes, but i got really good at correcting them fast, so i still have a pretty good WPM count, haven't measured it, but its descent for a person who types a lot. I hope KTouch can help. After just 20 minutes with it i feel uncomfortable typing the way i used to, seems inefficient.

</comment><comment><USER25> This: <http://www.typeonline.co.uk/typingspeed.php> tells me I type at about 55 wpm with about one error. Apparently this sucks. Damn it.

</comment><comment><USER43> I can see his point, but most of my "typing" consists of pressing two or three keys, followed by M-/ so how much would it _really_ help to touch-type?

</comment><comment><USER44> He should not try to hard so be funny. He is not succeeding, he's just drowing his point in superfluous words.

<comment><USER45> That's like... just your _opinion_ man :)

</comment></comment><comment><USER37> Typing is by far the most useful thing I learned in school.

<comment><USER46> Really? Not math and/or English?

<comment><USER37> I had typing class in 6th grade. So I'll restate it as the most useful thing I learned in school, from 6th grade on.

</comment></comment></comment><comment><USER47> Incidentally, Steve brought up an interesting topic. Musicians practice by playing fast, then slow, then medium. Fast, slow, medium. Over and over. That seems like a good way to write software.

You first try to implement your idea as quickly as possible, stopping to think only when necessary. The goal is to not spend too much time overthinking the implementation -- you want to find out if your idea is worth executing on.

If you decide that your idea isn't worth it, then you move on to your next one. Otherwise you take it slow, going back over your code and refactoring it. (I personally don't believe in "make one to throw away", but rather that it's possible to refactor an ugly design into a succinct one.) At this stage, you should meditate on the best way to accomplish your engineering goals. It will pay off in the long run to spend extra time here.

Then comes the final stage in your project's lifecycle: medium. The core structure of the design has solidified, and you need to add the flourishes that make software truly great. But you have to take your time to ensure that the codebase stays clean. At this point, the design of the various smaller subsystems should flow naturally from the architecture you decided on in the "slow" phase.

Repeat for each core feature.

<comment><USER29> That's exactly where I thought he was going...

I just recently started writing software >40 hours a week, and have been constantly torn between "getting things done" and "doing things right". The best way to program well might very well be a variation between the two modes.

<comment><USER48> The mantra from eXtreme Programming:

1\. Make it work. 2\. Make it right. 3\. Make it fast. 4\. Make it small.

#1 first, then if you have the need, #2. If you have a need, #3. If you have the need, #4.

It's a lot easier to make it right once you've made it work.

<comment><USER49> Actually, it's a lot easier to make it work if you've made it right to begin with. (That said, I've always found the best way to develop is to add functionality to a working program, no matter how small it starts out).

<comment><USER48> There are a few problems with this:

1\. Sometimes, making it work is enough. (one time code and such) There's no reason, other than for practice, to waste time designing such cases.

2\. You may find out that you're solving the wrong problem, and it's much easier to justify throwing out code that you didn't labor over an extensible design, etc. It's much harder to throw away wrong code that you've put work into the internal design.

3\. This doesn't mean that you don't design the outward facing interfaces correctly. Thus, you have a good set of unit tests already set up, and you can quickly tell if something is working as you refactor. You have a good baseline with which to compare.

</comment></comment></comment></comment></comment><comment><USER50> My typing speed is about 75 wpm, which probably sucks by HN standards. I don't type nearly as fast as I think.

When I'm writing Java code, I find that my typing speed is often a bottleneck. In Ocaml or Lisp, it never is.

<comment><USER51> I find that when I'm doing Java, I'm not thinking or typing as much as I am hitting ctrl-space for the IDE to autocomplete superLongMethodNamesFactoryStubHome().

In Ruby, it seems I think and type in equal parts.

<comment><USER32> I remapped my Escape key to a more convenient place on my keyboard (it's a thumb key now); as a result, when I write Ruby code in TextMate, half of it appears virtually instantaneously. The downside? Sometimes accidentally pressing Escape when typing anywhere else. D'oh!

<comment><USER52> I keep threatening to get two foot pedals. One for CTRL and one for ESC. I think it would give me vim superpowers.

<comment><USER53> I have a pedal for my Kinesis keyboard, but I almost never use it. When I do use it it's for something like num lock... I tried it for Emacs ctrl and/or meta but it didn't work well. The big problem is that I don't keep my feet frozen in one spot for hours, so when I go to press the pedal I have to _find_ the darn thing by feeling around with my feet. You don't have to lose much time doing this before the point of the pedal is lost.

I could try to train myself to keep my feet in one spot. But I fear the ergonomic consequences. I have enough trouble with the need to keep my _hands_ in the same spot for hours on end...

Maybe I need much bigger pedals. Or special _shoes_...

<comment><USER54> What sort of pedal, how much did it cost, and where'd you get it?

I ask because my sister had this neat idea for a hardware hack: a digital music stand. The idea being that page turns really suck when you play any instrument that takes two hands (we're both violinists), and if you could hook it up to a foot pedal, you could control the music without putting down your instrument. I also pointed out that a digital music stand would cost at least as much as a computer, but now that you can get laptops for $98, this may be doable...

Plus, think of all the people on YouTube that you see lean over to stop recording. If it doesn't already exist, software to control a webcam through a foot pedal would be a great boon to YouTubers everywhere. The porn industry would love it too - that bra unclasp is so much sexier when she's not blatantly fiddling with her webcam.

<comment><USER55> Kinesis has their own foot pedals.

<http://www.kinesis-ergo.com/foot.htm>

There are a number of midi/usb pedalboards, but they have tons of pedals and are relatively expensive.

There are also a lot of DIY footswitch projects. Check this one out, it is for turning pages inside digital music stand software. :)

<http://www.instructables.com/id/USB-Foot-Pedal/>

Also, I used to be in orchestras. A Kindle for sheet music would be neat. Especially if it had built in metronome and tuner for practicing. Might take away some of the old-school ambiance though.

</comment></comment></comment></comment></comment></comment></comment><comment><USER56> If you need to type that much, to where whether or not you can touch type matters . . . you are doing something wrong. Saying touch typing matters amounts to stating that programming is actually carried out ON THE SCREEN YOU ARE TYPING ON and I could not disagree with that more . . . programming takes place in the mind of the programmer, typing on the screen is a byproduct.

I can't wait to see how his argument holds up once we have brain to computer interfaces that allow us to skip typing altogether.

<comment><USER23> _programming takes place in the mind of the programmer, typing on the screen is a byproduct_

As he says in the article, the actual programming is not what requires much typing. It's communicating with others on IRC (or e-mail, whatever you kids use these days), typing documentation, writing blog posts, etc. that require typing skills.

I will agree with him on this. I don't type much when actually programming, but I do type a lot when talking with people on IRC (including co-workers, since we all work from home) and writing documentation. And writing HN comments :)

<comment><USER57> So touch typing let's you procrastinate more efficently? ;)</comment></comment></comment>


The "Outside the Box" Box - <AUTHOR> http://www.overcomingbias.com/2007/10/outside-the-box.html

<comment><USER2> you're always in a box. being aware of the box can help you tremendously. it's when you think that you've left the box that's dangerous, because you're still in the box, but now you don't know it.

<comment><USER3> You're always in a box, but it's not necessarily a cubic box, and it usually has more odd nooks and crannies than you'd expect. Most people restrict themselves to a certain well-explored subset of your problem space. The trick is to explore the rest of it.

And this analogy is overextended and cliché. Let's move on and find better analogies.

<comment><USER2> of course exploring the box from the inside can never tell us if the box is bright purple and unusually shaped, because there is no outside to stand in. if aliens ever come along, they might tell us things that are along the lines of "well of course your box is purple how could you not see that?" and of course we'll be able to tell them that their box is lime green.

</comment></comment></comment><comment><USER4> People should stop associating neural networks with backpropagation networks. That is like saying all of AI is based on simplistic rule-based systems. I guess it is mostly people with only casual knowledge of both fields who make suggestions of that sort. Also, there is no reason to get outside the box. Most research and VC money tends to concentrate in one corner of the box. Go forth, be brave, and explore the box first!

<comment><USER5> I don't object to "backpropagation" aka gradient descent, which is a bit of simple calculus-based optimization. What I object to is the widespread public perception that saying "neural networks" is a brilliant new paradigm- overthrowing Key to General Intelligence, after over three damn decades.

Biologically inspired stuff? I applaud it to the extent that it works. It's not a magic key to anything, and it doesn't avert the challenge of understanding.

<comment><USER2> it also seems the surest path to producing an intelligence that acts as if it were a product of natural selection, i.e. one that is selfish, xenophobic, etc. (other sexual competition based heuristics).

</comment></comment></comment><comment><USER6> Considering that the backpropagation and variants thereof gained significant commercial/industrial adoption while "monkey and banana" type problem solving systems mostly failed, I think his criticism of artificial neural networks is quite unwarranted.

The entire change has been that people _aren't_ trying to go for 'general intelligence'. They approach it purely as a statistics problem. We have some data, what can we do with the data, how accurately can we do that?

</comment><comment><USER7> You know, our box is made of billions of tiny vibrating geometric figures. The box is weirder than we thought.

</comment><comment><USER8> not this guy again

/not a fan of this author

<comment><USER5> Why can't everyone love me? Why, why, why?</comment></comment>


Dimension Independent Similarity Computation (DISCO)  - <AUTHOR> http://engineering.twitter.com/2012/11/dimension-independent-similarity.html

<comment><USER2> Link to full paper: <http://arxiv.org/abs/1206.2082></comment>


SF Hackerhouse has open rooms come April 1 - <AUTHOR> http://arram.posterous.com/sf-hackerhouse

<comment><USER2> Sadly, I'm one of the guys moving out (cross country move for/with the girlfriend). This place is in such an insanely amazing location, though. Highly recommended.

</comment><comment><USER3> For a brief moment I considered abandoning my wife and son to go live here, be a badass hacker for the next year, kick ass in the next YC offering with a co- founder I meet here, then travel the world using rent-a-couch with my Mac PB always close by, releasing one cool version of our sw after another _while_ keeping a widely-quoted blog.

Then reason prevailed (sigh).

</comment><comment><USER4> Just total curiosity, but how many people typically live at Hacker House and how much shared/common space is there?

<comment><USER2> For the last year it has been 5 people in 5 rooms (though 2 people share 1 bedroom), so 1 room is left for a big shared office. There's a middle living area, 2 bathrooms, a kitchen, and roof access.

</comment></comment><comment><USER5> Are there other similar hacker houses in other locations? NYC?

</comment><comment><USER6> It's hard to tell which of the photos are referring to which rooms. Is the 'closet' room pictured there?</comment>


Breathing Supernova - <AUTHOR> https://www.theregister.co.uk/2019/08/16/largest_supernova_explosion/ <comment><AUTHOR> "... The flares are separated by 100 days followed by a gradual decline, where the supernova rests for about 650 days before the pattern is repeated again. Spectroscopic data shows that it emits mostly calcium and oxygen "</comment>


How to represent strings, the heavy way - <AUTHOR> http://finger-tree.blogspot.com/2010/11/my-strings-can-beat-up-your-strings.html <comment><AUTHOR> It's funny, strings are one of the most often-used data structures, and yet people don't think about them as much as they think about more sexy things like hash tables. Strings are just part of the scenery. They deserve more glory. (Except for C strings, which need to die.)

</comment><comment><USER2> Has anyone ever created a robust Unicode string API that treats graphemes as indivisible units? I keep seeing libraries that force you to directly handle codepoints, making it your problem to be aware of which characters are combining and have to be kept together (which almost nobody has done their homework on) so as not to corrupt the text.

<comment><USER3> Would Perl's Unicode::Normalize module fit your bill? I believe Unicode::Collate uses it so that a single codepoint accented 'e', for example, sorts the same as 'e' with a combining accent.

<comment><USER2> That's similar. What I'd really like to see is a string API that doesn't let you separate the letter and the combining accent at all, whether it has a precomposed normalization or not (unless you dig all the way down to asking which codepoints a grapheme is composed from).

</comment></comment></comment><comment><USER4> > two equal strings will always be represented by the same pointer.

That's not right at all. Two equal strings /may/ be represented by the same pointer. Only if all strings are interned will this trick be useful and I don't know of any languages that intern all strings

Also, cache and branch prediction effects don't seem to be accounted for.

<comment><AUTHOR> Okay, two _interned_ strings will be represented by the same pointer. That doesn't complicate the comparison logic that much; the common case of interned-interned comparisons can be checked for first, and the branch predictor will get rid of most of the overhead of having an extra check in there.

This is similar to a trick for representing bignums on a 32-bit system. You can use the lowest bit of a 32-bit value as a tag: if it's zero, then the number is a 31-bit integer; if it's 1, then the number (with the low bit cleared) is a pointer to a heap-allocated bignum. The common case is that you're doing operations with numbers that fit in 31 bits, so the code for handling bignums is avoided by the branch predictor. (This works even better on a 64-bit system, where the common case is even more common.)

As for cache effects, I think the main issues there, for ropes, are tree depth and chunk size. You want the tree to be shallow (so as to minimize the number of potential cache misses before you reach the chunk you're looking for) and you want the chunks to be large enough that they get good cache locality, but small enough that you get fast insertion/deletion/concatenation/etc.

</comment></comment><comment><USER5> This type of data structure is sometimes called a "rope". (get it?)

<comment><AUTHOR> The list of textile-related terms which correspond to data structures includes string, rope, cord, yarn, weave, weft, thread, and even quipu. It's getting kind of ridiculous.

<comment><USER6> I looked all of these up; in doing so, the only quipu I could find is on what I believe to be your own GitHub page. Are quipus (or, to use the Quechua plural, quipukuna) something you devised, or are you borrowing the name from elsewhere?

<comment><AUTHOR> That would be my own contribution to the ridiculousness. See, I'm working on operational transformation based on this paper:

<http://bouillon.math.usu.ru/articles/ctre.pdf>

...and the author names every data type after something stringy. I wanted to continue the theme, but it took some serious Wikipedia digging before I could find something that was textile-related and not already taken. In retrospect, this was a bad choice, since I kept forgetting how to spell it. :-(

<comment><USER6> Most varieties of Quechua wouldn't spell it 'quipu' any more; that's the influence of Spanish orthography, where 'qu' meant 'k' and 'hu' meant 'w'. Most modern orthographies would spell it 'khipu', which might be easier to remember.

And for your future endeavors: twine, thrum, strand, and lisle are, as far as I know, unused.

</comment></comment></comment></comment></comment><comment><USER7> If you need to access a utf-8 string indexed by _character_ rather than byte you are probably doing something wrong.

<comment><USER8> You have an issue with fast text search?

<comment><USER7> If you aren't building an index ahead of time, you're writing a state machine, in which case you're better off treating it as bytes for efficiency and simplicity. (An array of 256 pointers vs a nearly unbounded dynamic map of pointers.)

If you are building an index ahead of time, just use byte offsets in your index instead of character offsets. You'll still be iterating through it from the beginning to build the index.

<comment><USER8> You can't treat its as bytes because you are than dependent on what the came before those bytes, which messes with your ability to skip ahead on a miss.

<comment><USER6> He's arguing that you don't need to skip ahead on a miss. If you're test some UTF-8 string for membership in some other UTF-8 text, then go ahead and compare the individual bytes even if they don't line up as characters.

If you use a fast text search algorithm like Aho-Corasick, you'll still get reliable and accurate fast text search, and while you will perform unnecessary checks against invalid UTF-8 sequences, you won't have to create extra data structures or use any other operations and the algorithm can be implemented in a way that's pretty straightforward. The convenience of that outweighs the benefits you'd get of using a larger, elaborate data structure.

<comment><AUTHOR> If you just need get-current-char and go-forward-n-chars operations, you can get those cheaply by having heavyweight strings implement an iterable API. (Yes, I know you also need the ability to iterate backward for Boyer-Moore, but that's also fairly straightforward.)

This is not an argument against heavyweight strings, but an argument for better programming languages.

<comment><USER6> Well, the other advantage to using language-provided ropes or some variation on it, especially in functional languages with the capability for parallel execution, is that the rope structures (i.e. trees) are similar enough to Steele's conc lists (c.f. Guy Steele's "Organizing Functional Code for Parallel Execution") that searching in parallel could be achieved with little to no extra work from the programmer, which when possible would be much better than straight Aho-Corasick on a byte array.

<comment><AUTHOR> What if you're searching for substrings which span more than one chunk? What you'd end up needing to do is make a monoid of Aho-Corasick automaton state transition functions, and use a parallel prefix method. Steele gives examples of this sort of thing in the talk you mentioned. He and Danny Hillis go into more detail in their classic paper:

<http://portal.acm.org/citation.cfm?doid=7902.7903>

If you combine this with heavyweight strings, you can get incremental and/or parallel string matching, but it's almost as easy to do on a byte array.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Related paper by Boehm:

[http://www.cs.ubc.ca/local/reading/proceedings/spe91-95/spe/...](http://www.cs.ubc.ca/local/reading/proceedings/spe91-95/spe/vol25/issue12/spe986.pdf)

If I recall correctly an implementation of "ropes" ships with the Boehm GC sources.

</comment><comment><USER10> Small nit: Ruby actually represents strings as mutable objects.

<comment><USER11> Which does cause occasionally hilarious but usually mind rendingly irritating to ferret out bugs, from time to time. Common Lisp strings are the same way (symbols in both languages being the immutable type).</comment></comment>


Ask HN: Why doesn't banana juice exist? - <AUTHOR> Just had a conversation with co-workers at the office... we are all equally puzzled how this is not a "thing" <comment><USER2> "There is no such thing as banana juice. Banana flavor comes from an oil that does not mix well with water. Normally it is imbued in the fatty flesh of the banana. You can buy banana acetate which has a banana-like flavor." \- first Google result

</comment><comment><USER3> It does exist and it's delicious. It's not common in the United States, but for the south east Asian countries I've visited it's commonly available along with other fresh juices.

</comment><comment><USER4> Mu.

[https://www.walmart.com/ip/Goya-Goya- Nectar-9-6-oz/142388990](https://www.walmart.com/ip/Goya-Goya- Nectar-9-6-oz/142388990)

<comment><AUTHOR> This needs to be standardized & vegan in your local Whole Foods imo</comment></comment>


Panasonic Now Forces You To Use Their Batteries - <AUTHOR> http://panasonic.jp/support/global/cs/info/dsc_battery.html

<comment><USER2> I used to think you should never buy OEM parts (for your car, your computer, etc). I thought the aftermarket could even provide superior versions of parts, or at least, the same thing for less money.

Then I got a job in hardware engineering. Now I _always_ buy the OEM part. Some examples:

* Remanufactured toner cartridges -- much more likely to contain toxic substances that can vaporize into the air when printing. And have fun guessing whether they stated the page counts accurately.

* Seagate HDDs vs. Apple HDDs -- same drive, right? Wrong. Apple writes custom firmware, based on extensive testing. You may recall the data loss issue that came out last year with these (Barracuda 7200.11) drives... but not with the Apple firmware.

* No-name Chinese Li-ion batteries. Tested them myself, and they outright lie about the mAh. They're also almost certainly less safe.

* Got Bosch platinum plugs for my VR6 Jetta. Better than stock, right? Wrong. Finally found a mechanic that truly understands the VR6, and the stock plugs (NGK) were chosen for a reason.

Other examples abound. It isn't worth your time trying to outsmart the engineers that made your device by going with a part made by someone with no accountability (no brand to protect, no phone number you can call, etc).

<comment><USER3> _"Now I _always_ buy the OEM part. Some examples:"_

I thought I would provide another example as this was one of those things that always amused me.

Back when my brother was alive, he was a Porsche enthusiast, he owned several at the same time (4) and his first love was his 944 that he raced.

Anyway, the door handles on a 944 are the same as a standard VW part, with one slight difference. One has "PORSCHE" etched into the plastic while the other didn't. A luxury that increased the cost of the part by nearly 15 times.

The funny thing was that with the 944 series, there were many non porsche parts used in the production of the car. The body was made by Audi (which we learnt one summer while stripping all of the noice cancelling rubber off the body... not a fun job)

</comment></comment><comment><USER4> If I would have read this story anytime before 2007, it would have angered me. But in the past few years, I've read about so many instances of poorly- constructed exploding batteries (most of which were from 3rd parties) that I have a hard time passing judgment on Panasonic for this.

<comment><USER5> But honestly, what do they care if a third-party battery explodes in the user's hand? IMO a better way to deal with this would be for the firmware to record when a third-party battery is used, but not prevent it; in this way, Panasonic could shield themselves from spurious maintenance requests (and lawsuits), while still allowing the camera's owner to ultimately decide how the camera is used.

This isn't unlike Apple's insistence on Apple-branded RAM being used in their machines; if you're having Mac problems, and you have third-party RAM installed, AppleCare will tell you to take a hike.

<comment><USER6> Product Liability Law in many jurisdictions requires manufacturers to correct problems when they become known. Some jurisdictions require the correction for already sold and shipped product (Hello, this is Panasonic. Send your camera in for firmware update.) Other jurisdictions only require correction for new sales (Those cameras will merely ship with the updated firmware).

In any event, recording when a third-party battery is used does not shield a manufacturer from liability. In fact, it will be excellent evidence for the Plaintiff that the manufacturer knew of the design defect, and failed to correct it. Furthermore, the manufacturer failed to adequately warn the consumer. Two counts lost by Panasonic.

<comment><USER7> But this implies there is a defect in the camera that causes the explosion. The defect, and product liability, is in the battery.

<comment><USER6> Not according to the law. The Plaintiff's lawyer will allege that the camera is defective where it does not have the necessary safety devices to accommodate third party batteries. Courts consider that a design defect. Manufacturers have a non-delegable duty to install safety devices in their products.

</comment></comment></comment></comment></comment><comment><USER8> Panasonic should have a certification process to allow 3rd party batteries that meet their safety standards.

<comment><USER2> What makes you think they can afford to do that? And enforce it. There are already numerous international standards (ISO, etc) on things like Li-ion batteries, which of-label manufacturers are happy to ignore, lie about, or just implement incompetently.

<comment><USER8> Panasonic wouldn't have to pay for it. The 3rd party manufacturer would go to a testing lab (recognized by Panasonic) and pay for certification.

Once they receive certification, they could be added to the approved vendor list.

</comment></comment></comment><comment><USER9> Lithium polymer batteries are no joke. They can explode and mess you up if you happen to be too close to them when they do. Panasonic is only trying to protect the consumers of their products.

</comment><comment><USER10> They could potentially let you downgrade to another firmware version that does not have this check. In that case you accept the liability if the batteries do explode.

</comment><comment><USER11> This seems like user-hostile behavior to me. It would stop me from buying one of their cameras.

</comment><comment><USER12> It also solves the problem of people keeping their digital camera for more than a year now that they have realized that they don't need twice as many megapixels.

Oh sorry - we don't make the battery for the 2008 model anymore, but the 2009 model with chrome fins (although the same imager) is on sale!

</comment><comment><USER13> Based on the comments I think Panasonic is within their rights here, but still I would probably not buy from them. I'll stick with cameras using rechargeable AAs.

Possibly somebody will figure out how to make a knock-off battery that the camera recognizes as genuine Panasonic, putting us back at square 1 again.</comment>


Thou Shalt Not Use Struct - <AUTHOR> https://medium.com/@ferd/thou-shall-not-use-struct-67dd62111167#.1o54k7q04 <comment><USER2> Title should really be: Thou shalt not use a struct whose members are defined in a header file.

Because the rest of the post drags on about encapsulation with the implicit assumption that use of private and public in classes is the only way to acheive it. What makes this assumption awkward is that the C++ class style actively encourages certain kinds of coupling which the article is crusading against, and the best means of encapsulation we have: using only opaque types in header files, is omitted.</comment>


The first GNU/Linux distribution with the kernel 3.0 (?) - <AUTHOR> http://gnuguitarinux.sourceforge.net/

<comment><AUTHOR> I know, linux 3.0 is not out yet, this is rc4, but anyway, its just for the fun :)

</comment><comment><USER2> Debian has had the RCs in experimental for a while now...</comment>


Pip -t: A simple and transparent alternative to virtualenv in Python - <AUTHOR> http://blog.zoomeranalytics.com/pip-install-t/ <comment><USER3> I don't really get what this is supposed to solve.

\- `virtualenv` works by creating an overlay of the `site-packages` in `$VIRTUALENV`, and change the shebang of scripts to use absolute path of python in the overlay. That way, not only do you get dependencies isolation, but you can also call directly your programs from outside the virtualenv and it will work.

What you propose is both bad practice (relative path in `$PYTHONPATH`) and rather annoying (you need to be in a specific directory to run everything). Trying to automate that will sure end up in pure hell!

\- As in "you need to `cd` to _this_ directory then run _that_

\- Or "WTF it worked on my machine when I was in this directory but now it doesn't"

<comment><USER4> Well as we mentioned, it's supposed to solve a situation where you don't want to use all the overhead of virtualenv.

The things you care about may be different from what others care about: I'm guessing don't care about Windows compatibility or you wouldn't talk about shebangs, and others may not find only running the scripts from the project root an issue (I don't for example).

Why is a relative path in the PYTHONPATH necessarily bad practice? It's not a rhetorical question, I am genuinely curious.

If you're happy with virtualenv then continue using it - all we have done is propose an alternative.

<comment><USER5> I'm curious, what sort of overhead are you seeing with virtualenv that leads you to use this/any alternative? I've used virtualenv + virtualenvwrapper on some seriously underpowered and low-on-space machines, and have really not noticed enough overhead to even make a blip.

<comment><USER6> I'm pretty certain virtualenv just changes some environment variables.

I found a writeup [1] on how to write your own virtualenv. It doesn't look like there's much overhead there.

I suppose one could justify not using virtualenv if they're on a system with limited resources or network access. I've known people who spent hours building a compiling python 2.7 from source on embedded systems because they rolled their own distro, and in that situation it would make sense to not want to mess with virtualenv if you just spent hours getting pip working.

1: [https://www.recurse.com/blog/14-there-is-no-magic- virtualenv...](https://www.recurse.com/blog/14-there-is-no-magic-virtualenv- edition)

<comment><USER7> My impression is that the benefit of this approach is that it fits the mental model of NPM and Bower. Being able to manage packages across your stack using the same kinds of steps feels... organized. The relative path issue, however, needs some more consideration.

</comment></comment></comment></comment></comment><comment><USER8> I'll use the opportunity to moan about the state of packaging in the Python world. Why, after so many years, there is no way for me to ship software written in python, in deb format?

I end up doing some real crazy stuff:

* build in docker

* using virtualenv /usr/local/mypackage

* then manually copy over the init scripts "cp /usr/local/mypackage/bin/* /usr/local/bin"

* and debianize "/usr/local/mypackage/" and "/usr/local/bin".

Except it doesn't work:

* I need root do create the venv in /usr/local.

* This technique copies garbage like "activate" script to bin.

* virtualenv ships its own python binary. If the python version on host differ, it won't work.

* The workaround is to rewrite the bin scripts.

Total mess. All I need is a deb with some bin scripts, and all dependencies bundled. Is it _that_ hard...

<comment><USER9> I tried a few things myself, like fpm[1], rpmvenv[2] and lately pex[3] - <USER2> so far, I haven't found something, that I would call solid _and_ simple. We have constrained deployment environments that do not allow most of the tools, that would ease the process on a development machine. Basically, I need a deb or rpm.

I have some hopes to wrap a pex into deb/rpm, but I would not call this approach simple.

That's unfortunate since Python is a wonderful language for many data-sciency tasks - Python makes things possible and pleasant, that would be a pain in other languages.

* [1] [https://github.com/jordansissel/fpm](https://github.com/jordansissel/fpm)

* [2] [https://github.com/kevinconway/rpmvenv](https://github.com/kevinconway/rpmvenv)

* [3] [https://pex.readthedocs.org/en/latest/](https://pex.readthedocs.org/en/latest/)

* Another tool: [https://github.com/spotify/dh-virtualenv](https://github.com/spotify/dh-virtualenv)

<comment><USER10> We use dh-virtualenv and it's working out pretty well for us so far.

</comment></comment></comment><comment><USER11> > Looking at Javascript, tools like npm and Bower provide the easy, reliable > and powerful package management capabilities which it feels like Python is > missing. The key to their success? Both tools download a copy of the right > versions of the right libraries, by default placing them in a special folder > directly within your project's directory.

Isn't this exactly what virtualenv does anyway? Plus, with virtualenv you don't have to muck around in your $PYTHONPATH and you can still choose which Python version is installed for each virtualenv.

This article doesn't seem to explicitly mention any, but what are the compelling reasons to use pip over pyenv/virtualenv for project isolation? I guess using 1 tool to install dependencies and isolate your working environment is handy. I'm unsure if the overhead of virtualenv is so high that it offers a compelling reason to switch (at least for me).

</comment><comment><USER5> I'd hardly consider virtualenv with virtualenvwrapper "overkill". It's a pretty elegant and incredibly easy solution to conflicting dependencies that is capable of being used on almost any other environment easily.

<comment><AUTHOR> Elegance is always a relative term, but one could argue that having 0 dependencies is more elegant than having 2 dependencies.

<comment><USER12> Well 1 dependency, since this solution technically requires pip ;-)

</comment></comment></comment><comment><USER13> oh, it's 2015 and people still don't know about pep-370, PYTHONUSERBASE and pip install --user :(

[https://www.python.org/dev/peps/pep-0370/](https://www.python.org/dev/peps/pep-0370/)

<comment><USER14> That's for per-user isolation. This is about per-project isolation. A single user can have many projects with different dependencies.

<comment><USER13> that's what PYTHONUSERBASE (the environment variable) is there for!

<comment><USER14> Ah, I hadn't thought of using it that way. Seems like a working solution, even though it's not the problem that the PEP is meant to solve.

<comment><USER4> But you may want to keep 3 installation levels: global, per-user and per- project. If you use the second to achieve the third, then you no longer have the second.

</comment></comment></comment></comment></comment><comment><USER15> > forget about source env/bin/active and deactivate!

If the activate/deactivate bothers you, you can also just call the interpreter directly: env/bin/python ; you can also call any pip-installed binaries similarly. For example, env/bin/ipython if you have that installed. Or env/bin/pip.

I have a small utility[1] to magic that to "vpython" and "vipython" and "venv pip", respectively. (The last one is the general "execute this binary in the virtualenv" form; the utility makes some assumptions about how you name your envs, however, but also searches up the tree (I can cd into a dir, so I don't need to do ../../env/bin/python… or source the env.) I believe there's another implementation of this idea out there, but I can't find it at the moment.

(My vim is/was a bit python-heavy, and sourcing envs utterly breaks it if I attempt to start vim with an env sourced, since it gets the right vimrc, but the wrong pip installation)

[1]: [https://github.com/thanatos/vpython](https://github.com/thanatos/vpython)

</comment><comment><USER16> I started using pip -t ever since I started coding for AppEngine. I prefer it to a virtualenv becaus it works out a lot neater with the dev server. App engine's earlier approach was to use either virtualenv or pull all the dependencies' code down into the project directory but lately, the App Engine team have started recommending using pip -t instead.

</comment><comment><USER17> Careful using relative paths in PYTHONPATH.

If you share a file system with untrusted users (like /tmp or an NFS mount) or extract an untrusted archive (zip, tar, rar) then you might inadvertently execute python code that another user placed there!

It's the same reason why you shouldn't use PATH=. in your shell.

This poor man's virtualenv doesn't seem like a good idea...

</comment><comment><USER18> This is a very bad idea, for the same reason that relative directories are not on the regular PATH on Unix: On a multi-user system, or even a single-user system that sometimes has untrusted files on it, you can't safely use your tools if they can be overridden by whatever someone happens to have placed in the current directory.

For example, if you're looking through various home directories for some file, you might be doing something like:

      $ cd /home/foo
      $ ls
      $ cd /home/bar
      $ ls

If your PATH contained ".useful_stuff/tools" and the user bar happened to have a file called "/home/bar/.useful_stuff/tools/ls", that file has now been executed instead of /bin/ls, with your privileges. Your account has now been compromised.

Try this:

      [ptx@hn downloads]$ python3 -c 'print("hello")'
      hello
      [ptx@hn downloads]$ export PYTHONPATH="./.pip"
      [ptx@hn downloads]$ python3 -c 'print("hello")'
      You have been owned! Have a nice day.
      hello
      [ptx@hn downloads]$ cat .pip/site.py
      print("You have been owned! Have a nice day.")

For this same reason, if you use Mercurial on a repository owned by someone else, you get something like:

      [root@host foo]# hg stat
      not trusting file /home/ptx/foo/.hg/hgrc from untrusted user ptx, group users

Microsoft had a related security problem a few years back where they would load DLL files from the current directory: [https://isc.sans.edu/diary/DLL+hijacking+vulnerabilities/944...](https://isc.sans.edu/diary/DLL+hijacking+vulnerabilities/9445)

</comment><comment><USER6> This is a nice, simple solution to segregating python package environments. I personally prefer virtualenv, as I can navigate around the filesystem and open ipython from anywhere within the venv. I guess I don't see the usefulness of it so much because I have no problem using virtualenv.

The relative path is an interesting trick, I'll have to keep that in mind in the future.

</comment><comment><USER19> Since the packaging wars end of 2012 to beginning of 2013 I was following relatively closely packaging and requirements tracking, and let me say this: We don't need another solution. We need the solution we have to work better. Pip+Virtualenv is enough to learn and handle and nowadays works well for most use cases. It's maybe not perfect but it gets the job done. Problems I still see: Most of all integration with the system's package manager; pip3 install -e will be overwritten by the corresponding pypi package if you increase the version, although the -e installed version is already the required one; sudo pip3 freeze doesn't work, at least on the current Ubuntu.

There are so many little details that need to be fleshed out in such an infrastructure tool, we can't solve all these boring problems multiple times.

</comment><comment><USER20> There is probably an obvious answer to this, but a cursory google search turned up no answers.

The idea of having different multiple versions of dependencies on a single system is not exactly a new problem, and is solved by _many_ other package managers. Is there some inherent weakness in python modules that forces them to be managed this way? Do the maintainers of pip insist on this for other reasons?

It seems like one of the bigger complaints I hear about python so I feel like it must be harder then it seems.

<comment><USER3> But this is exactly what virtualenv does...

1\. You create a virtualenv 2\. You enter the virtualenv 3\. You install dependencies in it

Redo these steps for every isolated set of dependencies you want.

The solution proposed here does not solve anything. It only provides some half-working equivalent of virtualenv that works with a hidden directory to run your scripts...

<comment><USER21> The differences:

1\. Your 'node_modules' is automatically created by npm. No need for a separate tool.

2\. You don't have to 'enter' an npm environment other than changing to the directory where it exists.

These really aren't huge issues, but I can see it being an annoyance for some, especially people coming from Node.js to Python.

<comment><USER22> There is a more fundamental difference, which is what happens in a single project with a diamond-shape dependency with version mismatches, like this:

        A -> B, C
        B -> D == 0.1
        C -> D == 0.2

This dependency graph is handled easily by npm and other tools (at the expense of disk space, memory usage, etc.) and potentially small incompatibilities/gotchas, but is completely impossible to satisfy with pip.

</comment></comment></comment></comment><comment><USER23> IMHO complexity created by limited isolation facilities of virtualenv and the likes isn't worth the resources you save by not just having a VM for each app you work on.

The complexity arises from differing system-wide dependencies that are out of scope of various package managers or virtual environments, and from development environment (assuming we're addressing the need to have multiple apps co-exist on one machine for development) not matching production.

</comment><comment><USER24> Not sure why it tries to replace virtualenv which is already obsolete in favor of pyvenv which is built-in.

<comment><USER25> Not everyone is off Python 2.x yet, for a wide variety of reasons.

</comment></comment><comment><USER26> Also have a look at vex: [https://github.com/sashahart/vex](https://github.com/sashahart/vex)

Unlike this pip solution, vex extends your PATH to include installed scripts. It also works well on Windows and is really easy to use.

</comment><comment><USER27> Isn't it rather dangerous to have a "transparent" version of virtualenv?

</comment><comment><USER28> This is somewhat similar to what I do ...

<comment><AUTHOR> interesting! what do you do differently?

</comment></comment><comment><USER29> Packaging: if you have to do it, you should be building a bootable, distributable, OS instead.

Doesn't matter how many times others learn this lesson, I personally see it over and over.</comment>


Ask HN: Is there a way I can view top posts of all time? - <AUTHOR> <comment><USER2> You can _almost_ do this using the search.

Most popular stories - [https://hn.algolia.com/?q=&query=&sort=byPopularity&prefix=f...](https://hn.algolia.com/?q=&query=&sort=byPopularity&prefix=false&page=0&dateRange=all&type=story) Most popular comments - [https://hn.algolia.com/?q=&query=&sort=byPopularity&prefix=f...](https://hn.algolia.com/?q=&query=&sort=byPopularity&prefix=false&page=0&dateRange=all&type=comment)

... but what Algolia are doing to get "most popular", at least for comments, isn't the number of votes, so it's not what most people would consider 'right'.

<comment><AUTHOR> That's pretty cool. Thanks boss!</comment></comment>


Blame genetics for bad driving, study finds - <AUTHOR> http://www.cnn.com/2009/TECH/science/10/29/bad.driver.gene/

<comment><USER2> This article seemed misinformative to me. The experiment involved a very specific kind of driving, which could perhaps tell us something new about BDNF. Instead, the writer made inappropriately generalized conclusions about driving without any new information about BNDF.</comment>


Gladwell: In 50 years, people will forget Steve Jobs - <AUTHOR> http://www.cnn.com/2012/06/08/tech/innovation/gladwell-jobs-gates/index.html <comment><USER2> I disagree with this summation for one reason, both he and Gates are tied to the dawn on the PC revolution as such their personal history is intertwined with an important time in human history. Much like those whose history is tied to the renascence. I think they will be remembered because of their being anchored to an important time, much as Ford is remembered for being anchored to the industrial revolution. One cannot negate the surrounding macro history when taking into account how history will favor the micro actors in that time.

</comment><comment><USER3> _"We need to be clear when we venerate entrepreneurs what we are venerating," Gladwell said in Toronto. "They are not moral leaders. If they were moral leaders, they wouldn't be great businessmen."_

While entrepreneurs may not necessarily be moral leaders, I disagree with the implication that a great businessmen cannot also be a moral leader.

</comment><comment><USER4> Someone says something radical about tech, it makes big tech news on every blog. Rinse, repeat.</comment>


Google Photos passes the 1B users mark - <AUTHOR> https://www.theverge.com/2019/7/24/20708328/google-photos-users-gallery-go-1-billion <comment><USER2> real ones? :D:D</comment>


Sign Up at Irs.gov Before Crooks Do It for You - <AUTHOR> http://krebsonsecurity.com/2015/03/sign-up-at-irs-gov-before-crooks-do-it-for-you/

<comment><USER2> The fact that you have to just "sign up" on the website and manage this sort of delicate financial information is probably the worst they could have done.

I complain that my government gives me a piece of paper with the password (after they checking biometrics and lots of paperwork), but I now see that we're decades ahead of the IRS.</comment>


To Be the Best, You Have to Go Through the Worst - <AUTHOR> http://shahruk.com/2012/10/31/to-be-the-best-you-have-to-go-through-the-worst/

<comment><USER2> The article is a nice bit of wishful thinking—I wish you all the best. You should always strive to be better and do great things.

But I disagree with the basic premise in the title. I went through hell in my first startup because I believed this, and thought I had to push through my broken partnership and disagreements because starting a startup was always going to be difficult.

Now I'm working with fundamentally better people; wholly great people, in fact, and I've learned that everything I was told about startups and difficulty and "overcoming adversity" was just flat out wrong. I now truly believe that I didn't have to go through that hell to become the best. It was a lie. I only started becoming better once I was in a positive situation with a set of positive people doing work I believed in. The improvement in my life and work was exponential.

Moral of the story: trust your gut. If it doesn't feel right, it might not be. Maybe it's just hard, but maybe it's also _too_ hard. Of course you have to work your ass off, and of course you'll learn a lot, but it shouldn't drive you into the ground. Keep your head screwed on.

Advice I wish I had heard earlier; or from the right people, maybe.

</comment><comment><USER3> This isn't really necessarily true, and it definitely seems like he isn't making it easier on himself. Girl dumps him after a week (breaking his heart) and four years later they're back together, he's working on forgiving her, and they've co-founded a start-up?

Any personal issues you may have with someone are going to compound under the stress of a start-up (although 20 hours a week is about the same as many other college kids with part-time jobs), try to avoid crossing the streams.

<comment><AUTHOR> Well I did summarize the article quite a bit. Yeah I was hurt but we were freshmen in high school. What the blog post leaves out is how easily we were able to talk to each other even after that.

I'm a developer, I'm half creative, and I am more logical. I am good at getting things done, figuring out priorities, and talking to customers. I suck at saving money.

She's fully creative. She's more emotional, she's better at finding creative solutions to problems, and saving money.

We fully compliment each other in terms of skills and traits. Honestly id much rather be in a position where I have her as my partner rather than going to some event to find a cofounder who I trust with my business and idea over a few coffee dates.

However with that said, we do have issues balancing dating and work.</comment></comment>


Show HN: Using an ImageNet-pretrained image classification model in PyTorch - <AUTHOR> https://colab.research.google.com/github/stared/thinking-in-tensors-writing-in-pytorch/blob/master/extra/Using%20an%20ImageNet-pretrained%20model.ipynb <comment><AUTHOR> Source: [https://github.com/stared/thinking-in-tensors-writing-in- pyt...](https://github.com/stared/thinking-in-tensors-writing-in- pytorch/blob/master/extra/Using%20an%20ImageNet-pretrained%20model.ipynb) (from "Thinking in Tensors, Writing in PyTorch": [https://github.com/stared/thinking-in-tensors-writing-in- pyt...](https://github.com/stared/thinking-in-tensors-writing-in-pytorch))

Looking for feedback.</comment>


Sign Up Forms Must Die - <AUTHOR> http://alistapart.com/article/signupforms

<comment><USER2> There was some significant discussion when this was posted five years ago:

<https://news.ycombinator.com/item?id=145622>

If you think the HN community was smart back then, it's probably worth a look.</comment>


Don't Hammer Yammer. Think Bigger - <AUTHOR> http://www.markevanstech.com/2008/09/11/dont-hammer-yammer-think-bigger/ <comment><USER2> Yammer is Twitter for corporates done right.

Funny seeing how the blogosphere slams them for being a ripoff of twitter.

Hello! Facebook is a ripoff of Friendster. But Facebook is Friendster done right.

Yammer totally deserve the award. Everyone I ask (who's not a blogomaniac) thought Yammer was a great product in broadcasting news to a large group (beats mass-emailing)

</comment><comment><USER3> I haven't looked at Yammer, but Twitter seems like it's a bit 'free form' for business. What kinds of controls over inappropriate content, frequency of use, departmental scoping etc., is Yammer coming to the table with?

Small enterprises like software companies will probably be just fine with Twitter, but the real money is most likely in large enterprises with maybe 5000+ users, and real needs to control the uses that the system is put too, control abuse and so on. For example, the abuses possible with email and the web is a nightmare for these companies.

</comment><comment><USER4> My Yammer works fine.

</comment><comment><USER5> Why does everyone think people will pay to 'control' their network? None I know 'pay' to restrict IM, IRC, newsgroup posts, etc, so why should this be different?

<comment><USER2> If you come from an enterprise background, you'll find that most enterprises are really serious about controlling their network. So they will pay. $1/user is like tea break expense for them.

</comment></comment><comment><USER6> <http://presentlyapp.com/>

Another twitter for the enterprise. Looks good.

<comment><USER2> I like it. It'll appeal to those who finds Yammer lacking (eg. no group features).

But if i have to make a choice, i'll go with Yammer because

1) I don't have a need for those advanced features that presentlyapp provides

2) Yammer feels more fun

</comment></comment><comment><USER7> Yammer? I barely know 'er!

</comment><comment><USER8> I agree, please don't hammer my Yammer.</comment>


Code2vec: learning distributed representations of code - <AUTHOR> https://code2vec.org/ <comment><USER2> Most examples I tried didn't work very well, but when it did work it was truly neat. The performance makes sense from a quick glance into the paper. The model represents programs as paths in the AST, which is not sufficient to reconstruct the semantics, but is a good "fingerprint" of a program for fuzzy retrieval tasks. That's the domain which the authors wanted to target.

I wonder if there is really so much low hanging fruit still lying around, or if everybody who tried injecting some more domain knowledge into tools like this had quietly failed.

For example, the obvious way of building a distributed representation of, e.g., the simply-typed lambda-calculus (STLC) is by building a model. There are four local constraints that the model has to satisfy and the payoff is a representation that is invariant under program equivalence.

There are some complexity theoretic reasons why this cannot really work all the time (conversion in STLC is nonelementary), but even something that works in simple cases would be more robust than a statistical fingerprint that gets confused by the names of local variables...

<comment><USER3> > representation that is invariant under program equivalence

is this even computable at all (leaving aside the complexity theoretic issues)?

<comment><USER2> That was a poor choice of words. Models of lambda calculus are invariant under beta-eta conversion, which is what I meant by program equivalence, but which is not the same thing as contextual equivalence.

Thus you get a representation invariant under computation. This remains decidable when you consider only normalizing programs as in STLC or related subsystems.

</comment></comment></comment><comment><USER4> Nice! could be useful base for a tool to make code more DRY or higher quality.

One way would be an IDE extension that suggests a reference implementation of an algortihm if it finds code in your code base resembling it with high prediction score. Or if it sees code duplication it will suggest a refactoring to factorize the common function.

</comment><comment><USER5> This could be useful for reverse engineering minified/obfuscated code.

</comment><comment><USER6> Interesting concept, now to rush and lookup word2vec applications and see if they make sense for code :p

Also, props for an academic work having an extensive README! [https://github.com/tech-srl/code2vec](https://github.com/tech-srl/code2vec)

I do wonder if some sort of AST normalization would improve the input signal. Example 8 on the website shows their system correctly identifying an isPrime function. However some irrelevant perturbations can break it. If you swap the if statement condition around from `n % i == 0` to `0 == n % i` the proposed names are totally different and make no sense.

<comment><USER7> Well, than maybe train it on random AST equivalency transformations? I'd assume that to work better.

<comment><USER8> Yes, that indeed works better

</comment></comment></comment><comment><USER9> It would be nice if someone had some code with associated requirements, use- cases, user stories, or even test suites or documentation.

Then we could use an adversarial network to try to learn the relationship between requirements (or tests) and code.

<comment><USER10> JIRA could be parsed to do this, specifically when git commits are tagged to tickets. Quite an effort to get all that data in the right form though

</comment></comment><comment><USER11> Very cool idea, but other than the examples, I didn't very much luck. It wasn't able to guess a basic Fibonacci or FizzBuzz, and for isEven, it returned isOdd, which I guess is close but still.

<comment><USER12> The model was trained on real-world code of top starred repositories from GitHub.

Although we tend to think as Fibonacci and FizzBuzz as "basic" \- these are actually not common in real projects.

<comment><USER13> But what would we quantify as "real" projects?

<comment><USER12> We just took the top-starred Java projects from GitHub, assuming that their source code and naming are of good quality. These included projects like elasticsearch, hadoop-common and maven.

We assumed that their code and naming quality are worth learning, such that the learned patterns will transfer to other code and projects, because they are popular and actively maintained projects. So, as you can imagine, FizzBuzz is not that common there :)

<comment><USER14> You could probably dig up a pretty large number of high quality teaching repos to supplement those projects. I'm thinking of the types of repos that are included as supplements for MOOCs or reference books. Then you'll get some of the canonical gimmicky algorithms like fizzbuzz. But more importantly, you will get reference implementations of fundamental algorithms. Things like mergesort or binary tree search. While you are unlikely to see a straightforward implementation of those algorithms in a production repo, it wouldn't surprise me to see some the core abstract patterns repeated over and over again because they are so fundamental to CS pedagogy. And if you pick sufficiently high quality repos, you (hopefully) won't be compromising the code quality metrics driving your selection of those top starred repos.

<comment><USER15> Consider also Rosetta Code, which should have Java implementations for a ton of simple problems.

</comment></comment></comment></comment></comment></comment><comment><USER16> This is a really cool demo. For common patterns like get, contains, ends with, etc, this could be helpful in code representation without having to go into the details.

</comment><comment><USER17> We're being replaced.</comment>


OP-Z Synthesizer - <AUTHOR> https://teenage.engineering/products/op-z <comment><USER2> Promising similar open source project : [https://github.com/topisani/OTTO](https://github.com/topisani/OTTO)

The progress made by the guys these last months is impressive, and both the UI and hardware aestetics really shines (while they are inspired by the OP1, they now have their own personality)

<comment><USER3> Awesome! How did you find out about this project? I've been looking to work on a project like this and didn't find them.

<comment><USER4> I have also seen this project while looking for an open source VST in a pi-box thing. Looks really neat.

<comment><USER5> There are a couple of these kinds of devices you might not have tuned into yet, namely:

Axoloti:

[http://www.axoloti.com/](http://www.axoloti.com/)

(There are great cases/knobs/button boxes for this, for example check this thread out for the mad directions things can take: [https://www.muffwiggler.com/forum/viewtopic.php?t=158092](https://www.muffwiggler.com/forum/viewtopic.php?t=158092))

Organelle:

[https://www.critterandguitari.com/organelle](https://www.critterandguitari.com/organelle)

Another very cute, very programmable portable digital synth ..

And then there are things like this, which I had the pleasure of playing recently at superbooth:

Sonicware ELZ1:

[https://www.sonicware.jp/elz-1-1](https://www.sonicware.jp/elz-1-1)

So, yeah .. lots of little portable, digital and analog synths in the OP-1/-Z style format.

</comment></comment></comment></comment><comment><USER6> I have an OP-1 and an OP-Z. More and more I use the OP-Z, the sequencing workflow is just incredible. I don't have an ios device and after climbing the learning curve it's totally functional without a screen.

Also, the OP-Z can be used to sequence several pieces of external hardware at once [0]. Definitely not a toy. It has it's quirks (e.g. adding your own samples requires chopping them to exactly 6 seconds or all hell breaks loose, and no ability to "zoom in" on your sequence if you have multiple trigs per step) but it's a trade-off for all the power in the form factor.

[0] [https://www.youtube.com/watch?v=XHfCl6-xamM](https://www.youtube.com/watch?v=XHfCl6-xamM)

<comment><USER7> Zoomings been in beta for ages. In the latest fw samples on synth tracks can be <=6 seconds and wav also.

<comment><USER6> Oh great, I need to update then! Is the beta available to test somewhere?

</comment></comment></comment><comment><USER8> Whatever Teenage Engineering makes, it looks awesome and seems to be of great quality.

I randomly found out about them and started looking at a bunch of youtube videos, it made me really want to check those things out.

I ended up buying a PO-33 KO, it's super fun. Turns out I can't make music (and don't really care for it) but the quality of the product is awesome and I'd recommend to anyone interested in music.

<comment><USER9> I'm in the same boat. I really like the product but have a really hard time creating anything enjoyable.

<comment><USER10> Same, I'm drawn to the buttons and knobs and flashing lights and cables though.

Is there any good tutorial or course out there on how to evolve from making a thing create random noises to actual music?

I mean this device is a big initial investment. The Pocket Operators less so though.

A colleague also showed me the Korg Monologue, which has a lot of things going for it (synthesizer + sampler built in one, only thing lacking maybe is drums / beats but you could hook it up to idk, GarageBand maybe and stream it through or add it later?)

<comment><USER11> I started from scratch with ableton and have worked my way up to make decent techno music. [0] I've watched a ton of YouTube channels on production and just fiddled around with every effect. It's best to start out with a basic loop you enjoy and then iterate on it [1], if you're not feeling it, put it aside and work on another loop and come back later. In my opinion the most important thing is to try and imitate the things you like because it reveals a lot about the music, which is a good learning experience, and additionally about your own way of hearing etc. It's also important to see theory as a sort of praxis, most of the stuff is empiric and after the fact, nothing really matters, but it's useful to know for when you're stuck.

[0]: [https://m.soundcloud.com/someotherorder/of-necessity- absolut...](https://m.soundcloud.com/someotherorder/of-necessity-absolute- nonsense)

[1]: [https://m.soundcloud.com/someotherorder/vile- break/s-e7EV6](https://m.soundcloud.com/someotherorder/vile-break/s-e7EV6)

<comment><USER12> Very nice music! Thanks for sharing.

</comment></comment></comment></comment></comment><comment><USER13> Some alternatives if the op-z isn't quite hitting the spot for you:

Elektron Digitakt - powerful sampler / sequencer. No synth engine but you can make many synth sounds using single-cycle samples.

Elektron Digitone - same form-factor as above but with an fm synthesis engine (think yamaha dx7) instead of a sampler.

Novation Circuit - wayyy cheaper. Can play samples but not sample live. Powerful synth engine, not fully editable without a computer. Good for live improve with pre-composed patterns.

<comment><USER4> Synthstrom Deluge (Synth, drums, amazing sequencer, sampler and soon to be live looper in v3) was the choice for me when considering TE products. I almost bought a bunch of Pocket Operators, then I looked at the cost and decided to just pull the trigger on what I really wanted and got a Deluge. I love it, so much.

<comment><USER14> The USP of the Deluge seems to be the isomorphic(?) chord keyboard. How did you find that to be? Was it easy to learn?

I admit I would love one but the price puts me off.

<comment><USER4> Personally the major selling point of the Deluge, and the reason I love it so much, is the sequencer. It's the most intuitive sequencer I've used and allows you to flow and work quickly.

The scale note keyboard is good, but not all that playable, a LaunchPad might be better for doing similar but with aftertouch and bigger pads. That said, it's a very welcome feature and easy to use for coming up with ideas and staying in key.

I am not a musician though, at all. I am rubbish at music, but the Deluge has helped me make smiles and dive into hours of sounds and beats I thought I'd never be able to make. I've spent time in Ableton and never got anything much out of mouse clicking, mostly just frustration with all the options and tedious input methods. With the Deluge I can turn it on and quickly lay down a simple chord progression, a drum beat, and make a bass line that satisfies. Then I twist filter knobs and mute tracks, and just jam on it for hours.

Oh, and its battery powered, so I take it everywhere. It's just such a wonderful piece of technology. Easily worth every penny I spent on it.

<comment><USER14> Thanks - I looked at a video of the sequencer, and it seems a lot like the Tenori-On (which I have).

</comment></comment></comment></comment></comment><comment><USER15> Teenage Engineering make astonishing products you just want to own even though you have no use for them. There is something deeply aesthetically pleasing about their devices.

If the price hadn't been so steep for their OP-1 I would have bought one on impulse years ago.

<comment><USER16> I've been traveling full-time for a year and living out of basically one big rolling-suitcase. Every time I'm back in the states, I convince myself to put the OP-1 in storage - it's just taking up weight, I could just as well use Ableton, etc...

...but I can never bring myself to leave it. I don't use it a ton, but when I do I get sucked into it for 4+ hours. I especially love to use it on long international flights (I read someplace this was one of the design goals), and my tape tracks are crammed with loops from the last 5 years - it's unexpectedly nostalgic to listen back.

I originally bought it because of that strange impulse you mentioned, at a time when I really shouldn't have been buying expensive synth-toys - but I'm so, so glad that I did. Totally encourage you to pick one up if you ever get the opportunity!

<comment><USER17> I'm in a very similar situation with the OP-Z! No musical background, bought it because I was curious about the UI. I find myself getting sucked into it for hours at a time, even though I haven't yet made a beat I'd be comfortable sharing.

My original plan was to sell the OP-Z after a few months, but now I think I will hold onto this thing until it dies.

<comment><USER18> > No musical background, bought it because I was curious about the UI. I find > myself getting sucked into it for hours at a time, even though I haven't yet > made a beat I'd be comfortable sharing.

Study music theory! Seriously, it's more of a science than an art. The art comes in how you apply it. I made a huge jump from making little 10-second loops to making enjoyable music after I learned a little theory. It is well worth your time.

<comment><USER19> Yet most musicians are not consciously aware of theory while they make music. So you don't really apply music theory, many great artists don't actually know the theory much at all.

</comment></comment></comment></comment></comment><comment><USER20> The decision to depend on an external device is going to suck in 30 years. This is where the OP1 shines. Meanwhile I have synthesizers from the 70's and 80's that still work well and sound amazing.

<comment><USER21> My sense is that it doesn't strictly rely on an external device - you can find your way to where you like without a screen... My long-term fear is what happens when the internal batteries get old.

(I love my OP-1 and pile of pocket operators; Teenage Engineering is doing amazing work.)

<comment><USER22> Maybe I misunderstood the OP-Z manual but I think that some of the functionality of the OP-Z is only accessible if you connect it to an iOS device, e.g. the two features called Photomatic and Videolab.

PS some recent promotional material by TE said that the OP-Z app is iOS only "for now", so at least there is hope that it will become available on more platform.

<comment><USER23> Those are both at least 100% ancillary to it's function as a synth and sequencer and are kind of just fun extras for stuff like live performances.

</comment></comment></comment></comment><comment><USER24> On similar note: I am so addicted to the programmable synthesizer [http://foxdot.org/](http://foxdot.org/)

<comment><USER25> This looks amazing! How steep would you say is the learning curve? Is it worth it?

<comment><USER26> Foxdot is based on Python so if you know Python you can get going making beats pretty quickly. It's great fun to play with but I think it takes time to get used to thinking of melodies in terms of numbers rather than frets or keys. I'm now spending some time learning Supercollider which Foxdot uses to make sounds.

</comment></comment></comment><comment><USER27> I played with one of these a month or so ago and will definitely get one for my more musically oriented child to play around with. They're fun and a different way at making synthesized sounds, the UI is reminiscent of handheld game consoles. Beware though, these could very well be a gateway drug to a house full of gear ;)

<comment><USER28> You can't ever overcome synth GAS... I have a music studio full of latest greatest toys and it's never enough... Better excise it right in the beginning or you are lost forever ;-)

</comment></comment><comment><USER29> teenage engineering industrial design > Apple industrial design.

<comment><USER30> Great... now Apple will buy them, steal their designers and engineers, and run the place into the ground

<comment><USER29> garage band ver. x with digital version of OP1

Please no!

</comment></comment></comment><comment><USER31> Wow, it's quite expensive, especially in comparison with recent gen of affordable synths.

<comment><USER32> Can you point to some affordable recommendable synths?

<comment><USER10> I've recently played with the Korg Monologue, it's a solid machine, analog synthesizer and step sequencer, enough standard ports to extend it eventually - a criticism to the device mentioned in the OP is that it's pretty nonstandard in a bigger workflow. It's < $300, still not cheap but a pretty good package overall.

A lower price is the Korg Volca, at $100 - $150 per unit. They're less versatile though and you'll probably end up having to buy / link up multiple.

Even lower and you're looking at stuff like the Teenage Engineering Pocket Operator series, single card devices in the $70 range. There's a wide range of variations, each of which (correct me if I'm wrong) has 16 instruments and a programmable step sequencer, 16 patterns preloaded. The preloaded patterns have only 16 steps, but you can program it to have more than that and switch between patterns every 16 beats. You can link up multiple together as well, they can synchronize with one another (iirc you have to hook up your phone as the first step which generates a synchronization signal).

<comment><USER33> You don't need a phone, the Pocket Operators have a couple of different sync modes so that you can have one be the master.

</comment></comment></comment></comment><comment><USER28> How does it compare to Novation Circuit (my favorite travel toy) or Deluge?

</comment><comment><USER34> Looks like a cool product. Couldn't see how much it costs.

Pity it only works with ios. I have one and like a lot of things about Android, but they really dropped the ball with no low-latency audio support.

</comment><comment><USER35> I guess I'm not in the target market, but how do you play this musical instrument? It looks like it doesn't have much in the way of a keyboard?

</comment><comment><USER36> The OP-Z is cute, but I've been looking for an iOS synth app that comes close to the OP-1 experience for a long while - in my view, it is a much nicer synth.

<comment><USER37> Do take a look at Korg Gadget - it is a tremendous piece of software. VERY easy to pick up and just jam even with the vanilla synths (Chiang Mai is one big sweet spot), but really also deep enough to produce pro level tracks. The additional KORG synths (especially the wave station and ODYSSEi) are high end emulations and basically indistinguishable from the original hardware.

<comment><USER19> I would say indistinguishable is an overstatement.

</comment></comment></comment><comment><USER38> That's a good price.

<comment><USER39> I'm not convinced, particularly given Teenage Engineering's pricing history.

I root for them, absolutely. But their stuff carries a premium and is technically limited, generally fulfilling a novelty space.

The big win here is the visual stuff, but again I'm not sure that justifies the price.

<comment><USER40> I would never call OP-1 limited. I haven't touched the OP-Z but I doubt I'd think it's "technically limited" as well.

I'd say that the OP-1 is probably one of the better designed musical instruments in the recent past.

<comment><USER41> TE make toys - finely designed and polished toys supported by a finely designed and polished web site. But still toys.

OP-1 has a lot of options that make you feel like you're making music, when in fact you're trapped in an endless round of "What happens if I...?" inside the feature space.

Hence the novelty tag. They're not particularly productive instruments, but they can be a fun way to pass an hour or two.

A software environment like Max, PD, or Reaktor is much less limited. But the learning curve is much steeper, and the instant gratification factor much lower.

And then there are the code-based environments like Supercollider, in which you can implement the OP-1 sequencers and synths with a few lines of code, and easily create your own variations - but the learning curve for non-coders might as well be vertical, and it's not shallow even for experienced coders.

<comment><USER23> > A software environment like Max, PD, or Reaktor is much less limited. But > the learning curve is much steeper, and the instant gratification factor > much lower.

I think comparing any physical keyboard synth/sequencer to the full desktop software is going to make the device look like a toy in comparison. It's apples and oranges in terms of available power and interface and really purpose.

</comment></comment></comment></comment></comment><comment><USER42> Proprietary device with proprietary bindings. I like pocket operators a lot, but this seems like TE is going the opposite of where I wished they would...

<comment><USER43> what a strange stance. what would you have them do?

and if you want an open source "portable keyboard thing", then there's already the organelle. it is no surprise it isn't much cheaper and isn't as well designed, for both hardware and software.

[https://www.critterandguitari.com/organelle](https://www.critterandguitari.com/organelle)

<comment><USER42> An HDMI/USB port, alongside access not simply for Unity but also for raw data for use with OpenGL and whatnot. It's not an unreasonable request.

<comment><USER44> That is an unreasonable request. It contradicts their modus operandi and demands the earth, moon, and stars of an off-the-shelf product so that a niche - game developers - can build profitable tools on top of it while paying them nothing for the privilege.

<comment><USER42> Dang, times _sure_ have changed. Back in my good ol' days...</comment></comment></comment></comment></comment>


Ask HN: What makes HN the superior intellectual forum on the web? - <AUTHOR> Personally, I find these two below mentioned reasons for HN's appeal toward intense intellectual discussions, unparalleled to any other place on the web --
1. Bare-bones design -- This acts as a great filter and barrier-to-entry of sorts, wherein only those who _actually_ want to consume (or contribute) content stick around.
2. Text heavy content -- Again, I personally find this super appealing. Text only content keeps the reader's focus on what the author is trying to convey, which more often than not brings out the best in one's writing. Contrast that with many competing 'multimedia-heavy' forums where there's a greater chance of a reader getting distracted by unrelated content (suggested, similar, etc).
Bonus: Well implemented nested comments -- Following two HN users have a go at each other (respectfully, that is) in a fine display of one-upmanship is absolutely gratifying with a super-low chance of it going ad hominem.
What'd you guys think? <comment><USER2> That's quite a premise! I disagree with it extremely strongly.

People mostly don't go back to any HN thread that's more than a day old. So any conversation that requires more than a few hours of thinking can't happen here, because by the time you finish thinking hard about what you just read, no-one is reading anymore. How could that possibly lead to the superior intellectual forum on the web? It's a place for people to share their initial opinions about something in response to news. That can be good! Often people have interesting first opinions! But it's not the pinnacle of intellectual thought.

<comment><USER3> Additionally, people commonly don't read the articles posted, then make comments asking about or mentioning things that are discussed in depth in the article, because they want to get in early and get those upvotes before the thread becomes too crowded.

</comment></comment><comment><USER4> Occasionally, you can find great discussions on HN because HN has a large amount of domain experts on various sciencey topics. Apart from that, I don't really think HN is that incredibly fantastic.

If you compare it with your average social media (facebook, twitter, mainstream reddit), then yeah, you could say HN is more intelectually sophisticated than that.

The realest, greatest and most fantastic forums are the tiny ones, ones dedicated to a very specific topic, attracting only those who have a major interest in that topic.

Think of various tiny dedicated subreddits, or Lambda the Ultimate, or a huge collection of sites no-one here has ever heard of...

HN's great, but absolutely doesn't deserve the title of "superior intellectual forum on the web". That's _way_ too much.

<comment><USER5> > Occasionally, you can find great discussions on HN because HN has a large > amount of domain experts on various sciencey topics. Apart from that, I > don't really think HN is that incredibly fantastic.

Exactly. HN has experts, especially in some areas of computing. But many people sound off without knowing what they are talking about. I usually wonder why I even bothered to comment on something related to space. Space seems to be a topic the HN loves, but there aren't a ton of people here with real domain knowledge in it.

</comment></comment><comment><USER6> > _" The superior intelectual"_

??

I believe this is arrogant and wrong. Both the words _the_ and _superior_ give me that impression.

I also believe both points you mentioned are just characteristics that fits the culture of its members in a self-reinforcing loop. Not causation for the quality of its comments.

</comment><comment><USER7> 1\. The actual people who choose to be here.

2\. The reasons they choose to be here.

3\. Good moderation, in part because it is paid, but in part for other reasons. (I know a forum where, in my opinion, the paid staff are The Problem.)

4\. "Table Stakes" \-- for some people here, there is potentially a lot on the line. This means the most influential people have intrinsic motive to reign themselves in and cooperate with the moderating staff's agenda instead of taking some big stand _on principle_ etc.

5\. The nature of those "table stakes" probably helps to combat classism, sexism, racism, etc.

</comment><comment><USER8> Most submissions and comments here are far from intellectual. I don't know what your frame of reference is, but seriously?!

</comment><comment><USER9> It's the zeitgeist. HN aggressively self-moderates, the actual moderators have a light but objective touch. With exception to a few characters, I've chatted with people here who have not only changed my beliefs but also changed theirs. The community believes in scientific rigor, but also share illuminating anecdotes.

You can't distill HN into a formula. It is the sum of the participants.

</comment><comment><USER10> I think this thread is satire. Have a good one.

</comment><comment><USER11> While I do think the user base is intellectual, theres really not much conversation.

In the good old day there would be a proper forum with conversations that went for months.

</comment><comment><USER12> None of the features you mention have any but the weakest relationship to the intellectual quality of Hacker News.

Take all of them together, you could describe Reddit before the rebuild. Minus the nested threads, you could be describing 4chan (which, despite being an imageboard, has a lot of textual content.)

</comment><comment><USER13> I think the key is heavy handed moderating. It creates a culture where certain types of comments aren't allowed(aggressive, and flippant) which brings up the level of commentary.

</comment><comment><USER14> ... just like boards2go forums.</comment>